Построение виртуальных миров MMO. Часть 1.

В данной статье мы собираемся обсудить структуру Виртуального Мира ММО (*), предлагающего типичные инструменты сообщества (виртуальный чат, списки контактов, магазин, игры, торговые инструменты, и другие), которые могут быть найдены в приложениях данного жанра. (Habbo Hotel, Mokitown, Club Penguin...)

(*) = Массовая Многопользовательская Онлайн (Игра / Сообщество / Ролевая игра)

Существует множество сокращений, которые определяют разные жанры MMO (MMOG, MMOC, MMORPG, MMOFPS...).


Немного истории

В последние 2-3 года наблюдается заметный рост ММО Сообществ, основанных на флеш-технологии, вдохновленных такими популярными сайтами как Habbo Hotel, Mokitown и подобными виртуальными мирами.

За всеми этими приложениями стоит идея создания крайне интерактивного мира, где пользователи могут не только встречаться и общаться, но также создавать индивидуально настраиваемые «пространства» (комнаты, квартиры, дома), играть в онлайн игры (одно- и многопользовательские), размещать фотографии и обмениваться ими, и многое другое.

В ранний период ММО сообщества были основаны главным образом на «толстых клиентах» (исполнительные файлы, зависимые от платформы, обычно только для Windows), которые пользователи вынуждены были скачивать, устанавливать на своем компьютере и запускать.

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

Среди тех первых экспериментов были DeviousMUD, которые позже переименовали в RunEscape и Habbo Hotel. Обе игры MMOG быстро обрели чрезвычайную популярность, получив миллионы зарегистрированных пользователей по всему миру. Этот опыт вдохновил многие другие компании на изучение и экспериментирование с похожими технологиями, включая Macromedia Flash (сегодня Adobe Flash).

Вернувшись в 2001-2002 годах, технология Flash стремительно увеличивала популярность, но ей недоставало той же мощности визуализации как у конкурентов (это были дни Flash 5 и Flash MX). Помимо этого, Shockwave имел специализированную серверную технологию, предоставленную Macromedia (Shockwave Multiuser Server – многопользовательский сервер), которая помогала упростить разработку и внедрение онлайн игр MMOG.

Буквально в течение нескольких лет произошло очень быстрое развитие технологий, и сегодня Flash является ведущей платформой для любого типа приложений и игр, основанных на браузере, включая MMOG. Скорость визуализации значительно возросла с появлением 8-й версии флеш плеера и языков Actionscript 2.0 и 3.0, которые предоставляют мощную платформу для написания любого типа объектно-ориентированного кода.

На сегодняшний день последняя версия флеш плеера (версия 9), доступная для 3 основных операционных систем (Windows, MacOS X и Linux-x86), предоставляет переписанную виртуальную машину с новыми функциями, такими как JIT-компиляция, поддержка двоичных сокетов, усовершенствованная структура визуального программирования и поддержка видео.

Концепция: VirtuaPark



Чтобы проиллюстрировать архитектуру на основе подобного приложения, мы будем анализировать дизайн игры "VirtuaPark". Это вымышленное сообщество на движке MMO, имеющее настраиваемые пользователем аватары, которые взаимодействуют в средах наподобие 3D (изометрические), онлайн и оффлайн систему сообщений, систему торговли и различные многопользовательские игры, где пользователи могут бросать вызов друг другу.

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

Приложение стопроцентно будет основано на браузере с использованием флеш плеера.


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


Следующая диаграмма показывает, как организованы модули приложения:

Мы назначили четыре главных «модуля», которые позволят пользователю получить доступ к имеющимся функциям:

• Main Menu (главное меню). Оно представляет список всех доступных «инструментов» и «игр». После щелчка по одному из этих пунктов будет запущен инструмент/игра.

• Control Panel (панель управления). Панель, снабженная закладками, со следующими элементами управления:
o Chat History [История чата] (запись всех сообщений чата)
o Room List [Список комнат] (список доступных комнат/мест)
o User List [Список пользователей] (список доступных пользователей в текущем месте)
o My buddies [Мои друзья] (список друзей с их статусом онлайн/оффлайн)

• Chat Message Bar (строка сообщений чата). Простая строка управления, где пользователи могут печатать свои сообщения с помощью инструментов редактирования текста и добавления смайлов.

• Avatar Chat (чат аватаров). Наиболее важная область приложения, в которой будут запускаться чат аватаров и многопользовательские игры. Avatar Chat будет обладать изометрическим видом с возможностью прокрутки в стиле Habbo и ей подобных. При запуске игры чат будет спрятан, а действие игры будет происходить на его месте.


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

1. пользователь щелкает по пункту Customize Avatar (настроить аватар) в главном меню;
2. инструмент загружен и запущен в новом окне внутри приложения;
3. пользователь изменяет внешний облик своего персонажа и подтверждает изменения;
4. инструмент посылает запрос SmartFoxServer, который в свою очередь сохраняет новый профиль в базе данных и посылает событие обратно модулю Avatar Chat, так что происходит обновление всех пользователей.


