Как называется архиректура такой игры?

Question

[MegaMufa]

Добрый день.

Есть вот такая многопользовательская онлайн игра: travian.ru И я никак не могу понять, как устроена архитектура у подобных игр. Ее нельзя назвать пошаговой, но и она не является realtime приложением. Какая то событийно-ориентированная архитектура.

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

Неужели сервер по несколько раз в секунду обсчитывает все объекты в игровом мире (строящиеся здания, ресурсы, войска и тп)? И как это вообще выглядит?

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

Подскажите любые ресурсы, книги, статьи, которые помогут разобраться с ДАННЫМ типом архитектур. Я даже не знаю, что мне искать надо. Буду вам очень благодарен.

Answer 1

[Владлен Грачев]

По-моему, решение «в лоб» очевидно. Автора вопроса напрягают запросы от клиента, но, кажется, он неверно трактует их суть. Клиент не должен говорить серверу, что «постройка здания закончилась, запиши это». Он может сообщить о начале постройки и спросить: «а не завершилась ли постройка?». Завершается постройка без участия клиента.

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

Событие в очереди представляет собой некое описание события, а также метку времени, по которой событие должно произойти (например, здание строится 2 часа, значит в качестве метки будет записано время на два часа позже отправки запроса на постройку).

В бесконечном цикле сервер делает следующее: выбирает все события, время завершения которых уже наступило, и обрабатывает их: изменяет уровни/координаты объектов, пересчитывает характеристики, изменяет флаги, удаляет событие из очереди.

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

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

Comments

[MegaMufa]

Вот так гораздо понятнее, спасибо. А какое то общее название у такой архитектуры есть? Или как про нее инфу искать?

[Viktor Vsk]

@HaruAtari не думаю, что подобную "сущность" стоит описывать чем-то большим, чем "клиент-сервер".

[Владлен Грачев]

@HaruAtari, трудно сказать. Вообще, это все MMORTS по сути. И при поиске, пожалуй, отталкиваться нужно от этого. Первое, что попалось, например :: www.gamasutra.com/view/feature/2326/massively_mult... :: но даже не читал, честно говоря.

Answer 2

[protven]

Автор, почитайте уже форум упомянутой вами игры. Как человек игравший (и выигрывавший один из раундов) в травиан, могу сказать что на форуме есть отличные темы, которые описывают архитектуру игры. Навскидку - forum.travian.ru/showthread.php?t=66352

Там же на форуме можно по задавать вопросы.

Comments

[MegaMufa]

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

[protven]

Ну вот точный алгоритм серверной части вам ессно никто не раскроет, так как компания на этом деньги делает и это ее затраты на R&D. Поэтому единственное что остается, чтобы понять как все работает - это реверс-инженерия со стороны клиента. Если кратко, то ответ [b]
victorvsk [/b] очень похоже описывает и механику травиана.

Answer 3

[Алексей Лебедев]

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

Проходит это время и все это появляется на клиенте.

Но иногда время на клиенте идет медленнее, чем на сервере.
Более ресурсоемкий и надежный вариант - это отправка запросов на сервер каждые N секунд.
Игрок отправляет запрос и если что-то построилось, то выводится на клиенте.

Comments

[MegaMufa]

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

Answer 4

[Константин Китманов]

Советую проглядеть Making Isometric Social Real-Time Games with HTML5... — большая часть там про графику, но есть и про эту архитектуру ближе к концу.

Comments

[MegaMufa]

К сожалению, это - не то, что надо. Я глазами пробежался. Там он предлагает строить архитектуру основанную на запросах клиента. Я спрашиваю, сколько у меня денег - сервер считает и говорит. Т.е. действия происходият по инициативе клиента, а не сервера.

[sim3x]

@HaruAtari зато не надо просчитывать весь треш, который никто никогда не запросит

Answer 5

[Виталий Желтяков]

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

Comments

[MegaMufa]

Действтя должны происходить сами, а не по запросу клиента. Мир асинхронен. Если даже все игроки выйдут из игры - он продолжает "жить" сам оп себе.

[Константин Китманов]

Тогда надо юзать очередь сообщений с отложенной доставкой. Сообщения должны пинать сервер, чтобы он сделал расчеты и записал в бд новое состояние.

[MegaMufa]

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

В общих чертах понятно, а вот поконкретней - тупик. Я раньше ни с явой, ни с акторами знаком не был. Да вообще кроме веба ничего не писал. Вот и топчусь на месте.

Answer 6

[Viktor Vsk]

Работал когда-то с вот таки движком railorz.com/. Правда, видимо, уже давно не поддерживается. Игра - вот эта barbariansgame.com (тоже не знаю, работает ли)

Принцип похож - вся игра висит у клиента на бэкбоне. По событию отправляет запрос на сервер,а на сервере все выполняется в бэкграунде. Так же каждые несколько сотен миллисекунд идет синхронизация с сервером.