Как инкапсулировать пользователя на сервере?

Question

[historydev]

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

Для примера возьмём абстрактную игру, её суть - убить босса.
У босса есть здоровье.

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

Answer 1

[Сергей delphinpro]

Абстрактный ответ

Создаем таблицы в БД
games
id | user_id
bosses
id | game_id | health | ...

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

Comments

[historydev]

А если игроков пару десятков тысяч и все они бьют одного босса?
У меня нет опыта с высоконагруженными системами, пример это детские цифры конечно и к этому не относится, но для меня это уже много.

Мне вообще стоит беспокоиться на этот счёт или беру mariadb и не парюсь?
Как себя база чувствовать будет если поток запросов на уровне сокетов будет?

[Сергей delphinpro]

Владимир,

А если игроков пару десятков тысяч и все они бьют одного босса?

Вы написали что у каждого будет свой босс )

Но не суть. Вы спросили про идентификацию и привязку пользователя и его игры/босса. Я на это ответил.
Что касается хайлоада - то тут я хз.

Answer 2

[Adamos]

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

Comments

[historydev]

А разница? Нам ведь всё равно придётся хранить там данные для проверки, как при авторизации, нет?

[Adamos]

Владимир, где "там"? Какие "данные"? Дьявол в деталях. Для пользователя вы "все равно" храните данные и проверяете авторизацию, вопрос, требуется ли для вот этой конкретной задачи хранить что-либо еще. По описанному мной сценарию творить отдельную таблицу под здоровье боссов - не потребуется. Секретный ключ может тупо генерироваться из ID юзера, например.

[historydev]

Adamos, ID юзера статичен, здоровье нет, как мне на сервере потом понять, что здоровье действительно изменилось на -N допустим, а не на -N+2?

[Adamos]

Владимир, а как вы это собираетесь делать, читая из БД?
Разжевываю: вы пускаете юзера к боссу, передавая браузеру "у босса 20 хитов, дата, подпись".
Юзер бьет босса, браузер сообщает серверу: "ты мне вот докУмент давал про 20 хитов с подписью, и учти удар".
Сервер проверяет подпись, просчитывает удар, отдает браузеру "у босса 18 хитов, дата, подпись"...
И никаких баз.

[historydev]

Adamos,

просчитывает удар

- можно вот здесь подробнее?
А где тогда хранить удар, его тоже можно подменить?

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

Однако если юзать допустим сокет комнаты, оператива думаю будет улетать очень быстро, при большом кол-ве юзеров, redis тоже самое.

а как вы это собираетесь делать, читая из БД?

Довольно просто на самом деле, манипуляции с боссом производятся средствами end-поинта, клиент знает только адреса куда обращаться за ударом, где здоровье прочитать и т.д.

Хотелось бы тоже самое, но без базы и без триллионов оперативы.

Ваш вариант подходит, но я не понимаю как мне реализовать интерфейс для него в формате выше

[Adamos]

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

[historydev]

Adamos, А, я кажется понял, пересобрать токен без ключа с сервера не выйдет, соответственно и подмены быть не может, сразу всё будет понятно! Спасибо! Туплю.

Answer 3

[Saboteur]

Странный вопрос.
А где сейчас хранишь информацию об одном боссе?
Там же храни и про нескольких.