Вопрос о дизайне класса относительно серверной клиентской игры

Question

У меня вопрос относительно дизайна классов в игре. У меня уже была базовая c установка сервера, клиентского соединения и клиента. Моя цель - реализовать игру поверх этого. Игра представляет собой карточную игру, в которой игроки получают слово и должны его переводить. Первый игрок, ответивший на правильный перевод, получает очко. Я думаю о том, чтобы реализовать игровой класс, в котором происходят все логики c. Здесь вы можете увидеть мою текущую диаграмму классов (извините, если некоторые из logi c плохо прорисованы. Я только искал в Google свой путь по дизайну диаграммы классов, и это было лучшее, что я мог сделать)

моя диаграмма классов

Сервер получает в начале количество игроков, раундов и другие переменные, хранит экземпляр игры и инициализирует его переданными аргументами. В игре и там все логики c происходят при выборе следующего термина, поэтому отправьте и проверьте, кто отвечает правильно. Мои вопросы: как решить это правильным образом относительно отправки игры, например, текущего слова для перевода через функция трансляции. Моя первая идея заключалась в том, чтобы игра расширяла сервер, чтобы я мог использовать функцию трансляции сервера в игре. Но я не уверен, так как игра на самом деле не является экземпляром с сервера типов, а сервер содержит его экземпляр. Поэтому в отношении OOP это кажется неправильным. Еще меня беспокоит, имеет ли смысл, чтобы у сервера был список подключений, а игроки также имели подключение к своему клиенту. Можно ли решить эту проблему более элегантным способом?

* 1008 красивая и хорошо определенная структура классов?

Заранее благодарю за любую помощь.

Answer 1

Думаю, вы на правильном пути, и у вас хорошая интуиция, где это сделать.

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

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

• Сервер отвечает за сохранение основного состояния игры и прием входящих запросов клиента (игрока).
• Игра отвечает за основные игровые логи c.
• Клиент - это пользовательский интерфейс для запуска / запуска / взаимодействия с игрой. Клиент подключается к серверу.
• ... и т. Д.

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

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

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

Надеюсь, что это поможет!