Как визуализировать дизайн физического движка?

Я делаю физический движок, и мне становится довольно сложно следить за всем этим. Часто, когда я возвращаюсь к своему коду после перерыва, я просто не помню, почему это не работает. Большинство проблем - не просто ошибки программирования, а недостатки дизайна в моем физическом движке. Вот почему я должен просто закончить проектирование, прежде чем программировать.

Однако мне нужен способ написать на бумаге весь дизайн моего физического движка. Иначе я просто забуду это завтра и снова потеряюсь. Диаграмма классов UML совсем не подходит для разработки физического движка. Я действительно не забочусь о классах, но о процессе. Я не считаю диаграмму бизнес-процесса действительно полезной, потому что моделирование одного шага (фрейма) моего процесса не поможет мне понять окончательное поведение моего движка на многих этапах.

Итак, какую диаграмму я должен использовать, чтобы помочь мне следить за процессом? Какую диаграмму используют профессионалы для создания физического движка?

Делать списки замечательные вещи.

Я не говорю о // #TODO: комментарии бла-бла. Я имею в виду получить честный для Бога блокнот.

Никогда не знаешь, когда вспомнишь что-то важное. Записная книжка будет спокойно сидеть и позволять вам думать, не жалуясь на то, как ваш почерк не будет компилироваться. Некоторые из моих лучших идей происходят в ванной комнате (да, у меня есть водонепроницаемый блокнот, но вам не нужно заходить так далеко).

Вы можете получить карманные, которые сшиты (не склеены), чтобы они не развалились в вашем кармане. Не удалось получить модный со встроенной закладкой? Лента, ножницы, лента и никто никогда не узнает.

Когда идея приходит в голову, просто запишите ее. Нарисуйте маленькие прямоугольники рядом с каждой идеей, и вы можете легко пометить ее как выполненную. Поставьте поле вверху страницы, и вы узнаете, когда страница будет готова.

Какой последовательный доступ недостаточно хорош для вас? Да, они также делают карманные переплеты. Все это может показаться немного большим, но это лучше, чем тонуть в заметках или пытаться запечатлеть все в Jira.

Не оставляйте вещи наполовину реализованными

Держите ваши улучшения маленькими и достижимыми. Не начинайте ничего, что не может быть закончено за один присест. Если это слишком много для этого, то разбейте его на более мелкие шаги. Всегда оставляйте код, который компилируется и проходит тесты. Да, и не оставляйте проходные тесты, которые вы никогда не видели неудачными. Выполнение теста, как успешного, так и неудачного, - это то, как вы тестируете тест

Перестань думать, что тебе нужен весь дизайн на бумаге

Что вам нужно сделать, это захватить ваш развивающийся план. Вы не знаете, как все будет выглядеть, когда вы закончите, так что перестаньте притворяться, что вы это делаете. Захватите то, что вы выяснили так хорошо, как можете. Используйте салфетку и карандаш, если нужно. В любом случае, мало кто понимает 90% UML. Используйте все, что вы можете, чтобы показать, что вам нужно показать. Я сосредотачиваюсь на том, чтобы показать свои интерфейсы и что знает о чем.

Пишите заметки, когда вы прекращаете кодировать

В тот момент, когда вы снимаете пальцы с клавиш, вы в последний раз поймете, что вы сделали (и что вы запланировали), а также что вы делаете сейчас. Запишите это понимание как можно лучше в некоторых заметках. Если у вас есть только комментарии, то вы все еще привязаны к компьютеру и, скорее всего, оставите лужу на стуле. Опять же, иметь ноутбук - это классно.

Таким образом, вы можете изящно посадить свой мозг, спасти свой мочевой пузырь и снова взлететь позже, не прибегая к кофеину и стискиванию зубов.

«Все должно быть построено сверху вниз, кроме первого раза», - говорят они.

Я бы начал с самого низкого уровня (например, базовой векторной математики), и убедился, что хорошо его понимаю и у него хорошее тестовое покрытие. Затем я построил бы еще один слой поверх этого, позволяя выполнять более абстрактные операции (например, группы / объекты, обнаружение столкновений, механика столкновений). Опять же, я бы покрыл это тестами; это помогло бы мне подумать о реальных случаях использования этих абстракций в движке.

Если у вас нет очень хорошего понимания всего движка (например, когда вы повторно внедряете хорошо известный существующий движок), обычно хорошо иметь эти слои; это позволяет вам думать о конкретном слое с точки зрения предыдущего слоя, и, как правило, не намного глубже. Вы можете экспериментировать и создавать слой с новыми полезными абстракциями; то, что оказывается практичным в реальности, часто отклоняется от первоначальных идей.

Надеемся, что каждый слой достаточно мал, чтобы вам не требовалась сложная схема, или просто создать полезную.

Я никогда не сталкивался со сложной диаграммой кода, которая была бы полезна. Тем не менее, полезны диаграммы взаимодействия и жизненного цикла . Довольно часто такая диаграмма ограничена 1-2 слоями и поэтому проста.

