Масштабные многопользовательские интерактивные игры: Часть 1. Подход к определению размеров инфраструктуры

Выстраданные объективные рекомендации по структуризации проекта интерактивной игры

Масштабные многопользовательские игры (massively multiplayer online games - MMOG) определенно являются самыми сложными программными системами, разрабатываемыми в настоящее время. Они часто требуют работы десятков разработчиков и сотен художников, а также наличия действительно масштабных инфраструктур. Данная статья является первой в серии статей, которые прольют свет на системы, хранилища и сети, необходимые для запуска MMOG. В ней предоставлены введение в MMOG и единый подход к определению игровой инфраструктуры. Узнайте, как оценить необходимый объем инфраструктуры, а также как запустить MMOG.

Джордж Долбиер, главный разработчик, Games & Digital Entertainment, IBM

Джордж Долбиер (George Dolbier) является техническим руководителем группы IBM Games. Имеет десятилетний опыт работы в отрасли производства игр. Начинал с систем ввода данных, затем голосовых и текстовых чатов для игр, что в свою очередь привело к реализации и управлению интерактивными действиями не только для интерактивных игр, но и для сервис-провайдеров. Джордж пришел в индустрию игр, имея основательный опыт работы инженером-программистом в таких компаниях как Oracle, Informix и Sequent. В настоящее время он помогает IBM и индустрии игр понять друг друга.



03.01.2008

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

Основная таксономия отрасли (жаргон)

В киноиндустрии фильмы делятся на жанры (например, на боевики, приключения, драмы, романы, ужасы и комедии). Игры тоже классифицируются по жанрам, таким как шутеры от первого лица, логические игры, случайные игры (casual games), командные игры, ролевые игры, гоночные игры и симуляции. Но в отличие от кино игровая индустрия добавила новое измерение в свою классификацию по жанрам: разделение по способу игры и по возможности одновременно играть в нее более чем одному игроку.

Однопользовательские игры

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

Многопользовательские сетевые игры

Многопользовательские сетевые игры (multiuser dungeon, dimension, or domain (MUD)) обычно являются текстовыми, многопользовательскими, ролевыми играми. Такие игры позволяют нескольким пользователям зарегистрироваться на центральном сервере и совместно поучаствовать в приключениях, обычно при помощи текстового (не графического) интерфейса. Эти игры возвращают нас во времена консолей, мэйнфреймов и миникомпьютеров. MUD предшествовали не только PC-играм, но и самим персональным компьютерам. Согласно статье о MUD в Wikipedia, первая игра была запущена в 1977 (см. раздел "Ресурсы"). С точки зрения инфраструктуры MUD требует очень немногого по сравнению с другими видами игр, такими как интерактивные игры и MMOG-игры.

Многопользовательские интерактивные игры

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

Масштабные многопользовательские интерактивные игры

К MMOG относятся такие хорошо известные игры как EverQuest, World of Warcraft, EVE Online, Guild Wars и Lineage II. Эти игры разворачиваются глобально и поддерживают миллионы игроков. Данный тип игр требует создания наиболее сложной инфраструктуры, дублируемой и разворачиваемой в центрах обработки данных по всему миру. Сообщество разработчиков зачастую характеризует MMOG-игры как постоянные миры. С точки зрения инфраструктуры это одно и то же.

Постоянные миры

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

Масштабные социальные игры

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

Платформы

Игровая платформа - это устройство доступа к игре для конечного пользователя, в технических терминах обозначаемое также как сторона клиента. Основными игровыми платформами являются консоль, PC (персональный компьютер), карманный компьютер и мобильные устройства. Еще одна платформа, о которой обычно забывают упомянуть, - это игровые автоматы. В США индустрия игровых автоматов больше никогда не достигала такого расцвета как в конце 1970-х - начале 1980-годов. Однако игровые автоматы остаются популярными в Японии и в Азии. А с недавних пор серьезным бизнесом стали карманные и мобильные устройства. Будучи наиболее популярными в Азии и Европе, эти платформы в конце концов привлекли внимание крупных промышленных игроков, что следует из недавних приобретений. В данной статье мы остановимся на двух самых популярных игровых платформах: консоли и PC.

Игровые консоли

