Как мне моделировать экономичную игру в коде?

Я хотел бы создать экономическую игру, основанную на древней цивилизации. Я не уверен, как это сделать. Если бы я работал над меньшей игрой, например, над «Space Invaders», у меня не было бы проблем с ее структурированием:

• Главный класс управления
• Графический класс
• Класс игрока
• Вражеский класс

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

Я создаю класс страны, который содержит группу городов?

Конечно.

Есть ли в городах много строительного класса, в большинстве есть классы людей?

Конечно.

Я делаю класс поиска пути, к которому игрок может получить доступ?

Конечно.

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

Вы, естественно, взяли концепции в своей голове и сгруппировали их в код согласно некоторым простым правилам:

• Отличается ли эта концепция в поведении или данных от других объектов, которые у меня уже есть? (Страны и люди имеют очень мало, если таковые имеются, значимых данных или поведения, поэтому они должны быть представлены различными типами в игре).
• Нужно ли мне даже манипулировать этой концепцией в коде значительным образом (если ваша игра имеет дело с отдельными людьми, вам может понадобиться этот Personкласс, но если игра заботится только о них в совокупности, как в более ранних версиях SimCity, вы может не нуждаться в этом типе, ни в экземплярах этого типа для создания картографии 1: 1 населения города ( int populationCountможет быть достаточно).
• Требует ли эта концепция государства ? Если это так, он должен быть как-то инкапсулирован, что позволяет мне хранить это состояние (класс), а не набор свободных функций. (Реализация поиска пути не имеет аналогичного объекта реального мира, но она требует отслеживания данных, например, какие узлы на карте уже рассмотрены, и это лучше сделать с помощью класса, чем хранить его в связке скрытых глобалов и создания автономных функций).

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

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

То, что вы описали (класс для каждого основного типа логического игрового объекта) имеет смысл для простой игры. Если вы впервые пишете игру такого типа, я бы посоветовал сделать это так.

Просто пара советов:

• Является ли плеер действительно отличается от врага ? Многие функциональные возможности, вероятно, будут одинаковыми, поэтому обычно они должны быть одного и того же класса или расширены из одного базового класса. Рассмотрим базовый класс AbstractPlayer с двумя подклассами HumanPlayer и AIPlayer - все общие функциональные возможности могут входить в AbstractPlayer .
• Предпочитаю настраивать объекты с композицией, а не наследованием. Не делайте ваши иерархии наследования слишком глубокими. Если вы начнете вызывать класс ForgeWithSteelAnvil, вам следует беспокоиться: Forge может быть подклассом Building , но тип используемого наковальни должен быть объектом, содержащимся в здании.
• Точно так же предпочитают свойства, которые позволяют вам настраивать объекты, а не добавлять сотни немного разных классов объектов.

В более сложных играх можно использовать более продвинутые методы, но я советую не использовать их, пока вы не освоитесь с базовым подходом ООП (то есть успешно выполнили пару завершенных игр). Более продвинутые подходы могут включать:

• Прототипные объектные модели - используйте один класс для всех игровых объектов и моделируйте все свои объекты с помощью свойств / атрибутов и композиции. Гораздо более гибкий / динамический, чем стандартный ООП, но сложнее в управлении (в частности, компилятор не сильно вам поможет, если вы сделаете что-то глупое). Я использовал это с хорошим эффектом в моей маленькой Roguelike-игре Tyrant ( https://github.com/mikera/tyrant )
• Компонентные системы Entity - хорошо, если у вас есть много сложных поведений, которые вы хотите смешать и сопоставить во многих различных типах игровых объектов. Очень мощный, но трудно получить право.

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

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