Методы снижения сложности программирования игр [закрыто]

Question

В свободное время программирую игры как хобби, разные вещи и на данный момент ничего сложного.Такие вещи, как 2D-шутеры, игры с плитками, головоломки и т. д.

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

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

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

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

Я часто задаюсь одними и теми же вопросами:

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

Answer 1

Ах, если бы на ваш вопрос был хороший ответ.Тогда разработка игр не была бы такой сложной, рискованной и трудоемкой.

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

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

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

Ничто из этого не характерно для игр, но эта проблема часто возникает в играх, поскольку существует так много разрозненных подсистем, к которым мы еще не разработали стандартные подходы.Если взять веб-разработку, то на самом деле существует лишь небольшое количество устоявшихся парадигм:«один файл шаблона/кода для каждого URI» чего-то вроде PHP или, может быть, подход «модель/шаблон представления/контроллер» RoR, Django и пары других.А вот в играх каждый катает свое.

Но одно ясно:вы не можете решить проблему, задав вопрос: «Как объекты общаются».Существует много разных типов объектов, и они требуют разных подходов.Не пытайтесь найти одно глобальное решение, подходящее для каждой части вашей игры — ввода, сети, звука, физики, искусственного интеллекта, рендеринга, сериализации — этого не произойдет.Если вы попытаетесь написать какое-либо приложение, пытаясь придумать идеальный интерфейс IObject, который подойдет для любой цели, вы потерпите неудачу.Сначала решите отдельные проблемы, а затем ищите общие черты, проводя рефакторинг по ходу дела.Ваш код должен быть пригоден для использования, прежде чем его можно будет даже считать пригодным для повторного использования.

Игровые подсистемы живут на том уровне, на котором им нужно, не выше.Обычно у меня есть приложение верхнего уровня, которому принадлежат объекты Graphics, Sound, Input и Game (среди прочих).Объект Game владеет картой или миром, игроками, неигроками, вещами, которые определяют эти объекты и т. д.

Отдельные игровые состояния могут быть немного сложными, но на самом деле они не так важны, как думают люди.Пауза может быть закодирована как логическое значение, которое, если оно установлено, просто отключает обновления AI/физики.Меню могут быть закодированы как простые наложения графического интерфейса.Таким образом, ваше «состояние меню» просто становится случаем приостановки игры и отображения меню и возобновления игры, когда меню закрыто - никакого явного управления состоянием не требуется.

Уменьшить связь между игровыми сущностями довольно легко, опять же, до тех пор, пока у вас нет аморфного представления о том, что такое игровая сущность, которое приводит к тому, что всему необходимо потенциально взаимодействовать со всем.Игровые персонажи обычно живут на Карте или в Мире, который, по сути, представляет собой пространственную базу данных (помимо всего прочего) и может попросить Мир рассказать ему о близлежащих персонажах и объектах, без необходимости хранить на них прямые ссылки.

В целом, вам просто нужно использовать хорошие правила разработки программного обеспечения для вашего кода.Главное — сделать интерфейсы небольшими, простыми и сосредоточенными на одном и только одном аспекте.Из этого естественным образом вытекает слабая связь и возможность сосредоточиться на меньших участках кода.