Главная > AGP Game Platform, AJAX, Dojo Toolkit, ExtJS Framework, MMOG, MMORPG игры, веб-обзоры, Стартапы > WarAliance Game — постмортема проекта он-лайновой браузерной стратегии, часть 2.

WarAliance Game — постмортема проекта он-лайновой браузерной стратегии, часть 2.

5 января 2009

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

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

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

galactic_map_sectors

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

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

reload_period

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

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

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

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

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

mail_center

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

mail_context_menu

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

special_report

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

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

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

wa_multi_msg_and_chat

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

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

chat_wnd1

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

all_chat

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

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

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

  1. 5 января 2009 в 02:02 | #1

    Вторая часть тоже очень понравилась. Особенно хороши идеи по поводу внутри игрового обмена сообщениями и общения(чата). Действительно, если призадуматься, то многим(сказал бы даже всем, но уж не все я браузерные игры играл), стоило бы обратить внимание на эти идеи. Хотя в основном (как в статье и сказано) большинство браузерных игр и держится по популярности из за общего чата, где каждый не по теме ведет непонятный треп, знакомится (женятся — в Carnage такое видел 🙂 ), а про сам игровой процесс игроки уже и забыли. Геймплея нету, все туда заходят чтоб початится, поэтому и половина экрана — это по тематике оформленый чат и немного графики и текста, заставляющего игрока на что то щелкать, «думать» ( 🙂 ), покупать за реальные деньги какие то вещи крутые, чтоб был повод о чем потрепаться в чате. У автора статьи же, подход к игре немного другой, ощущается важность геймплея как такового, что для игр есть очень важной составляющей (основной). Спасибо, и ждем следующих частей статьи (полируя космолет, ведь надеюсь игра выйдет)

  2. 5 января 2009 в 02:06 | #2

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

  3. 5 января 2009 в 02:10 | #3

    Кстати odnoklasniki своего рода тоже браузерная игра 🙂 Да да, там нужна тоже стратегия определенная в поиске знакомых и друзей, появились платные вещи (кто богаче, у того картиночка возле фотки покруче), и очередной повод потрепаться обо всем этом через внутрисайтовые сервисы… Этим всем хотел сказать, что даже социальным сетям стоит пересмотреть свои методы предоставления обмена сообщениями и чата…

  4. 5 января 2009 в 03:36 | #4

    ждём ещё продолжения 🙂 и линку, которая работает.

  5. 5 января 2009 в 13:26 | #5

    Victor — да, вы совершенно правы. Есть некоторый симбоиз между этими классами проектов, более того, некоторые игры напрямую идут в подобие соцсети, как западные, так и частично наши — тот же SanCity, который я стремился превращать в социальный мир. К этой же области идут и форумные игры. Только, конечно, порядок игроков больше — холдинг Аструм только заявил про достижение миллионного игрока (при этом там несколько популярнейших игр), а вКонтакте и Одноклассники уже давно дошли и перешли даже 10м рубеж., я уже не говорю про гиганта Facebook

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

Комментирование отключено.
Developers.org.ua