Примечание:

Создание основанного на мозаике изометрического движка для модуля Avatar Chat – дело обычное, но на его создание и интеграцию с сервером может уйти несколько месяцев кропотливого труда. Кроме того, для построения расположений чата обычно требуется редактор уровней, что добавляет еще несколько часов к разработке. Хорошо, что существуют аватарные движки сторонних организаций, такие как TheoAvatar компании TheoWorld, которые уже интегрированы с API библиотекой SmartFoxServer. Вы можете проверить демо-версию аватара здесь.

Приложение, основанное на модуле Shell

Настало время погрузиться в архитектуру MMO, и мы начнем делать это (как ни странно), с клиентской стороны. Чтобы модули приложения могли работать как одно целое, нам необходим специальный модуль, который выступает в роли связующего звена между всеми другими. Этот специальный модуль будет назван «Shell». Он представлен в следующей диаграмме:

Модуль Shell будет иметь много обязанностей:

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

• Загрузка/выгрузка модуля. Он будет загружать и активировать другие модули при запуске приложения, запускать дополнительные инструменты и выгружать те из них, которые больше не нужны.

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

• Управление пользовательским интерфейсом. Он будет управлять диалоговыми окнами и сообщениями об ошибке, которые поступают от сервера, что должно отображаться поверх остальных модулей. Он также может активировать/деактивировать модули. В случае важного сообщения или ошибки он должен прекратить взаимодействие модуля с приложением.

• Многоязыковая поддержка. Shell будет динамически загружать внешние языковые данные из базы данных или XML файла и, соответственно, заполнять все компоненты графического интерфейса пользователя (надписи, кнопки, списки, формы, т. д.). Таким способом мы также можем управлять локальными справочными страницами, сообщениями об ошибке и даже денежным обращением.

