Встала проблема организации кода игры, хочется написать сразу грамотно, да не знаю как, может быть есть какие - то паттерны?
В игре есть игровые экраны, с функциями Update и Render, которые выполняются бесконечно. Также в игре есть игровые объекты типа карты, юнитов и зданий. Вопрос заключается в том, как всеми этим управлять?
У меня есть два варианта структуры кода.
1) Игровой экран напрямую управляет объектами. Но в нём я очень сильно сомневаюсь.
2) Игровой экран косвенно управляет объектами, через специальный класс, например Engine. То есть Экран управляет Engine, а Engine управляет объектами. Но и в этом варианте я сильно сомневаюсь, уж больно напоминает фильм "Начало", также и здесь, класс в классе в третьем классе.
Быть может у Вас есть свои варианты? Литературу просьба не советовать, уже пару книг читаю по этому вопросу, просто необходимо срочно знать ответ.
1. Единственного правильно ответа нет.
2. Сразу грамотно ещё никто никогда ничего не писал, не нужно надеяться и/или переживать. Если проект учебный, то просто пишите.
3. Если «экран» — это то, что отвечает за отрисовку игры, то он точно не должен управлять логикой.
4. Если возникают проблемы с определением того как управлять набором объектов, проще всего ввести дополнительную абстракцию (как Ваш вариант 2), только назовите не Engine (слишком уж обще), а, например, UnitsManager — все команды, касающиеся юнитов шлите ему, а он внутри уже пусть сам разберётся. Это позволит разделить всю логику на две независимые части (одна делает всё с юнитами, другая с ними ничего не делает), что упростит восприятие архитектуры.
А что управляет взаимодействием UnitsManager? И в таком случае необходимо будет сделать контролер, которые совмещает действия других таких же классов. Уже слишком сложная структура получается...
Экран - в данном случае имелось ввиду состояние игры, меню, пауза, сама игра.
К тому же мы уже успели в прошлых проектах наговнокодить, сейчас структура проекта кажется идеальной (по крайней мере с ней удобно работать), но не хватает винтика, который бы управлял и связывал все части этого кода.
>в таком случае необходимо будет сделать контролер, которые совмещает действия других таких же классов.
Зачем?
>не хватает винтика, который бы управлял и связывал все части этого кода.
Вы хотите написать «САМЫЙ ГЛАВНЫЙ КЛАСС»? :-) Он необязательно нужен.
Вообще, такоой подход неверен. Эстетисческая составляющая и желания разработчиков не существенны. Какую проблему Вы хотите решить этим классом? Если есть конкретная проблема, то решайте, если нет — забейте. «Нам не хватает винтика…» — это не проблема.
Могу ошибаться, т.к. в целом на данный момент экспериментирую в том же направлении.
Для себя реализовал это примерно следующим образом:
1) GUI - видимо то, что вы понимали под "экранами". Графический интерфейс с отрисовкой и точками входа для действий пользователя (KeyListener и иже с ними). Никакой логики здесь нет, только соответствующая отрисовка.
2) Engine, грубо говоря - "движок": здесь содержится вся игровая логика. Карты, юниты, итемы, состояния и прочее. Все взаимодействия между объектами и экземплярами классов - описаны здесь.
3) Непосредственно Game - непосредственный "поток", включаемый по запуску приложения, который обуславливает взаимодействие GUI и Engine. Здесь инициализируется запуск Engine и GUI, а дальше по мере получения информации от движка и\или "экранов" - нужным образом обрабатывается взаимодействие.
Но, как я уже говорил, на правильность подобного деления не претендую.
Средний