Что я обычно нахожу наиболее ценным, так это описания интерфейсов и гарантии, предоставляемые каждым уровнем. Например, формат векторной математики и то, что происходит при числовых ошибках; формат более крупных описаний объектов (всегда выпуклый, всегда по часовой стрелке, как пересекаться и т. д.), механические параметры взаимодействия (как продвигается время, как обрабатывается масса, всегда ли сохраняется импульс, как рассчитываются силы?), тогда собственно взаимодействия (как справиться с трением? деформация? фрагментация? превращение механической энергии в тепловые потери вещь?).

Каждый слой должен быть достаточно маленьким, чтобы иметь заметное количество вещей, которые он вводит, и гарантирует, что он обеспечивает. Это описание может быть составлено даже без написания кода реализации (пока). Это снижает вероятность того, что вы сделали что-то ужасно неправильное в трех слоях; если бы вы это сделали, это было бы видно не более двух слоев глубиной уже.

Составьте схемы архитектуры! Трубопровод OpenGL диаграммы FrustratedWithFormsDesigner размещены в комментарии являются отличным примером для программы потока , но это только один тип диаграммы , которые могут быть полезны.

При разработке диаграмм вы хотите сделать понимание кода простым и интуитивно понятным; это может включать как высокоуровневые концепции (например, верхнюю линию узлов в этой конвейерной диаграмме OpenGL, что-то сказать), так и очень детальные технические детали (например, полный график вызовов функций).

В идеале ваша документация должна также облегчить понимание кода другими людьми; это может упростить проверку кода или совместную работу с открытым исходным кодом. Посмотрите на большие проекты, чтобы увидеть, как они этого добиваются - при работе с сотнями тысяч или миллионами строк кода понимание того, как работает программа без необходимости ее чтения, чрезвычайно важно для отслеживания базы кода или представления ее другим. , В репозитории Vim с 1,3 млн. LOC есть отличная документация высокого уровня (IMO) для этого в /src/README.txt . Это вводит:

• Какой код в каждом файле делает
• Важные глобальные переменные и их значения
• Что происходит в основном цикле и какие функции он вызывает
• Что происходит в каждом из режимов, и основные функции, которые их обрабатывают
• Что такое встроенные функции отладки

Если я хочу добавить патч, я обычно знаю, какой файл мне нужно изменить, чтобы достичь своих целей без особых усилий.

Одна из лучших особенностей Vim - /src/README.txtэто то, насколько легко ее найти и насколько она всеобъемлющая; в любом случае это не гранулярно, но если вы щелкнете по srcпапке на Github, она автоматически загрузится и даст указание найти другой код или документацию. Сравните это с репозиторием Powershell, который я искал в качестве примера, но не смог найти какой-либо эквивалентный файл или файлы Vim's /src/README.txt. (Плохой знак для проекта с 988 тыс. LOC!)

Некоторые вещи, которые вы можете захотеть построить в виде диаграммы или документа:

• Концептуальный ход программы (что программа выполняет и в каком порядке?)
• Реализован поток программ / график вызовов функций (Как программа достигает своих целей? Какие функции вызываются или создаются классы?)
• Какой код в каких файлах? Какова организационная схема и какие у вас есть правила для определения направления новой функции? Если у вас есть строгая организационная схема, знать, какой файл искать для определенной функции или класса, будет легко, даже без IDE или подобной IDE функции «найти проект».
• Кроме того, какие файлы включают какие другие файлы (связанные с графиком вызова функций)?
• Какие классы наследуют от каких других классов? Какова цель каждого класса?

Как вы можете сделать эти диаграммы? На вашем уровне, и для первых проектов, карандаш и бумага, вероятно, лучший / самый быстрый метод. Когда диаграммы и документация станут более четкими, вы можете изучить:

• Dot / Graphviz, набор программ для генерации графиков из .dotфайлов.
• LaTeX / TikZ, очень сложный и многословный инструмент для генерации графиков или изображений любого рода - он может быть слишком сложным для ваших нужд, особенно потому, что позиционирование всех узлов выполняется вручную, но об этом следует помнить, особенно если вы планируете написать бумага или что-то в этом роде позже.
• Для C, gson в egyptкрючках в gccи выводит .dotграф вызовов. Может быть автоматизирован или встроен в makeкоманду, что приятно!
• Аналогично, GNU cflowможет генерировать только текстовые графы вызовов для C. Эквивалентные инструменты могут существовать для других языков, хотя вы можете отказаться от автоматических инструментов в целом - не создание графика вручную может помешать вашему пониманию кода или обеспечить ненадлежащее предоставление сложный уровень детализации (знание того, какие вызовы функций printf()обычно бесполезны).

Попробуйте использовать диаграмму на основе сетей Петри. Можно систематически переводить диаграмму в компьютерные программы и интегрировать диаграммы высокого уровня с диаграммами низкого уровня.

Ссылки

Сетевые элементы и аннотации: универсальный язык визуального программирования (2016). Доступно по адресу https://www.academia.edu/31341292/Net_Elements_and_Annotations_A_General-Purpose_Visual_Programming_Language .

Сетевые элементы и аннотации для компьютерного программирования: вычисления и взаимодействия в PDF (2014). Доступно по адресу https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .