Как создать игру мечты
Разработка игры — трудный процесс. Он включает большое количество дисциплин, а не в состоянии значительного заимствовать из их обычных методик работы.
С позиции художества, созидательные люди (дизайнеры, артисты, беллетристы) сначала как правило формируют стандартную теорию собственного произведения и позднее прорабатывают компоненты, дополняют ей глубины. В подготовке же игры ваша базовая реализация игрового процесса изначально не действует, и требует нескольких итераций для усовершенствования. Во всех картинах просто нельзя принудить игру работать, и тогда бывает сложно отказаться от нее в пользу иного проекта.
С технологической же стороны способы, исследованные в институте, преимущественно не используются в подготовке игр. Техники ПО, на базе приобретенного тех. поручения, разрабатывают так именуемые сценарии применения. После создания данных сценариев все взаимодействия с клиентом делаются строго формализованными. Это далеко не действует в программировании для игр, в связи с тем что вы не менее сконцентрированы на чувствах, которые испытывает игрок, чем на том, что он будет делать.
Даже применение стандартов программирования не обещает работу платформы. Постоянно, как менеджер, я сталкиваюсь с разработчиками программного обеспечения, которые врут себе об удачном применении MVC в архитектурах их игр (и в итоге формируют общую тарелку со спагетти и фрикадельками).
Другой образец, когда разработчики программного обеспечения говорят, что с успехом работают, не применяя ООП внешний вид (впрочем они все-таки его применяют, не осознавая либо не признавая данного). Пальцев обоих рук не хватит, чтобы посчитать, насколько часто я с данным встречался.
Эти образцы скрещиваются с иной обстановкой, которую я видел большое число раз, когда разработчики программного обеспечения чересчур тревожатся о «наиболее верной реализации» и «хороших практиках в программировании». Это довольно часто ведет к тому, что код имеет лишние инкапсуляции, а заключительные приводят к кодовым базам, которые при изменении спецификаций, весьма трудно редактировать.
Если вы пишите игру, просто пишите код так оперативно и так просто как можно. Не тревожьтесь за внешний вид. Не используйте шаблоны разработки и инкапсуляцию для них лично. Сделайте код игры оперативно и нечисто и просто заставьте ее работать. Если в будущем с кодом является сложно работать, сделать его лучше. Если нет — не трогайте код.
Обычным доводом для сочинения вычищенного кода считается командная работа и большое количество разработчиков программного обеспечения, работающих над игрой. Основные разработчики программного обеспечения требуют элегантный и созданный код, являющийся причиной весьма медлительной подготовки. Игровой портал на сайте game-ss.ru поможет Вам при выборе или создании игры.
Доказательство такое: «Мы должны быть готовы сменить разработчиков программного обеспечения в любое время, таким образом код должен быть читабелен и готов для поддержки». В реальности такой метод отбирает значительно больше времени подготовки, и он едва ли выгоднее в продолжительной возможности.
Сделайте так, чтобы любой разработчик программного обеспечения в команде имел точную роль и область ответственности. Дайте им работать так, как им нравится, оперативно и нечисто, просто удостоверьтесь, что они формируют ясные API для коммуникации с иными разработчиками программного обеспечения. То что вы утратите в компании, вы намного выиграете в скорости подготовки.
Когда я работаю над Godot, я удостоверяюсь что внешний вид и архитектура так идеальны как вероятно. Когда я работаю над игрой, я хочу получить итог так оперативно как вероятно.
Очень многие читатели пожалуй указали, что Godot был основан для подготовки игр как раз подобным методом. Он улучшает рост мощности в первую очередь в дизайне. Работа системы сцен дает возможность использовать в подготовке игр подход «разделяй и властвуй» (вместо того чтобы волноваться о подобных глупых вещах, как MVC, разбиение на детали и т.д.).
Легкость GDScript дает возможность писать огромные кусочки кода которые «просто работают», и, когда они будут закончены, вы больше не будете к ним касаться. Завоевание «ощущения», что вещи располагаются на собственных местах, было целью, над который мы вместе с Ariel Manzur работали в течение многих лет, до того, как Godot стал open source подготовкой.