Шаг первый: Оценка своих способностей

Необходимые знания:

1) Владение как минимум одним языком программирования. До сих пор С++ является наиболее популярным языком в среде разработчиков игр из-за его преимуществ и эффективности. Visual Basic, Java или C# также подойдут.
2) Овладеть одной из графических библиотек. Популярны SDL, OpenGL и DirectX/Direct3D.
3) Определиться с сетевой библиотекой. Можно выбирать между WinSock, SDL_net, или DirectPlay.
4) Иметь общий опыт в программировании игр. Например, понимать, что такое очередь событий, многопоточность, дизайн GUI и т.д.

Очень рекомендуемые знания:

1) Принципы взаимодействия клиент/сервер и их архитектура.
2) Программирование для различных платформ. Возможно, вы захотите создать игру, или особенно - сервер, которые будут работать на различных ОС. В таком случае, рекомендую использовать SDL, OpenGL и SDL_net ( как кроссплатформенные библиотеки ).
3) Web-разработка. Это понадобится, если вы захотите дать своим игрокам возможность просматривать статистику, информацию о сервере и другие данные на web-сайте.
4) Безопасность и администрирование. Вы ведь не хотите, чтобы ваш сервер взломали и устроили там бардак?
5) Опыт командной работы. Вам понадобится команда, которую нужно будет эффективно вести и управлять.

Шаг второй: создание предварительного дизайна

Я часто замечал на различных форумах людей, которые собирают команду для разработки MMORPG. Большинство из них начинают с чего-то вроде этого: "Мы начинаем набор в команду и нам нужны три художника, два программиста, один музыкант и т.д. для создания революционной MMORPG, в которой у вас будет полная свобода действий и возможность изменять мир, и т.д. Мы заплатим вам после завершения разработки и получения прибыли". К сожалению, с текущим уровнем технологийНЕВОЗМОЖНО создать изменяемый мир. Установка своей целью невозможного ведёт к неудаче. Вместо этого, попытайтесь начать с небольшого, функционального, расширяемого дизайна и архитектуры.

Основная архитектура программы

В первую очередь, попробуйте сфокусироваться на создании простой модели клиент/сервер, где можно будет:

1) Создавать нового персонажа.
2) Сохранять персонажа ( на стороне сервера )
3) Входить в игру персонажем.
4) Иметь возможность общаться с другими персонажами.
5) Иметь возможность передвигаться в трёхмерном мире.

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

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

Шаг третий: выбор внутреннего протокола для передачи данных

Опять-таки, выглядит просто, но это не так. Вы не можете просто посылать strings с '\0' в качестве терминатора. А всё потому, что вам нужен совместимый протокол, которые сможет отсылать как string, так и binary данные. Неразумно использовать 0 ( или любую другую комбинацию ) как терминатор, потому что этот терминатор может быть частью потока данных, который вы хотите отправить. Более того, если бы отправите 20 байт, а затем ещё 20 байт, скорее всего, сервер не получит два последовательных пакета по 20 байт, а получит один в 40 байт для избежания траты пропускной способности на повторяющиеся заголовки. В качестве альтернативы, вы можете послать пакет в 1 килобайт, однако сервер получит его как два пакета меньшего размера. Отсюда следует, что вам необходимо иметь возможность узнать, где пакет начинается, а где - заканчивается. В Eternal Lands мы использовали следующий метод:

Offset 0: 1 байт, определяющий передаваемую команду
Offset 1: 2 байта, длина передаваемых данных
Offset 3: переменная длина, тело сообщения

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

Следующее, с чем стоит определиться, это - модель сервера: "неблокируемые сокеты, однопоточность" или "блокируемые сокеты, многопоточность". Оба метода имеют свои преимущества и недостатки:

Многопоточный:

1. Более "гладкий" отклик от сервера, потому что в случае необходимости игроку большого количества времени ( чтение базы данных ), это происходит в отдельном потоке, не затрагивающем остальные.
2. Очень сложно выполнять отладку и реализовать правильно этот подход: вам потребуется очень много синхронизаций, и небольшие промахи могут иметь ужасные последствия - крах сервера, дублирование предметов и т.д.
3. Использует многопроцессорные системы

Однопоточный

1. Намного более просто отладить и реализовать
2. Более медленный отклик сервера

В моей компании, мы пошли однопоточным путём, т.к. не имели достаточно ресурсов для работы над многопоточным подходом.

Шаг четвёртый: Клиент

Вы планируете 2D или 3D-игру? Некоторые могут полагать, что сделать игру в 2D проще. Я делал и те, и те, и верю, что 3D сделать проще. Позвольте мне объяснить, почему.