До сих пор многие люди, особенно вырастившие детей в последние 25 лет, прекрасно помнят об этой главной принадлежности телевизора. В начале 1980-х годов такой принадлежностью были Atari и Intellivision. Вторая половина этого же десятилетия дала нам Nintendo и Sega. В настоящее время такими принадлежностями являются Sony® PLAYSTATION®, Microsoft® Xbox и Nintendo.

Консольные игровые системы занимают огромный сегмент рынка игр в США, Японии и части Европы. Все современные консоли и консоли следующего поколения могут подключаться по широкополосным каналам. Но все же сегмент консольных игр еще должен доказать свою экономическую жизнеспособность.

С тех пор как два десятилетия назад Nintendo Entertainment System ворвалась на рынок, многие люди периодически предсказывали закат игр для PC. Эти люди не понимали экономики создания программного обеспечения. До тех пор, пока PC являются предметом потребления, экономическая привлекательность разработки игр для них останется.

"Gaming"

Вы, возможно, слышали о Nevada Gaming Commission и удивлялись, какое она имеет отношение к корейской игре Lineage II. Абсолютно никакого! "Gaming" - это одна из специализаций этой отрасли и обозначает рискованное вложение денег, или азартную игру.

PC

Почти ежегодно появляется статья, предсказывающая (или скорбящая по поводу) кончину игр на PC. По скромному мнению автора PC-игры не исчезнут в обозримом будущем по очень многим причинам. Например, PC-игры имеют самый низкий барьер для привлечения разработчиков. Также PC, вероятно, самая популярная платформа во всей Азии. Кроме того, именно на PC получили популярность сетевые игры. Открытая природа PC позволяет компаниям экспериментировать с новым и передовым аппаратным и программным обеспечением. Поскольку PC имеют фундаментальную полезность и вне игровой индустрии, всегда будет присутствовать большое их количество, что в свою очередь формирует рынок. Разработанные для PC технологии постоянно находят применение в PC-играх, начиная от мышки и перехода на цветную графику и заканчивая такими технологиями как 3-D ускорение, многоканальный звук, сетевая поддержка, Web-игры, голосовой ввод, текстовые и голосовые чаты в режиме реального времени и даже многопоточность. Предприимчивые разработчики PC-игр приняли на вооружение все эти технологии для совершенствования своих игр. Нет видимых причин тому, что данная динамика когда-нибудь изменится, поэтому в обозримом будущем PC останутся повсеместно популярной платформой для всех типов игр.

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


Деление мира - стиль интерактивных игр

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

Мир

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

Сайт

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

Схемы управления размером игрового мира

Для многопользовательских интерактивных игр и MMOG-игр используются две разные "схемы" предоставления многопользовательских возможностей. Обе схемы разделяют общее игровое сообщество. Обычно игровые сообщества разделяются по копиям игрового мира или экземплярам боевого поля, гоночной трассы и т.д. Ни одна другая форма развлечений в истории человечества не позволяла тысячам или даже миллионам людей одновременно принимать активное участие в спортивных играх или играх-повествованиях. В настоящее время нет ничего удивительного в том, что в игре обслуживается 10 миллионов участников.

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

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

Прекрасный новый (единый) мир

Некоторые известные компании (например, CCP - создатель EVE Online) разработали MMOG-игры в едином виртуальном мире, и на сегодняшний день их опыт является положительным. Эти компании являются первопроходцами, сталкивающимися с проблемами пригодности и техническими проблемами шардов MMOG-игр. В числе прочих должна быть решена задача создания содержимого MMOG-игр в едином мире. Похоже, что решением является разрешение создания содержимого игры самими игроками. Такое пользовательское содержимое не является новой концепцией в интерактивных играх; способность игроков самостоятельно расширять игровой мир устраняет наибольший барьер для интерактивных игр с единым виртуальным миром. Разрешение игрокам дополнять игру поднимает много других проблем, включая вопросы управления игрой. Было неоднократно продемонстрировано (как в игровой индустрии, так и вне ее), что заинтересованные сообщества могут значительно увеличить привлекательность игры, а также ее доходность.

Существуют решения и других проблем пригодности игр в единых мирах. Проблема нехватки ресурсов (для приключенческих игр - квестов) может быть решена путем творческого применения таких механизмов как система распределения найденных ресурсов на базе количества активных игроков, нуждающихся в этих ресурсах. Скопление торговцев и плотность заселения - это еще одна постоянная концептуальная проблема в единых мирах. Ее можно обойти, творчески подойдя к системе торговли. Двумя примерами являются "виртуальные" торговцы и неигровые персонажи (non-player characters - NPC), раздающие квесты.

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

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