У вас будет большой выбор средств для разработки Shell и его модулей, так как SmartFoxServer поддерживает Actionscript 2.0 (начиная с Flash 6 до и Actionscript 3.0 (Flash Player 9, использующий Flash CS3 и Flex Builder 2). Если вы планируете использовать AS 2.0, мы также рекомендуем вам посмотреть SmartFoxBits, целый набор компонентов пользовательского интерфейса, который значительно может ускорить процесс создания прихожих, приложений чата, и т. д.

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

Идя от простого к сложному, у нас есть клиент, который соединяется с нашим сайтом VirtuaPark через браузер. Сайт вместе со всеми swf файлами и другими ресурсами может с комфортом управляться сервером Jetty web server, встроенным в SmartFoxServer. Со встроенным сервером вы можете легко обслуживать статическое содержимое и создавать динамические веб-страницы, используя регулярные апплеты Java/JSP servlets, или с помощью встроенного интерпретатора Python, чтобы ускорить процесс.

Расширение серверной части будет управлять запросами, поступающими от каждого модуля, чатом аватаров и играми, к тому же, оно будет заходить на сервер базы данных, чтобы сохранять и извлекать пользовательские данные, получать статус приложения и тому подобное. В данном сценарии настоятельно рекомендуется использовать инструмент ORM, чтобы помочь упростить доступ к постоянным данным и сделать кодирование сервера удобным. Инструменты Hibernate и IBatis, пожалуй, наиболее популярны в мире Java, но существует много других, которые вы можете проверить.

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

SmartFoxServer позволяет разработчикам с легкостью интегрировать такие инструменты с расширениями Java и расширениями скриптов (Actionscript и Python). Если вы планируете использовать последнее, то у вас будет возможность получить прямой доступ ко всем объектам ORM из ваших скриптов без необходимости дополнительно дописывать Java код.

Чтобы вы имели представление о том, насколько мощной является смесь скриптовых языков (в данном случае Python) с ORM, такими как Hibernate, здесь приводится фрагмент кода, показывающий метод простой регистрации, который извлекает пользователя из базы данных и получает доступ к некоторым его свойствам:
1. class ChatModule(object):
2. def handleReq(self, cmd, params, who, roomId):
3. print "Handling Chat Request: ", cmd
4.
5. class ShopModule(object):
6. def handleReq(self, cmd, params, who, roomId):
7. print "Handling Shop Request: ", cmd
8.
9. class GameModule(object):
10. def handleReq(self, cmd, params, who, roomId):
11. print "Handling Game Request: ", cmd
12.
13.
14. handlersTable = {}
15.
16. def init():
17. global handlersTable
18.
19. print "Initializing"
20.
21. # Instantiate modules
22. chatModule = ChatModule()
23. shopModule = ShopModule()
24. gameModule = GameModule()
25.
26. # Add modules to the handlers table
27. handlersTable["chat"] = chatModule
28. handlersTable["shop"] = shopModule
29. handlersTable["game"] = gameModule
30.
31.
32. def destroy():
33. print "Stopping"
34.
35. #
36. # Handle client requests
37. #
38. def handleRequest(cmd, params, who, roomId, protocol):
39. separatorPosition = cmd.find("##")
40.
41. # Look for the separator
42. if separatorPosition > -1:
43. moduleName = cmd[0:separatorPosition]
44. reqName = cmd[separatorPosition + 2:]
45.
46. # Get the handler module and pass the request parameters
47. if handlersTable.has_key(moduleName):
48. handler = handlersTable[moduleName]
49. handler.handleRequest(reqName, params, who, roomId)
50.
51. else:
52. print "Unknown Module: ", moduleName
53.
54. else:
55. print "Invalid request: ", cmd
56.
57. #
58. # Handle server events
59. #
60. def handleInternalEvent(evt):
61. pass
62.

Инструмент Hibernate позволяет запрашивать объекты в базе данных с использованием языка, подобного SQL, который называется HQL. Как вы можете видеть, вместо длинной записи SQL выражений, нам просто нужно определить критерий для поиска. После извлечения объекта мы получаем доступ ко всем его полям (включая поля, отображенные на связанных таблицах) простыми механизмами получения и установки.

Расширение серверной части

Серверное расширение – это ядро приложения и, пожалуй, наиболее сложная часть для построения. Как уже было отмечено в предыдущих диаграммах, мы будем запускать игру VirtuaPark в ее собственной Зоне и будем использовать единственное расширение, внедренное на уровне зоны.
(Если вы не знакомы с базовыми понятиями структуры SmartFoxServer, мы предлагаем вам ненадолго оторваться от чтения и просмотреть статьи, которые можно найти в 4 главе нашей документации).

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

Ниже визуально представлено решение:

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

Чтобы этот механизм заработал, нам необходимо установить соглашение о присваивании имен между клиентом и сервером для имен запросов. Может быть, вы помните, что каждое сообщение расширения, отправленное и полученное сервером, имеет свойство cmd, которое определяет имя команды (запроса).

Применительно к нашей игре VirtuaPark мы будем использовать следующее соглашение:

moduleName##requestName

где:
• moduleName: имя целевого модуля;
• ##: разделитель;
• requestName: имя запроса для целевого модуля.

Здесь приведено несколько примеров запросов, основанных на вышеупомянутом соглашении:

chat##moveAvatar
profile##storeData
shop##buyItem

Следующий пример кода на языке Python должен прояснить весь процесс:

1.
2. class ChatModule(object):
3. def handleReq(self, cmd, params, who, roomId):
4. print "Handling Chat Request: ", cmd
5.
6. class ShopModule(object):
7. def handleReq(self, cmd, params, who, roomId):
8. print "Handling Shop Request: ", cmd
9.
10. class GameModule(object):
11. def handleReq(self, cmd, params, who, roomId):
12. print "Handling Game Request: ", cmd
13.
14.
15. handlersTable = {}
16.
17. def init():
18. global handlersTable
19.
20. print "Initializing"
21.
22. # Instantiate modules
23. chatModule = ChatModule()
24. shopModule = ShopModule()
25. gameModule = GameModule()
26.
27. # Add modules to the handlers table
28. handlersTable["chat"] = chatModule
29. handlersTable["shop"] = shopModule
30. handlersTable["game"] = gameModule
31.
32.
33. def destroy():
34. print "Stopping"
35.
36. #
37. # Handle client requests
38. #
39. def handleRequest(cmd, params, who, roomId, protocol):
40. separatorPosition = cmd.find("##")
41.
42. # Look for the separator
43. if separatorPosition > -1:
44. moduleName = cmd[0:separatorPosition]
45. reqName = cmd[separatorPosition + 2:]
46.
47. # Get the handler module and pass the request parameters
48. if handlersTable.has_key(moduleName):
49. handler = handlersTable[moduleName]
50. handler.handleRequest(reqName, params, who, roomId)
51.
52. else:
53. print "Unknown Module: ", moduleName
54.
55. else:
56. print "Invalid request: ", cmd
57.
58. #
59. # Handle server events
60. #
61. def handleInternalEvent(evt):
62. pass
63.

Мы назначили 3 простых класса (ChatModule, ShopModule и GameModule), которые представляют модуль чата, модуль магазина и игровой модуль соответственно. Каждый класс имеет метод handleReq, который будет вызываться главным файлом расширения.

В методе init() нашего расширения мы подвергли обработке все три класса и добавили их в глобальный справочник, называемый handlersTable. (Справочник в языке Python эквивалентен ассоциативному массиву / HashMap)

После получения запроса клиента методом handleRequest() мы проделаем следующее:

• Найдем разделитель ##;
• Разложим строку cmd на имя модуля и имя запроса (помните установленное нами соглашение?);
• Проверим, существует ли нужный модуль в handlersTable;
• Наконец, отправим запрос модулю.

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

1. public interface ModuleRequestHandler
2. {
3. public void init();
4. public void destroy();
5. public void handleRequest(String cmd, JSONObject params, User user, int roomId);
6. }

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

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

Во второй части данной статьи мы проанализируем оставшиеся части мозаики и предоставим дальнейшие советы по разработке.