Хотя обновление базы данных кажется излишним, оно имеет преимущества, когда наступает время для масштабирования, поскольку вы можете иметь несколько веб-голов, говорящих с одним бэкэндом.
Еще большее беспокойство вызывает то, как вы сообщаете состояние игры клиентам. Хотя полное обновление состояния игры время от времени гарантирует, что любые изменения будут зафиксированы, и все клиенты останутся синхронизированными, даже если они пропустят сообщение, игровое состояние часто довольно велико.
Также учтите, что обычно вы хотите, чтобы сообщения игрового состояния вызывали анимацию или другие обновления дисплея, чтобы отобразить действие (например, при перемещении фигуры она не должна просто появляться в пункте назначения в большинстве случаев ... она должна двигаться). пересечь границу).
В связи с этим одно из решений, которое объединяет в себе лучшее из обоих миров, - это сохранение базы данных, которая собирает все действий , выполняемых в таблице, с последовательными идентификаторами. Когда клиент запрашивает обновление, он может передать все действия после последнего, о котором он знал, и клиент может «разыграть» ходы. Это означает, что даже в случае сбоя запроса он может просто повторить запрос, и ни одно из действий не будет потеряно.
Сервер также может поддерживать внутреннее представление игрового состояния из тех же данных. Он также может отклонять незаконные действия и предотвращать их попадание в таблицу игровых действий (и, таким образом, предотвращать неправильное обновление других клиентов).
Наконец, поскольку на сервере действительно «одно истинное» игровое состояние, клиенты могут периодически сверяться с этим (что позволит вам находить ошибки в коде вашего клиента или сервера). Поскольку серверная база данных должна считаться основной, вы можете повторно передать все игровое состояние любому клиенту, который получает неправильное состояние, поэтому незначительные ошибки клиента (потенциально) не разрушат работу (за исключением, возможно, паузы, пока загружается состояние).