Определение размеров игры

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

Существует аксиома, утверждающая: "Лучше всего начать с пользовательского интерфейса". В игре пользовательский интерфейс состоит из сложной 3-D графики, 2-D меню, шестиканальной динамически переключаемой симфонической музыки, эффектов объемного звука, 3-D позиционирования и перемещения, 2-D навигации. Имея в распоряжении такой богатый пользовательский интерфейс, только две технических характеристики клиентского компьютера влияют на инфраструктуру игрового сервера: пропускная способность сети и требования по времени реакции. Поэтому сначала разберитесь с этими вопросами при попытке оценить размер физической инфраструктуры для создания MMOG.

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

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

Главным критерием пригодности для игры любого игрового приложения является время реакции. С этой точки зрения можно спросить: "Каково приемлемое время реакции?". Для такой игры, как шахматы, это время может очень меняться в зависимости от квалификации игрока. Многопользовательские интерактивные игры, доступ к которым производится через игровую консоль, имеют жестко заданные правила производительности, определяемые фиксированным временем обновления экрана. Точнее - игра полностью должна обновиться до следующего обновления экрана. Для телевидения это 24 кадра в секунду. Для PC-игр (доминирующей в настоящее время платформы многопользовательских интерактивных игр) требования значительно выше. Большинство игроков в PC-игры ожидает намного больше, чем 60 кадров в секунду.

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


Сказка о двух мирах (типах)

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

Уровни инфраструктуры многопользовательской игры

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

Уровни инфраструктуры MMOG

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

Многослойные (или основанные на шардах) MMOG-игры используют многие тысячи копий игрового мира для поддержки огромного количества пользователей. Термин "шард" обычно используется для обозначения конкретных серверов, спроектированных по схеме традиционных приложений. Схема представляет из себя многоуровневый шаблон Модель-Представление-Контроллер (Model-View-Controller - MVC). Каждый шард в MMOG разделен на три основных уровня. В самом низу расположен уровень базы данных. Над ним располагается так называемый уровень игрового движка (или игрового сервера). Над этим уровнем располагается интерфейсный уровень. Этот интерфейсный уровень часто разделяется на несколько тонких уровней, таких как уровни регистрации (login), границы (border), пределов (boundary) и баланса нагрузки (load balancing). Наконец, на самом верху располагается игровой брандмауэр и, естественно, подключение к Интернету.

Переменные производительности

На производительность MMOG-игры оказывают значительное влияние многие факторы, например:

  • Средний объем данных, передаваемых в секунду для каждого игрока: Это очень важно для понимания сетевой и интерфейсной инфраструктуры.
  • Планируемое общее число пользователей: Количество игроков, которые купят игру и будут играть в нее, должно быть точно оценено.
  • Планируемое общее число одновременно играющих пользователей: Полагая, что зарегистрировались все пользователи, рассчитайте количество игроков, которые будут играть одновременно в любой момент времени.
  • Планируемое общее число пользователей в географическом регионе: Географические регионы в различных частях мира нужно поделить в соответствии с количеством пользователей, которые будут играть (например, Шанхай, Пекин, Сеул, Токио, Сидней, Лос Анджелес, Сиэтл, Остин, Нью-Йорк, Лондон, Париж, Мюнхен и т.д.).
  • Планируемое число одновременно играющих пользователей в географическом регионе: После разделения мира для игры, определите количество игроков, которые собираются интерактивно играть в каждом регионе.
  • Планируемое число одновременно играющих пользователей на экземпляр программы: Часто трудно определить. Это - расчетное количество поддерживаемых игроков для каждого шарда.
  • Размер "данных о мире": Управляемый параметр, но абсолютно изменчивый. Он определяет количество информации, которая будет храниться в базах данных.
  • Диапазон размеров пользовательских данных: Количество постоянных данных, которые будет генерировать игрок во время игры.

Оценка факторов

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


Индивидуальные уровни в MMOG