В 2D, обычно вы имеете буфер кадра, который представляет собой большой массив из пикселей. Формат этих пикселей может различаться, в зависимости от видеокарты. Некоторые используют RGB-режимы, некоторые - - BRG и т.д. Количество битов для каждого цвета также может различаться. Это относится к 16-битному режиму. 8-битный и 24-битный режимы проще, но эти режимы также имеют проблемы: в 8-битном вам доступно только 256 цветов, а 24-битный режим медленнее. Также вам будет необходимо самостоятельно определять порядки для спрайтов и сортировать объекты, чтобы они отображались в нужном порядке. Конечно, можно использовать OpenGL или Direct3D для создания 2D игры, но обычно оно того не стоит. Не у каждого установлена видеокарта, так что использование 3D-библиотеки принесёт вам недостатки из обоих миров: не все смогут играть в эту игру, и вы не сможете использовать все преимущества 3D типа вращения камеры и теней.

Трёхмерный путь, как я уже говорил, проще, но требует знания простейшей математики ( особенно тригонометрии ). Современные графические библиотеки очень мощные, и предоставляют простые операции практически "нахаляву": вам не нужно сортировать объекты; можно легко изменять цвета или текстуры объектов; объект будет освещен в зависимости от положения источников света, если вы просчитываете нормали для него и т.д. Кроме того, 3D даёт вам больше свободы в плане создания и передвижения. Из недостатков стоить отметить, что не каждый сможет играть в вашу игру, т.к. до сих пор не все компьютеры оснащены видеокартами, и то, что заранее отрендеренные изображения будут выглядеть лучше тех, что рендерятся в реальном времени.

Шаг пятый: Безопасность

Как это ни странно, но нельзя доверять пользователям. Ни при каких условиях не надейтесь, что пользователи не смогут разобраться в вашей системе шифрования ( если вы её используете ) или протоколе. Всё, что пользователь посылает серверу, должно проверяться. Скорее всего, ваш сервер будет иметь фиксированный буфер. Например, обычно устанавливают небольшой буфер ( около 4 килобайт ) для входящих данных ( из сокетов ). Злобный юзер-хакер может отправить очень большой поток данных, и если это дело не проверять и отслеживать, оно может вызвать переполнение буфера и "падение" сервера, или, что ещё хуже, пользователь сможет выполнить произвольный код и взломать сервер. Каждое отдельное сообщение должно проверяться: каждый раз, когда случается переполнение буфера, когда приходят неправильные данные ( например, юзер говорит - откройте эту дверь, в то время как сама дверь находится за несколько километров от этого места ), или когда юзер пытается использовать Снадобье, которого у него нет и т.д. Скажу ещё раз: КРАЙНЕ важно проверять все данные. Во время, когда происходит какое-то нарушение, заносите его в лог вместе с именем пользователя, его IP-адресом, временем и местом нарушения, а также что это было за нарушение. Проверяйте иногда этот лог. Если вы заметите, что нарушения происходят от большого количества пользователей, скорее всего это баг или сетевая ошибка. Если же множество нарушений идут от одного пользователя или IP, это верный признак того, что с вашим сервером "играют", пытаясь или взломать его, или выполнить какой-то скрипт/макрос. Также, никогда не храните данные на стороне клиента. Клиент должен получать свои данные с сервера. Другими словами, клиент не должен посылать сообщения типа "Короче, вот мой список предметов" или "Моя сила - 10, мана - 200, а моё здоровье - 2000 из 2000". Также, клиент не должен получать больше данных, чем ему необходимо. Например, клиент не должен знать, где находятся другие игроки, кроме как в случае если они находятся поблизости. Это обычный здравый смысл, т.к. передача каждому игроку данных о каждом игроке "съест" много пропускной способности, и некоторые игроки смогут взломать клиент, чтобы получить нечестное преимущество ( например, видеть на карте положение всех игроков ). Всё это выглядит само собой разумеющимся, однако вы бы удивились, узнав, как много людей не понимают того, что мы называем здравым смыслом.

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

Проверяйте расстояния. Если игрок пытается торговать с игроком, который находится за 10 миллионов километров, вносите это в лог. Если игрок пытается посмотреть на объект или использовать предмет, который находится слишком далеко - вносите это в лог. Опасайтесь поддельных ID. Например, принято назначать ID каждому игроку ( обычно это делается во время входа в игру, либо у каждого игрока неизменяемый уникальный ID ). Если ID присваивается при входе в игру ( или при создании монстра ), имеет смысл использовать его положение ( индекс ) в массиве игроков как его ID.

Таким образом, первый залогинившийся игрок получит ID 0, второй - ID 1 и так далее. Теперь, наверняка у вас будет лимит количества игроков в 2000. В таком случае, если клиент пошлёт команду типа "посмотреть на игрока с ID 2000000", сервер "упадёт", если он не защищён от этого, т.к. сервер попытается получить доступ к неправильной памяти. Так что выполняйте проверку типа "если персонаж ID < 0 или если персонаж ID > maxplayers, то занести в лог нарушение и отсоединить игрока". Если вы программируете на С или С++, позаботьтесь о том, чтобы обозначить ID как 'unsigned int' и проверяйте верхнюю границу, или же если вы используете индекс как int ( а int по умолчанию signed ), не забывайте проверять, чтобы ID не был меньше нуля и больше макс. количества игроков. Нарушение этого правила приведёт к появлению проблем как для вас, так и для ваших пользователей. Аналогично проверяйте на координаты вне карты. Если ваш сервер использует алгоритмы поиска пути, и клиенты передвигаются путём указания точки перемещения кликом по поверхности, убедитесь в том, что этот клик не приходится за границы карты.

