Як я можу моделювати гру на основі економії в коді?

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

• Основний клас управління
• Графічний клас
• Клас гравців
• Клас ворога

Я не розумію, як би я зробив це для великих проектів, таких як моя економічна гра. Чи потрібно створити клас країни, який містить купу міст? Міста містять багато будівельних класів, більшість містять класи людей? Чи потрібно робити клас пошуку шляхів, до якого гравець може отримати доступ, щоб обійти його?

Чи потрібно створити клас країни, який містить купу міст?

Звичайно.

Міста містять багато будівельних класів, більшість містять класи людей?

Звичайно.

Чи потрібно робити клас пошуку шляхів, до якого гравець може отримати доступ, щоб обійти його?

Звичайно.

Все, що ви запропонували вище, здається розумним. Це може бути не найкращим способом для вас у довгостроковій перспективі, але це добре. Ви, очевидно, має сенс знати, оскільки саме організаційна модель вперше прийшла до вас. Важливо, щоб ви взяли це і почали з нього реалізовувати. Ви почнете, як розпочати, переконуючись над цим початковим «паралічем дизайну», який часто наштовхує розробників на початку завдання, і (якщо він виявиться дефектом якимось чином) навчить вас речі або дві про плюси і мінуси саме цього підходу до проектування.

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

• Чи суттєво відрізняється ця концепція за поведінкою або за даними інших об'єктів, які я вже маю? (Країни та люди діляться дуже мало, якщо такі є значущими даними чи поведінкою, тому вони повинні бути представлені різними типами в грі).
• Мені навіть знадобиться маніпулювати цією концепцією в коді суттєво (якщо ваша гра стосується окремих людей, вам може знадобитися цей Personклас, але якщо гра піклується про них лише в сукупності, як і в попередніх версіях SimCity, ви може не знадобитися цього типу, а також випадків цього типу для створення карти 1: 1 для населення міста int populationCount.
• Чи потрібна ця концепція держави ? Якщо це так, його слід якось інкапсулювати, що дозволяє мені зберігати цей стан (клас), а не купу вільних функцій. (Реалізація маршрутизації не має аналогічного об'єкту реального світу, але для цього потрібно відслідковувати дані, наприклад, які вузли на карті вже розглядалися, і це краще робити через клас, ніж зберігати його в купі прихованих глобалів і виконання самостійно функцій).

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

Зауважте, що пропозиція системи суб'єкта / компонентів, зроблена в коментарях, також є коректним підходом, хоча я б тут не відхилявся, якщо ви не переобладнаєте свій проект на менший розмір (просто тому, що в одному проекті можуть бути дві нові великі проблеми бути занадто непростим і може погіршити освіту, яку ви в іншому випадку отримаєте, якщо зосередитися лише на одному). У моделі, орієнтованої на компоненти, "тип" у вищезазначених питаннях стає більш неявним: не конкретний тип у коді, а неявний тип, визначений колекцією компонентів, що утворюють ціле. Можуть застосовуватися ті самі керівні принципи.

Те, що ви описали (клас для кожного основного типу логічного ігрового об’єкта) має ідеальний сенс для простої гри. Якщо ви вперше пишете гру такого типу, я б запропонував зробити це так.

Кілька порад:

• Чи справді гравець відрізняється від Ворога ? Багато функцій, ймовірно, будуть однаковими, тому вони, як правило, повинні бути одного класу або розширені з одного базового класу. Розглянемо базовий клас AbstractPlayer з двома підкласами HumanPlayer та AIPlayer - всі загальні функціональні можливості можуть входити в AbstractPlayer .
• Віддайте перевагу конфігуруванню об'єктів композицією, а не успадкуванням. Не робіть надто глибокими ієрархії спадщини. Якщо ви почнете викликати клас ForgeWithSteelAnvil, то ви повинні турбуватися: Forge може бути підкласом Building , але тип використовуваної ковадлі повинен бути об'єктом, що міститься в будівлі.
• Так само віддайте перевагу властивостям, які дозволять вам конфігурувати об'єкти, а не додавати сотні дещо різних класів об'єктів.

У більш складних іграх є більш вдосконалені методи, які ви можете використовувати, але я пропоную не використовувати їх до тих пір, поки вам не дуже зручно використовувати базовий підхід OOP (тобто ви зробили пару завершених ігор успішно). Більш досконалі підходи можуть включати:

• Моделі об'єктів на основі прототипу - використовуйте єдиний клас для всіх ігрових об’єктів та моделюйте всі свої об’єкти за властивостями / атрибутами та композицією. Набагато гнучкіший / динамічніший, ніж стандартний OOP, але складніше в управлінні (зокрема, компілятор не дуже допоможе вам, якщо ви зробите щось дурне). Я використовував це для хорошого ефекту в моїй маленькій грі Roguelike Tyrant ( https://github.com/mikera/tyrant )
• Компонентні системи Entity - добре, якщо у вас є багато складних способів поведінки, які ви хочете змішати і співставити в багатьох різних ігрових об'єктах. Дуже потужний, але важко поправитись.

Існує небагато методів, за допомогою яких можна підходити до організації ваших організацій та наборів даних. Я вважаю за краще написати документ з електронних таблиць і перевірити дані, що рухаються вперед і назад, щоб переконатися, що я ефективний. Якщо ви створюєте гру самостійно, пам’ятайте, що вона повинна мати для вас сенс. Іноді найефективнішим маршрутом є бути трохи менш ефективним у коді, щоб зробити проект простішим.

Якщо ви хочете отримати додаткову допомогу щодо структурування вмісту, знайдіть старий вихідний код гри, який використовує подібну структуру чи стиль, і знайдіть їх рішення. Потім вдосконаліть його і зафіксуйте на свій смак.