Чтобы обеспечить поддержку большого числа игроков, на что указывает первая буква "M" в MMOG (massive), серверная сторона игры представляет собой сложную конфигурацию десятков или сотен серверов, выполняющих различные функции. Эта инфраструктура часто разделена на уровни, как пирог. Каждый уровень выполняет определенный набор родственных функций. Обычно MMO следует архитектурной схеме, называемой "n-уровневая архитектура". В своей самой базовой форме эта архитектура может быть разделена на три уровня: интерфейс, промежуточный уровень и уровень базы данных.

Определение размеров интерфейсного уровня

Интерактивные игры являются главными целями для атак в сети. Такое впечатление, что они привлекают индивидуумов и группы людей всех сортов, желающих нанести вред. Передовой рубеж защиты должен объединять высокопроизводительное сетевое оборудование и отличные защитные функциональные возможности с уровнем межсетевых экранов, доказавших свою устойчивость к таким атакам, как отказ в обслуживании (denial-of-service), фрагментация пакетов и другим типичным атакам интернет-сайтов методом грубой силы (brute-force).

Определение размеров промежуточных уровней

Размеры промежуточных уровней зависят от архитектуры самого игрового движка. Именно на этом уровне располагается игровой движок - сердце симуляции. Размеры этого уровня почти полностью зависят от реализации игрового движка. Большинство MMOG-движков могут обрабатывать от 200 до 600 игроков на сервер; используя современные процессоры, все больше компаний заявляют, что могут достичь показателя в 600 пользователей на игровой сервер. Нетрадиционный дизайн игрового движка позволяет поддерживать в 10 раз большее число пользователей на серверах.

Определение размеров уровня базы данных

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

Замечания по игровым базам данных

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

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

Обычно в MMOG-играх используется та же технология базы данных, что и в банках, страховых компаниях, системах управления торговыми операциями и медицинских регистрирующих системах. Но в отличие от обычных бизнес-систем схемы данных в MMOG-играх умышленно спроектированы простыми, а все выполняемые в этих таблицах транзакции являются простыми операциями обновления и чтения. К сожалению, масштабы MMOG-игр начинают достигать архитектурных пределов традиционных баз данных. Многие игровые компании исследуют возможность использования нетрадиционных движков баз данных, которые смогут технологически обеспечить производительность и малое время реакции. Опыт показал, что базы данных, размещаемые в оперативной памяти, предоставляют исключительную производительность и малое время реакции. Действительно существуют хорошо известные технологии базы данных, обеспечивающие ACID-транзакции (Atomicity, Consistency, Isolation and Durability - атомарность, непротиворечивость, изолированность и долговечность) для критичных ко времени реакции приложений (ссылки на дополнительную информацию по ACID приведены в разделе "Ресурсы"). Эти технологии часто распределяют данные по нескольким серверам, распространяя в них запросы, что позволяет полностью размещать наборы данных в оперативной памяти и параллельно выполнять запросы на нескольких системах.


Определение размеров простым способом

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

Определение размеров большой инфраструктуры - это целая наука. Как ни странно, тут можно использовать те же технические приемы, что и для новой скоростной автострады. Короче говоря, эти приемы заключаются в поиске ключевого фактора пропускной способности и ключевого фактора производительности. Другими словами, определите самое узкое место. Преимущество поиска самого узкого места состоит в том, что все ресурсы, потраченные на устранение этого места, будут пропорциональны окупаемости. В идеальном случае такой расход ресурсов повысит производительность всей системы в 2, 10, 20 и 100 раз. Если узкое место найдено, и его устранение повысит производительность на 5 или 10 процентов, лучше потратить время на что-нибудь другое. Будет трудно оправдать любые затраты на устранение узкого места с такой маленькой отдачей. Затраты легче оправдать, когда найдено ключевое узкое место, и производительность можно повысить значительно.

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

Для каждого, кто работал над MMOG-игрой, ключевое узкое место является мучительно очевидным - связь между игровым сервером и клиентами. Можно смело предположить, что CPU, оперативная память и диски на порядок быстрее сети. После определения узкого места можно определить показатели производительности, являющиеся ключевыми для определения размеров инфраструктуры, - "как быстро" и "как много".

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

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

Вот две ошибки, которые можно совершить:

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

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

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

