Как это сделать против Solid Software Design?

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

Мой личный вызов: как насчет эффективности сегодня и долгосрочного мышления в то же время? Кроме того, в то время как вы делаете это, вы, возможно, с таким же успехом захотите изучать новые вещи в пути, вместо того чтобы прибегать к тем же повторяющимся схемам, которые вы использовали в течение последних 5 лет?

Чем меньше опыта у вас есть, тем больше времени вы тратите впустую с предварительным дизайном. Создание хороших дизайнов - это то, что вы узнаете, выполнив это, а затем увидев / оценив, как это получается. Некоторые решения имеют далеко идущие, но неясные последствия. После некоторых игр вы, вероятно, сможете сделать первоначальный дизайн довольно солидным, и это окупится, если вы потратите еще немного времени на этот этап.

Мой девиз: прежде всего делать вещи, но руководствуйтесь здравым смыслом, чтобы определить, какие компоненты более критичны, чем другие, и спроектировать их довольно хорошо, в пределах вашего временного ограничения. Например, если ИИ имеет решающее значение для вашей игры, убедитесь, что вы можете легко расширить / изменить его позже. Или, если вы собираетесь написать компонент, который вы будете использовать в каждой игре, разработайте его для повторного использования. Отслеживайте свое время и не сходите с ума от проектирования. Установите крайний срок разработки и после этого начните взламывать все, чтобы получить конечный срок выпуска. Но убедитесь, что вы отметили, какие пункты необходимо реорганизовать / перепроектировать впоследствии, и рассчитайте через некоторое время, прежде чем вы начнете в следующей игре улучшать эти вещи, чтобы они не могли вас укусить!

Хороший совет: если вам приходится выбирать между двумя вариантами, не задерживайтесь над деталями. Чаще всего нет «хорошего» или «плохого». В некоторых ситуациях A будет лучше, в некоторых - B, и в целом разница между ними не всегда будет стоить времени.

Существует большой опыт в разработке программного обеспечения или игр, поэтому убедитесь, что вы тратите часть своего времени на исследования (например, читая книгу по дизайну, читая об опыте других, разговаривая с другими программистами о ваших разработках и т. Д.) ).

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

Есть принцип, называемый YAGNI , он же «Ты не собираешься нуждаться в этом», который в основном гласит, что ты не должен реализовывать что-то, пока не поймешь, что тебе это понадобится.

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

Моя личная философия - сделать самое простое, что могло бы сработать . Тем не менее, есть разница между «Готово» и «Взломать дерьмо вместе». Написание кода с определенной целью не должно подразумевать создание вещей, которые генерируют «запах кода», таких как обнародование всего, наличие классов blob, которые делают все, или любой из этих десятков других вещей, которые означают «плохой» код.

Это оценивается как истинное в моем мышлении сегодня:

• Прагматизм над идеологией
• (1) Заставьте его работать (2), затем сделайте это правильно - игра окончена, если вы забудете шаг 2
• Отпусти это!
• Слишком много предварительного дизайна будет пустой тратой времени
• TDD и Clean Code позволяют создавать более простые и стабильные программные решения.

Я друг программного обеспечения быстрого прототипирования. Особенно во время разработки игр. Это хорошо для быстрого изучения, тестирования и использования вещей. Для близкого к аппаратному программированию или сложных алгоритмов это лучший метод для меня.

Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
 Testing();
 LotOfFixing();
 PlayingWith(); 
 bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();

Моя версия Rapid Prototype должна иметь правильную корку прототипа:

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

Преимущества:

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

Если вы делаете это хорошо, у вас может быть настоящая отладочная / обучающая версия вашего продукта.
Мы используем его в нашем проекте, и мы довольны этим.

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