Alpha-Beta-Release Blog

Приветствуем наших читателей! Сегодня я продолжу рассказывать о проекте WarAliance, начало читайте в этой статье.

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

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

Информация про все объекты на карте (имеется ввиду, общая информация вроде положения, типа объекта, название и т.п.) хранится в кеше на клиенте, мы использовали Dojo.storage, при логине игрока проверяется, есть ли в кеше информация, а если надо, она обновляется. Данные в дальнейшем используются для отрисовки карты без дополнительных обращений к серверу. Позже я применил этот же подход в следующем проекте, используя, правда, хранилище от browserpersistent.ru, а также реализовав два типа кеширования - для рисунков и данных, которые при загрузке заносятся в кеш и могут хранится даже между перезагрузками клиентского компьютера, управление же кешем есть как у пользователя (при логине можно установить настройки кеширования), так и на сервере - установив флаг кеша, можно заставить клиентов даже с заполненным кешем перезагрузит его, если информация обновилась.

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

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

Кстати, тема управления соединениями в случае комбинации периодических запросов и динамических  - ещё не решенная, в другом проекте я использовал ручное разнесение по времени интервалов, так, чтобы они не накладывались. Кроме этого, вступает в силу и ограничение браузера на количество одновременных HTTP-запросов к одному хосту. В общем - сложности есть, и их много. Буквально сегодня обсуждал с другим разработчиком тему специальной библиотеки - некоторой надстройки над обычным AJAX-ом для создания очередей, управления запросами и приоритетами (некое подобие QoS механизма) и т.п. А если еще вспомнить, что сюда бы добавить и автоматическое распределение запросов по серверам и проверку доступности и возможность офф-лайн работы - окажется, что это целый AJAX-движок получается. Некоторую работу в этом направлении мы уже ведём!

А в WarAliance была подобная, но сильно упрощенная библиотека, еще в первых альфа-версиях, которая работала поверх Dojo.io, и реализовывала как очередь запросов, так и управляла их исполнением, использовала предопределенные обработчики для разных типов запросов и единый координационный центр AJAX-вызовов. Если сначала предполагалось, что этот модуль будет центральным звеном и единой точкой связи с сервером, то в остаточном варианте мы все же отказались от этого, перенеся запросы, которые обновляют части страницы на использование встроенного в ExtJS механизма UpdateManager, и только оставшиеся служебные запросы работали через менеджер. В другом проекте я применял просто невидимый DIV тег, который периодически обновлялся при помощи UpdateManager-а, а серверный скрипт писал туда сразу JS код для исполнения. Схема достаточно простая и надежная, только есть некоторые тонкости в реализации выполнения скриптов в UpdateManager-е. В полную меру с некоторыми нюансами этого подхода мы столкнулись в другом проекте, Роза Ветров, о котором позже напишем также материал.

Теперь поговорим немного про общение, точнее - коммуникацию. Для онлайновых игр это одни из важнейших аспектов, кстати, один из ближайших материалов будет как раз посвящён этому вопросу и технической реализации в рамках разрабатываемой мною платформы для игр AGPsource. В проекте WarAliance мы реализовали несколько видов коммуникации. Центральным местом была система сообщений, некоторый приближенный аналог почтовой системы. Сюда приходили все сообщения игроку - как служебные (отчеты), так и письма от других игроков. К сожалению, в рамках ExtJS 1.1 тогда было затруднительно реализовать систему папок, поэтому в первоначальном виде был плоский список сообщений, которые имели ряд параметров - статус (прочитан/новое), тип сообщения и флаг важности. Это было первое серьезное применение самого навороченного компонента ExtJS - GridPanel. Как видно на скриншоте, получилось достаточно симпатично. Однако здесь были и первые подводные камни, например, мы так и не научились перегружать данные так, чтобы игрок не замечал мерцания, то есть, не вышло обойтись без полной перестройки таблицы. Это привело к тому, что при открывании письма таблица перестраивалась, так как менялся статус сообщения.

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

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

Для сообщений мы ввели понятие архива - если их было достаточно много, игроку реально сложно было управлять, даже имея возможность перелистывать список и сортировать его по полям (здесь особенности грида из ExtJS оказались как нельзя кстати). В том же Ogame, впрочем, как и в других играх, на число сообщений или наложен лимит (в Ogame сообщения старше 3-х суток просто удаляются, даже если вы их не прочитали еще), а сам список просто выводится по мере поступления. Но ведь сообщения, а именно служебные отчеты - это очень важный элемент игры, особенно, если вам необходимо реализовать возможности расширенной тактики и стратегии! Например, вы следите за игроком, постоянно изучая шпионажем его планеты - вам надо хранить все эти донесения разведки, сравнивать данные. Это уже элемент геймплея, причем высокоуровневый, это уже стратегия. Поэтому мы реализовали неограниченное количество сообщений, при этом добавив возможность архивирования - выделив одно или несколько сообщений, игрок отправлял их в архив, который в любой момент мог открыть, однако для сообщений была доступна только общая информация и возможность чтения. Технически это была отдельная таблица, планировалось даже использовать другой движок (например, Archive, который отлично справлялся бы с большим количеством сообщений, но медленный для выборки).

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

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

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

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

Сейчас я не буду останавливаться на технических моментах чата, он достаточно простой - с одной стороны простейший AJAX-запрос, отсылающий сказанную фразу, на стороне сервера, простейший, максимально легкий скрипт, складывающий сообщения в базу, а также сразу автоматически проверяющий и удаляющий устаревшие сообщения. И в окне чата второй скрипт, реализованный все тем же механизмом UpdateManager из ExtJS, который запрашивает и получает сразу отформатированную HTML-страницу. На сегодняшний день у меня есть ряд технологических соображений по кардинальной перестройке систем общения внутри игрового сервера, я их изложу в отдельном материале.

Хотя от возможности иметь один общий чат для всех мы все же не отказались - просто вынесли его на отдельную вкладку основного окна игры, и не стали писать собственное решение, предпочтя тогда (да, наверное, и сейчас) готовое и хорошо проверенное решение - FreePHPChat. Таким образом мы достигли логического разделения - игра и внутриигровые коммуникации происходят без отрыва от геймплея, а общий чат, который, по опыту, всегда вырождается в пустотрёп обо всем - вынесен на логически отделенное окно/вкладку.

Нда, что-то и вторая часть получилась достаточно длинной, придется оставить и на следующий материал немного. В общем, продолжение следует...

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

P.P.S. Этот проект не был бы без помощи и участия нескольких замечательных людей, которым я хочу выразить личную благодарность: Олег, Дима (gabby), Богдан (lizard) и Александр (White).