Проблемы объектно-ориентированных приложений в разработке игр

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

Я думаю, вам следует использовать предложенный вами подход warpPlayer(player, position). Он поддерживает класс Player в чистоте. Если вы не хотите передавать игрока в функцию, возможно, вы могли бы иметь класс PlayerController, содержащий объект Player и метод warp(Position p). Таким образом, вы можете добавить публикацию событий в контроллер и не включать ее в модель.

Что касается сохранения плеера, я бы сделал это, заставив Player реализовать какой-то интерфейс сериализации. Класс player отвечает за сериализацию и десериализацию самого себя, а какой-то другой класс будет отвечать за запись сериализованных данных в/из файла.

Советую не опасаться того, что игрок будет классом геттеров и сеттеров. Что вообще такое объект? Это компиляция атрибутов и поведения. На самом деле, чем проще ваши классы, тем больше преимуществ ООП вы получите в процессе разработки.

Я бы разбил ваши задачи/функции на такие классы:

Игрок:

• имеет атрибут хитпойнтов
• имеет атрибут позиции
• может ходить по (позиция), запуская события «ходьба»
• может лечить(хитпойнты)
• может получать урон (очки жизни), вызывая событие "isHurt"
• можно проверить на живость, например метод isAlive()

Fighter расширяет Player (вы должны иметь возможность превратить Player в Fighter, когда это необходимо):

• имеет силу и другие боевые параметры для расчета урона
• может атаковать () запуская событие «атака»

Мир отслеживает всех игроков:

• прослушивает события «прогулки» (и предотвращает незаконные движения)
• слушает события «isHurt» (и проверяет, живы ли они)

Battle обрабатывает сражения между двумя бойцами:

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

PlayerPersister расширяет AbstractPersister:

• сохраняет состояние игрока в базе данных
• восстанавливает состояние игрока из базы данных

Конечно, разбивка вашей игры будет намного сложнее, но я надеюсь, что это поможет вам начать думать о проблемах с точки зрения «более ООП» :)

Я, вероятно, подумал бы о том, чтобы иметь объект Game, который отслеживает объект игрока. Таким образом, вы можете сделать что-то вроде game.WarpPlayerTo(WarpLocations.Forest); Если есть несколько игроков, возможно, передайте объект игрока или руководство с ним. Я чувствую, что вы все еще можете оставить его ООП, и я думаю, что игровой объект решит большинство ваших проблем.

Проблемы, которые вы описываете, относятся не только к дизайну игр, но и к архитектуре программного обеспечения в целом. Обычный подход заключается в использовании механизмов Injection Dependency Injection (DI) и Inversion of Control (IoC). Короче говоря, вы пытаетесь получить доступ к локальному типу Service из ваших объектов, чтобы, например, распространять какое-либо событие (например, деформацию), журнал и т. д.

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

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

В этом случае я бы посоветовал вам спроектировать данные, которые необходимо синхронизировать между всеми клиентами, и хранить их в одном классе (например, GameState). Этот объект будет обрабатывать всю синхронизацию между разными ПК, а также позволит вашему локальному коду запрашивать изменения данных. Затем он будет «управлять» игровыми объектами (Player, EnemyTank и т. д.) из своего собственного состояния. [редактировать: причина этого в том, что сохранение этого состояния как можно меньшим и его эффективная передача между клиентами будет ключевой частью вашего дизайна. Хранение всего этого в одном месте делает это намного проще и побуждает вас помещать в этот класс только самое необходимое, чтобы ваши сообщения не раздувались ненужными данными]

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

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

Иногда хитрость в ООП заключается в понимании того, что такое объект и какова функциональность объекта. Я думаю, что часто нам довольно легко концептуально зацикливаться на таких объектах, как Player, Monster, Item и т. д., как на «объектах» в системе, а затем нам нужно создавать такие объекты, как Environment, Transporter и т. д., чтобы связать эти объекты вместе, и это может выйти из-под контроля в зависимости от того, как концепции работают вместе, и что нам нужно выполнить.

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

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

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

Я хотел бы расширить последний абзац GrayWizardx, чтобы сказать, что не все объекты должны иметь одинаковый уровень сложности. Для вашего проекта вполне может подойти объект, представляющий собой простой набор свойств get/set. С другой стороны, важно помнить, что объекты могут представлять задачи или наборы задач, а не объекты реального мира.

Например, объект игрока может не отвечать за перемещение игрока, а вместо этого представлять его позицию и текущее состояние. Объект PlayerMovement может содержать логику для изменения положения игрока на экране или в игровом мире.

Прежде чем я начну просто повторять то, что уже было сказано, я укажу на принципы SOLID ООП-дизайна (о двух из них уже упоминал Авиад П.). Они могут предоставить некоторые общие рекомендации по созданию хорошей объектной модели для игры.