Определение размеров нижележащих уровней является сложным, потому что зависит главным образом от того, как реализован игровой движок. Неплохим предположением для уровня игрового движка является то, что узкое место на самом деле связано с пропускной способностью канала оперативная память/CPU, а не с сетевыми взаимодействиями. Если это так, тогда нормальным подходом могло бы быть вычисление количества одновременно играющих пользователей, которое может поддерживать один двунаправленный сервер с CPU поколения X и памятью конфигурации Y. Если вы ищете эмпирическое правило, вот одно, которое вроде бы работает хорошо: для большинства игр каждый одиночный интерфейсный сервер может нагрузить как минимум четыре игровых сервера. Использование этого правила может быть довольно практичным заменителем на ранних стадиях разработки игры.

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

Можно сказать, что каждый разработчик игровой программы предпочел бы размесить всю базу данных игры в оперативной памяти. В этом сценарии производительность была бы невероятной и транзакции завершались бы за время, сопоставимое с временем вызова функции. Но это означало бы необходимость наличия системы с парой терабайт физической памяти. Найдется ли такая? Существует тип баз данных, называемый "распределенные без дублирования" ("distributed shared nothing"), которые действительно предлагают возможность поместить всю базу данных в оперативную память. На момент написания данной статьи довольно эффективными по цене являются системы с 4GB памяти. Система базы данных без дублирования может распределить данные и запросы по нескольким системам. Например, если вы объедините вместе системы с 4GB памяти, они будут иметь достаточно RAM для базы данных размером в 40GB в дополнение к операционной системе и другим задачам.

Примечание: Игровые транзакции не похожи на бизнес-транзакции. Разработчики игр знают, что во время игры выполняются миллионы очень маленьких операций чтения и обновления. Игровой движок не требует сложных соединений по схемам типа "звезда". Игры абсолютно не похожи на системы поддержки принятия решений (decision support system - DSS) или системы оперативной обработки транзакций в реальном времени (Online Transaction Processing - OLTP). Рабочая нагрузка в игре больше похожа на LDAP-протокол (Lightweight Directory Access Protocol) или на поиск в телефонном справочнике - много маленьких транзакций в простых таблицах.

Как насчет времени реакции?

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

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

Этот сценарий может показаться дурацким, но он иллюстрирует данную тему. Все элементы в этом сценарии представляют некоторый компонент сетевой технологии и то, что можно изменить для улучшения времени реакции - от специализированного дизайна упаковки (например, использование преимуществ расширений Internet Protocol version 6, таких как jumbo-пакеты) до протоколов Quality of Service (QoS-параметры по IP, там где доступны). Если обмен данными между клиентами и серверами спроектирован как медленный, громоздкий автомобиль, который должен останавливаться, а игровой сервер спроектирован как старый крошечный семейный продуктовый магазин, время обмена не будет оптимальным. С другой стороны, если вы можете использовать подсказки от клиента и сервера, для того чтобы сервер мог подготовиться к приезду высококачественного спортивного автомобиля последней модели, время реакции может быть уменьшено.

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

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

Определение размеров инфраструктуры обработки информации

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

Способы платежей очень отличаются в разных географических зонах. Достаточно неожиданным есть тот факт, что MMOG-игры являются некоторым образом первыми по-настоящему глобальными интерактивными сервисами, которые используются людьми, находящимися в любой географической зоне. Он стал причиной некоторых уникальных проблем индустрии. Например, в Северной Америке система кредитных/дебетовых карт является универсальной платежной системой, использующейся повсеместно, а платежи по предоплаченным картам – всего лишь исключение. В Европейском Союзе предоплаченные карты существуют наравне с кредитной системой, знакомой большинству северных американцев. В Южной Азии, особенно в Китае, системы кредитных карт практически не существует, а использование предоплаченных карт является нормой. Во всех этих регионах обработка платежей (независимо от способа) и биллинг - традиционно внешняя функция. В каждой географической зоне существует группа компаний, специализирующихся на биллинге и взимании платежей способом, уместным для соответствующего региона. Примерами таких компаний являются InfoSpace в Беллвью (Вашингтон) и YeePay в Пекине.

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

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


Резюме

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

Ресурсы

Научиться

Получить продукты и технологии

  • Пробное программное обеспечение IBM: Разработайте ваш следующий проект с использованием пробного программного обеспечения IBM, доступного для загрузки непосредственно на developerWorks.(EN)

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Web-архитектура
ArticleID=279686
ArticleTitle=Масштабные многопользовательские интерактивные игры: Часть 1. Подход к определению размеров инфраструктуры
publish-date=01032008