В последнее время очень широкое распространение в мире игр получили многопользовательские онлайновые игры (MMOG — massive multiplayer online game), которые рассчитаны на огромно-большое количество игроков. Конечно, все слышат только об успешных проектах, которые собирают серьезные финансовые доходы. Это и привлекает большинство новичков в игрострое в этот жанр. Однако, мало кто реально представляет себе, какие проблемы и задачи стоят при создании такого рода игр, какими знаниями надо обладать и т.п.

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

Цель данной статьи – дать начальное представление желающим сделать свою игру в стиле MMOG, о том, какими знаниями надо обладать, что нужно уметь и к чему быть готовым. Ведь не секрет, что если человек пробует что-то раз и результат отрицательный — то повторно возвращаться он к этому вряд ли будет. Поэтому хотелось бы предостеречь еще раз желающих окунуться в мир создания таких игр и предложить им еще раз все обдумать и взвесить. Может, стоит начать с более простых игр, чтобы просто получить требуемый минимальный опыт?

Статью такого типа мне хотелось написать уже давно, но я не обладал достаточным опытом в этой сфере. В просторах Интернета мне попалась статья Radu Privantu, который является основателем и руководителем проекта Eternal Lands (www.eternal-lands.com). С его письменного разрешения я перевел эту статью на русский язык.

В статье говорится о создании MMORPG (ролевой игры), но я думаю, что описанное в ней относится ко всем типам массивно-многопользовательских онлайновых игр.

Автор статьи: Radu Privantu.
Оригинал статьи: http://www.devmaster.net/articles/building-mmorpg/ (статья написана 06/08/2004)
Перевод: AlexKom

Руководство для начинающих создателей MMORPG игры

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

Шаг 1. Оценка своих знаний:

Шаг 2. Создание эскиза разработки

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

Сначала, попробуйте сосредоточиться на создании простейшей клиент-серверной модели, где будут введены следующие возможности:
1. Создание нового персонажа
2. Сохранение этого персонажа (на стороне сервера)
3. Вход в игру персонажем
4. Создать возможность общения с другими
5. Создать возможность передвигаться по миру в 3D

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

Можно легко добавлять или модифицировать поля.

Изменение статистики об игроке (не из игры) гораздо проще

Вы можете быстро и эффективно получать различную статистику, используя SQL запросы

Нет необходимости создавать операции ввода/вывода в файл, база данных все это сделает за Вас

Легко обновлять и восстанавливать

Недостатки:

Легко допустить ошибки. Например, выполнение запроса с забытым оператором ’where’. Это может иметь катастрофические последствия, особенно если у Вас есть только старые (или нет совсем) бэкапы

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

Требуется писать дополнительный код для конвертации Ваших данных в/из базы данных

Требуется опыт работы с базами данных и языком запросов SQL. Также необходимы библиотеки для организации взаимодействия между приложением и базой данных

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

Файлы

Преимущества:

Очень быстрый доступ (чтение/запись)

Легко имплементируется

Не нужны дополнительные библиотеки

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

Недостатки:

Может быть довольно проблематичным добавить новые поля, если вы предварительно не продумали формат и структуру файла

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

Требуется написание специального кода, для возможности обновления/проверки статуса игроков

Немного сложнее для выполнения операций обновления и восстановления

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

Шаг 3. Разработка внутреннего протокола для передачи игровых данных

Эта задача также выглядит простой, но опять-таки, это не так. Вы не можете просто отправить строку с символом терминального нуля ‘\0’. Вам будет нужен совместный протокол, который будет способен передавать как строковые, так и бинарные данные. Неблагоразумно в таком случае использовать 0 (или любой другой набор) в роли терминаторного элемента, потому что этот терминатор может оказаться частью потока данных, который Вы посылаете. Кроме того, если Вы хотите отправить 20 байт, а затем еще 20 байт, скорее всего сервер не получит пакет с 20 байтами, а затем еще один пакет с другими 20 байтами. Вместо этого, он получит сразу 40 байт, так как это снижает нагрузку на сеть за счет заголовка пакета (будет отправлен один, а не два заголовка). Точно также Вы можете отправить пакет размером 1 кб, но сервер получит два пакета меньшего размера. Таким образом, необходимо знать где пакет начинается и где заканчивается. В проекте Eternal Lands использовался следующий метод:

* Смещение 0: 1 байт, определяющий передаваемую команду.

Смещение 1: 2 байта, длина передаваемых данных.

Смещение 3: переменная длина, тело сообщения.

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

Следующий вопрос для принятия решения – какую модель использовать на сервере: «неблокируемые сокеты, однопоточное приложение» или «блокируемые сокеты, многопоточность». Оба метода (много- и однопоточный) имеют свои преимущества и недостатки.

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

Однопоточный:
1. Намного проще реализовать и затем отлаживать
2. Большее время отклика

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

Шаг 4. Клиент

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

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

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

Шаг 5. Безопасность

