Общий концепт

Шляпа

1. Игра заключается в коммуникации между игроками, цель которой - объяснить как можно больше слов за ограниченный промежуток времени.
2. Название произошло из традиции писать слова на бумажках и класть их в шляпу, из которой они потом достаются во время объяснения

Довольно очевидно, что такой концепт плохо ложится в дистанционную игру. Уже существует некоторое количество приложений для избавления от шляпы, которые нас категорически не устроили. Суть их всех в том что телефон передаётся по кругу, что совершенно неприемлимо в наше время, в силу пандемии и очень большой связанности пользователя со своими девайсами.

И тогда мы решили создать приложение, которое позволяет играть в игры про взаимодействие между людьми, и предоставляет интерфейс. В случае шляпы приложение выполняет роль "шляпы", которая может находиться в нескольких местах одновременно, при чём она берет на себя ответственность определения порядка ходов, подсчёта очков и некоторые другие вещи, которые упрощают жизнь.

Архитектура

Server

Решает все вопросы, связанные с логикой игр и управлением лобби

• Services - абстракция над GRPC.
• Routing - не знает от GRPC, хранит игры, управляет клиентами, предоставляет все необходимые сервисы игрым
• Games - реализации игр

Стандартная точка входа DI - startup.cs

Client-lib

Предоставляет абстракции на GRPC-api, и некоторые инструменты, упрощающие работу с кодом

• Client - решает вопросы, возникающие перед созданием лобби, создает лобби (выбор ника, авторизация)
• Lobby - решает вопросы управления лобби (смена ролей, запуск игры)
• Game - решает вопросы взаимодействия с доменной моделью игры, выполняемой на сервере

Shared

DTO, которые используются для работы по GRPC (собираюются с использованием protobuf-net.GRPC) Также некоторый общий код

Test-server

Тесты на домен

Client

Первичная реализация клиента, работавшая в терминале (используется как референс)

AndroidClient

Реализация клиента под Android с использованием Xamarin

Стандартная точка входа DI - Application.cs

В игре есть 3 этапа:

• PreLobby
  • Выбор имени
  • Работает на PreLobbyViewModel
  • Все связанные представления лежат в PreLobbyView
• InLobby
  • Сбор игроков в Lobby
  • Выбор ролей
  • View модели и представления аналогично
• InGame
  • Работа игры
  • View модели и представления аналогично

Точки расширения

• Весь проект был создан для одной главной цели: обеспечить систему для организации сетевых пошаговых игр.
  • На сервере нужно унаследоваться от абстрактого класса Game
  • На клиенте надо реализовать соответствующие вьюмодели
• Для конкретной игры легко добавить новые команды
  • Нужно добавить DTO в Shared
  • Добавить обработчики в вьюмодели
  • Добавить обработчики в игру на сервере
• Легко добавить новый тип сообщений в цепочку обработчиков
  • Достаточно вызвать метод AddMessageType у IServiceCollection в Startup

Слои на сервере

Сервисы

Очень тонкий слой (измеряли линейкой), представлен классом MainService, существенная часть задач, которые могли бы попасть на этот слой, решает библиотека protobuf-net.grpc

Приложение

На этом слое происходит первичная работа с клиентами и отправка клиентов в соответствующие им комнаты, а также передача событий между клиентом и доменными сущностями

Домен

Домен состоит из нескольких областей:

• Лобби - логика управления комнатами
• Игры - создаются из лобби, отделены друг от друга, отвечают за логику, специфичную для конкретной игры
• ChainOfResponsibilityUtils - логика, связанная с распределением событий по соответствующим обработчикам в доменной области