Шаг шестой: Собираем команду

Создание игры - трудоёмкий процесс ( не считая тетриса и пинг-понга ). Особенно это относится к MMORPG. Вы просто не сможете сделать всё в одиночку. В идеале, команда независимых разработчиков должна состоять из:

Хотя бы 3 программиста: 1 для сервера, и 2 - для клиента ( или 1 для клиента, и 1 - для инструментов, типа плагинов для художников, редактора карт и т.д. ). Иметь в наличии до 6 программистов - нормально, а вот больше уже может стать излишним. Как минимум 1 художник, лучше 2 или 3. Если это 3D-игра, вам потребуется 3D-художник, 2D-художник ( текстуры, интерфейс и т.д. ), аниматор и лидер отдела. Если вы сам не хороший художник, отдел графики нуждается в координации опытным художником.

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

Веб-мастер, если вы сам не являетесь опытным веб-дизайнером, и не хотите тратить своё время на создание сайта. Иметь специалиста по звуку и музыканта не обязательно, но игра со звуком и музыкой определённо только выиграет от этого.

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

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

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

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

Ещё совет: не хвастайтесь игрой, пока вам нечего показать. Одна из наиболее раздражающих ситуаций - когда новичок создаёт тему с просьбой о помощи, собирает большую команду и рассказывает всем, насколько хороша его игра. Бывают ситуации, когда человек заходит на рекламируемый таким образом сайт, он видит внушительно меню, состоящее из секций типа "Скриншоты", "Концепт-арт", "Скачать", "Форум" и т.д. Чаще всего такие разделы пусты, либо ведут на несуществующую страницу. Если вам нечего представить в какой-то секции - просто не создавайте её. Лучше даже не тратьте время на сайт до тех пор, пока не будет сделано хоть что-то.

Шаг седьмой: Развеивая мифы

1. Ты не можешь сделать MMORPG, для этого необходима большая компания.

Я с этим не согласен. Хотя создание игр масштаба World of Warcraft, Ever Quest 2, Asheron's Call 2, Lineage 2 и т.д. для небольшой команды независимых разработчиков невозможно, тем не менее, создание приличной игры возможно, если у вас есть определённый опыт, мотивация и время. Вам понадобится хотя бы 1000 часов программирования для выпуска простой технической демки, и около 10-15 тысяч часов для выпуска почти готового клиента/сервера. Но, как лидер проекта, вы должны делать гораздо больше, чем просто программировать. Держать команду вместе, разрешать конфликты, общаться с общественностью, осуществлять техническую поддержку, создавать сервера, банить нежелательных пользователей, устраивать "мозговой штурм" и т.д. Так что вы будете завалены не только программистскими задачами. Также, скорее всего, вам нужно ходить на работу/в школу/в университет, что уменьшает количество времени, которое вы можете посвятить проекту. Нам очень крупно повезло, что ни один член команды не покинул её, но если это случится - будут большие проблемы. Просто представьте, что будет, если художник уйдёт на полпути. И ещё хуже - запретит вам использовать свои работы в этом проекте. Конечно, можно заранее подписать с ним контракт, но будет всё ещё сложно найти нового художника. Также может быть проблемой наличие в проекте двух разных стилей.

2. Нужно много денег ( 4-6 значная сумма ) для поддержки MMORPG сервера.

Ну, это просто не правда. Я видел выделенные сервера, с 1000 гигабайт в месяц трафика за 100 $ в месяц ( и 200-300 долларов за установку ). Только если ваш протокол передачи данных не плохо спроектирован, 1000 гигабайт вполне достаточно для сервера с посещаемостью в 1000 человек. Конечно, вам понадобится другой сервер для хранения клиента и сайта ( скачка клиента может создавать много трафика, как только игра станет популярной ). Наш клиент весит около 22 мегабайт, и иногда мы имеем 400 гигабайт трафика за месяц только на его скачивание. И это в то время, как мы ещё не слишком популярны. Ещё - вам не нужен выделенный сервер для самого начала. Сервер на DSL-линии может справляться со своей задачей, пока ваша посещаемость не перевалит за 20-30 человек. Тогда можно или найти хостинг, который согласится разместить его бесплатно в обмен на рекламу, или просто заплатить из своего кармана.

3. Создавать MMORPG очень весело.

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

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

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

Заключение

Надеюсь, эта статья дала вам взгляд "изнутри" на разработку MMORPG и поможет избежать многих ошибок.

ссылка:http://gamesmaker.ru/industry/common/rukovodstvo-kak-sozdat-mmorpg/