Я хотел бы создать экономическую игру, основанную на древней цивилизации. Я не уверен, как это сделать. Если бы я работал над меньшей игрой, например, над «Space Invaders», у меня не было бы проблем с ее структурированием:
- Главный класс управления
- Графический класс
- Класс игрока
- Вражеский класс
Я не понимаю, как бы я сделал это для более крупных проектов, таких как моя экономическая игра. Я создаю класс страны, который содержит группу городов? Есть ли в городах много строительного класса, в большинстве есть классы людей? Я делаю класс поиска пути, к которому игрок может получить доступ?
java
architecture
Мэтью Г.
источник
источник
Ответы:
Конечно.
Конечно.
Конечно.
Все, что вы предложили выше, кажется разумным. Это может быть не лучшим способом для вас в долгосрочной перспективе, но это нормально. Это, очевидно, имеет смысл для вас, поскольку именно организационная модель впервые пришла к вам. Важно, что вы берете это и начинаете реализацию с этого. Это поможет вам начать работу, преодолеет этот первоначальный «паралич дизайна», который часто мучает разработчиков в начале задачи, и (если он окажется ошибочным в некотором роде) научит вас кое-чему о плюсах и минусах этого конкретного подхода к дизайну.
Вы, естественно, взяли концепции в своей голове и сгруппировали их в код согласно некоторым простым правилам:
Personкласс, но если игра заботится только о них в совокупности, как в более ранних версиях SimCity, вы может не нуждаться в этом типе, ни в экземплярах этого типа для создания картографии 1: 1 населения города (int populationCountможет быть достаточно).Несмотря на простоту, ответы на эти вопросы могут принести вам большую пользу, когда вы решаете, следует ли преобразовывать ментальную концепцию в исходный код. Вы также можете прочитать о принципах SOLID объектно-ориентированного проектирования.
Обратите внимание, что предложение системы сущностей / компонентов, сделанное в комментариях, также является допустимым подходом, хотя я бы отказался от него здесь, если вы не измените масштаб своего проекта на меньший (просто потому, что принятие двух новых больших задач в одном проекте может быть слишком пугающим и может ослабить образовательную выгоду, которую вы иначе получили бы, сосредоточившись только на одной). В компонентно-ориентированной модели «тип» в приведенных выше вопросах становится более неявным: не конкретный тип в коде, а неявный тип, определяемый набором компонентов, образующих сущность. Могут применяться те же руководящие принципы.
источник
То, что вы описали (класс для каждого основного типа логического игрового объекта) имеет смысл для простой игры. Если вы впервые пишете игру такого типа, я бы посоветовал сделать это так.
Просто пара советов:
В более сложных играх можно использовать более продвинутые методы, но я советую не использовать их, пока вы не освоитесь с базовым подходом ООП (то есть успешно выполнили пару завершенных игр). Более продвинутые подходы могут включать:
источник
Есть несколько методов, которые вы можете использовать для организации ваших сущностей и наборов данных. Я предпочитаю писать электронные таблицы и тестировать данные, перемещаясь вперед и назад, чтобы убедиться, что я работаю эффективно. Если вы делаете игру самостоятельно, помните, что она должна иметь для вас смысл. Иногда самый эффективный маршрут должен быть немного менее эффективным в коде, чтобы сделать проект проще.
Если вы хотите получить дополнительную помощь по структурированию контента, найдите старый исходный код игры, который использует похожую структуру или стиль, и найдите их решение. Затем уточните и исправьте по своему вкусу.
источник