Я предвосхищу это, говоря, что я не искал огромное количество игровых исходников и не создавал много игр.
Но из-за того, что я пытаюсь использовать «корпоративную» практику кодирования в веб-приложениях, просмотр исходного кода игры серьезно ранит мою голову: «Что эта логика представления делает с бизнес-логикой? Это требует рефакторинга ... так же как и это, рефакторинг, рефакторрр» "
Это беспокоит меня, когда я собираюсь запустить игровой проект, и я не уверен, будет ли попытка mvc / tdd процесса dev помешать нам или помочь нам, так как я не вижу много примеров игр, которые используют это или большой толчок для лучших архитектурных практик это в сообществе.
Ниже приведен отрывок из отличной статьи о создании прототипов игр , хотя мне показалось, что именно такое отношение многие разработчики игр используют при написании кода для производственной игры:
Ошибка № 4: Создание системы, а не игры
... если вы когда-нибудь обнаружите, что работаете над чем-то, что не продвигает вас вперед, остановитесь прямо здесь. Как программисты, мы склонны пытаться обобщать наш код, делать его элегантным и уметь справляться с любой ситуацией. Мы считаем, что зуд ужасно трудно не поцарапать, но нам нужно научиться. Мне потребовалось много лет, чтобы понять, что дело не в коде, а в игре, которую вы поставили в конце.
Не пишите изящную игровую систему компонентов, полностью пропустите редактор и запишите состояние в коде, избегайте управляемых данными, самостоятельного разбора, XML-сумасшествия и просто кодируйте эту проклятую вещь.
... Просто выведите материал на экран как можно быстрее.
И никогда, никогда не используйте аргумент «если мы потратим дополнительное время и сделаем это правильно, мы сможем использовать его в игре». КОГДА-ЛИБО.
это потому, что игры (в основном) визуально ориентированы, поэтому имеет смысл, что код будет сильно взвешен в представлении, поэтому любые выгоды от переноса материала на модели / контроллеры довольно минимальны, так зачем беспокоиться?
Я слышал аргумент, что MVC вводит снижение производительности, но мне кажется, что это преждевременная оптимизация, и что есть более важные проблемы производительности, которые нужно решить, прежде чем беспокоиться о накладных расходах MVC (например, конвейер рендеринга, алгоритмы AI, структура данных). обход и т. д.).
То же самое и с TDD. Я не часто вижу игры, в которых используются тестовые случаи, но, возможно, это связано с вышеуказанными проблемами проектирования (смешанное представление / бизнес) и тем, что сложно тестировать визуальные компоненты или компоненты, которые основаны на вероятностных результатах (например, работают в рамках физических симуляций) ).
Возможно, я просто смотрю на неправильный исходный код, но почему мы не видим больше этих «корпоративных» практик, используемых в игровом дизайне? Действительно ли игры настолько различны в своих требованиях, или это проблема людей / культуры (т.е. разработчики игр происходят из другого фона и, следовательно, имеют разные привычки кодирования)?