SharedLogic. Общий игровой код для Unity-клиента и .NET-сервера
https://habr.com/ru/articles/918220/

Забавный концепт. Любопытная статья. Лично я предпочитаю тонкие клиенты. Но почитать про другие подходы всегда любопытно.

Единственное что хочется добавить к словам автора, что у подхода всё же есть недостаток. Пресловутые версии. Когда игру надо обновлять, то сервер должен обновится вместе с игрой. При значимых изменениях. Особенно с проверкой хешей. В статье я инфы про это не заметил, но это проблема shared logic в микросервисной архитектуре. Просто менее ярко выраженная, так как в микросервисной мы попадаем в «ад dll или ад версий». Так как у нас куча сервисов должна использовать одну и ту же версию shared logic микросервиса. И как следствие обновляться вместе с ним.

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

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

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

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

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

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

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

#новости