Естественно, пользователям нельзя доверять. Никогда не думайте, что пользователи не смогут разобраться в Вашей замечательно продуманной схеме шифрования данных (если Вы таковую используете) или в протоколе. Все что пользователь отправляет на сервер должно быть проверено. Скорее всего, на Вашем сервере будет несколько буферов фиксированного размера. Для примера, обычно создают небольшой (порядка 4 кб) буфер для входящих данных (из сокетов). Злоумышленник может отправить очень большой пакет данных. Если его не проверять – то это действие приведет к переполнению буфера, после чего последует падение сервера или в худшем случае, злоумышленник получит возможность взломать Ваш сервер, запустив на выполнение любой код. Каждое сообщение должно быть проверено: не произошло ли переполнение буфера, не пришли ли неправильные данные (например, пользователь присылает «войти в дверь», а дверь находится на другом конце карты, или «использовать лечебный эликсир» в то время как у пользователя нет нужного зелья и т.п.). Я повторю еще раз: очень важно проверять все приходящие данные. Когда же происходит обнаружение хакинга, запишите это в лог: в чем суть нарушения, имя пользователя, его IP адрес, время и дата. И время от времени проверяйте этот лог. Если вы обнаружите немного нарушений от многих пользователей, то это, скорее всего, ошибка в коде клиента или проблемы с сетью. Однако, если вы обнаружите много нарушений от одного и того же пользователя или IP адреса – это показатель того, что кто-то «забавляется» с сервером, пытается найти способ взломать его или запустить свой макрос/скрипт. Также, никогда не храните данные на стороне клиента. Клиент должен получать все свои данные с сервера. Другими словами, клиент никогда не должен отправлять данные, вроде следующих: «так, это список моих предметов» или «у меня сила равна 10, манны – 200 и жизни 2000 из 2000». Также, клиент не должен получать данных больше, чем ему нужно. Например, он не должен знать, где находятся все другие игроки. Ему нужно знать только о тех, кто находится рядом с ним. В этом есть здравый смысл, так как отправка всех игрокам данных обо всех игроках приведет к большому трафику, и некоторые игроки взломают клиент для получения для себя cheat-преимуществ (показать точные месторасположения игроков на карте). Это все выглядит довольно понятным, но, опять-таки, Вы будете удивлены, увидев, сколько людей не обладают тем, что мы называем «здравым смыслом».

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

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

Итак, первый игрок который залогинится получит ID 0, второй – ID 1, и так далее. Скорее всего у Вас будет установлен лимит, скажем, в 2000 индексов для списка игроков. Таким образом, если клиент пришлет команду вроде: «посмотреть на актера с ID 200000» - это приведет к падению сервера, если по неосторожности выполнение такого действия приведет к неправильному обращению к памяти. Итак, делайте проверки вроде: «если актерID<0 или есть актерID>=максимального значения индекса, тогда сделать запись в логе и отключить игрока». Если Вы создаете программу на С или С++, позаботитесь также об определении индекса типом ‘unsigned int’ и проверяйте верхнюю границу, или если Вы почему-то определили индекс как тип ‘int’ (по умолчанию тип ‘int’ – знаковый), помните о необходимости проверки на <0 и >= max значению. Невыполнение этого правила приведет к большому количеству ошибок для Вас, и разочарованию для игроков. Аналогично, проверяйте координаты на выход за границы карты. Если у Вас реализован на сервере в некотором виде поиск пути, и клиенты перемещаются путем указания позиции на поверхности, убедитесь, что они не указывают места за пределами карты.

Шаг 6. Создание команды

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

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

Несколько человек, для создания игрового мира: создание всех карт мира очень долгий процесс, и он очень важен для создания удачной игры. И снова, Вам будет нужен лидер для команды разработчиков игрового мира. Вы не можете просто взять кого угодно, чтобы они делали что угодно. Так Вы не сможете получить качественно проработанный игровой мир. А ведь именно такой Вам нужен, не так ли?

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

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

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

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

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

Еще пара советов: не хвастайтесь (не афишируйте) Вашей игрой до тех пор, пока у Вас не будет хоть что-то для демонстрации. Одна из самых раздражающих вещей – когда новичок оставляет сообщения вроде «требуется помощь», приглашает большое количество людей в команду, рассказывает о том, какая классная игра будет. Но пройдя дальше по линкам на такой проект (обычно он располагается на бесплатном хостинге) вы увидите потрясающее меню, содержащее в себе секции вроде «Скачать», «Скриншоты», «Концепт-арт», «Форум» и пр. Вы нажимаете на ссылку «скачать», и получаете красивую картинку «в процессе разработки» (или ошибку 404 в худшем случае). Когда Вы нажимаете на ссылку «скриншотов» - получаете аналогичный результат. Если у Вас нет файлов на скачивание, не создавайте ссылку «Скачать». Если нет скриншотов – не создавайте и этот линк тоже. Лучший вариант – это не тратить свое время на создание сайта до тех пор, пока у Вас не будет готово как минимум 10% проекта (как кода, так и арта).

Шаг 7. Развеем мифы

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

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

2. Требуется большая сумма (4-6-тизначная) для поддержания серверов.

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

3. Создание MMORPG очень увлекательно.

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

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

Заключение

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

Об авторе

Эта статья была написана Radu Privantu, ведущим программистом и руководителем проекта Ethernal Lands www.eternal-lands.com, бесплатной, с открытым кодом клиента MMORPG. С ним можно связаться по адресу chaos_rift at yahoo dot com.

Предисловие от переводчика