Как сделать игру мморпг: Разработка ММО РПГ – практическое руководство. Эпизод 1

Разработка ММО РПГ – практическое руководство. Эпизод 1

        В цикле статей «Разработка ММО РПГ – практическое руководство» вы получите ответы на эти и многие другие вопросы. Все цифры реальны. Все схемы, таблицы, исходный код, диаграммы БД и прочее взяты из реально существующего и успешно работающего проекта.

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

        Готовы? Тогда в путь!

        Трудозатраты

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

        Как видите, дороже всего обошлось создание клиента. И это не удивительно, учитывая, что игра — в реальном времени и с использованием 3D. На втором месте -сервер, и это тоже ожидаемо. Что неожиданно – это высокие затраты на управление и низкие – на 2D и 3D графику. «Может просто графика невзрачная?» – скажете вы. Как раз нет: графика игрокам нравиться. Секрет в активном использовании аутсорса для создания графики. Нам удалось существенно снизить стоимость производства графики, но при этом, естественно, возросли расходы на управление. Благодаря этому суммарный бюджет проект удалось уменьшить почти на 10%. А вот высокие расходы на геймдизайн – это наша ошибка. Изначально мы не верно оценили силы и стоимость разработки, поэтому мы замахнулись на то, что сделать были неспособны. В результате нам пришлось 3 раза переделывать сюжет, несколько раз менять боевую систему, перерабатывать схемы интерфейса и так далее. При более трезвой изначальной оценке, я думаю, удалось бы снизить затраты на геймдизайн раза в два (или 5% от общего бюджета проекта).

        На аутсорс мы отдавали концепт-арт и создание 3D-моделей, причем первые единицы техники в линейке (например, турель 1-го и 20-го уровня) обязательно создавались в офисе. А вот остальное (турели 40-го, 60-го и 80-го) – и концепты, и 3D-моделинг отдавали на аутсорс. Почему так? В офисе, прежде всего, происходит поиск концепта и его отображения в 3D. И, как любая исследовательская работа, она требовала высококвалифицированных (и, следовательно, дорогих) специалистов. А когда форма найдена производство можно смело отдавать на аутсорс.

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

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

        Состав команды

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

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

Таблица 1.

Выводы

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

        Схема системы и план разработки

        Формально «Звездные Призраки» — браузерная игра. Но веб-часть работает под управлением Adobe Flash и использует сокетное соединение. Поэтому, фактически, это клиент-серверная игра, только загрузка клиента происходит прозрачно для пользователя. Из каких же компонентов состоит игра? Казалось бы, все должно быть просто – из клиента и сервера. Но на самом деле (см. рис. 2) все несколько сложнее.

    Мы придерживались следующего порядка разработки:

1. Основной клиент
2. «Пробирка» для 3Dшников.
3. Основной сервер
4. БД
5. Админка (частично: создание предметов, локаций, ботов)
6. Авто-скрипты
7. Чат-сервер
8. Админка (все остальное)
9. Драйверы для платежной системы
10. Драйверы для поставщиков трафика
11. Веб-сайт
12. Рег. сервер и рег. клиент
13. Драйверы социальных сетей (авторизация).

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

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

        Этап 1. В первую очередь был разработан прототип игры без всякого сервера, но в который вошли практически все предполагаемые к использованию в клиенте технологии, а именно: Adobe Flash, Adobe Away3D, Adobe Starling. У нас был космос, в котором пользователь управлял одиноким кораблем. На этом прототипе мы обкатали базовую систему расчета кривой перемещения корабля, перемещение космоса (параллакс), проверили возможности отрисовки моделей на текстуру. В общем, мы протестировали все узкие места, которые видели в начале разработки и примерно поняли, как у нас все будет выглядеть. Это позволило сделать вывод о возможности технической реализации задуманного, а так же дало демо, с которым можно было идти к инвесторам.

        Этап 2. После утверждения тех.задания мы выработали тех.требования к 3D-моделям: на этом этапе у нас уже было представление о внешнем виде игры, платформе и движке. Кроме того, мы создали «пробирку» для 3Dшников – отдельный инструмент, в который можно было загрузить 3D-модель и посмотреть, как она будет выглядеть после рендера в Away3D. Дело в том, что после экспорта непосредственно в движок, модель выглядит немного не так, как в инструменте моделирования. Поэтому нашему артотделу, а особенно арт-директору, было крайне важно видеть, как все будет выглядеть на самом деле, чтобы «подтянуть текстуры», как он говорил. Тут сразу оговорюсь: в ходе работ мы перешли на новую версию Away3D, в которой шейдеры были другими, и это привело к изменению визуального отображения моделей. «Подтягивать текстуры» пришлось заново. Отсюда есть два очень важных вывода: во-первых, требуйте от текстурщиков порядка в файлах текстур, раскладки всего по слоям с человеческими названиями, чтобы через полгода другой человек мог открыть файл и найти нужный слой, а, во-вторых, все «подтягивания» графики делайте не сразу по ее готовности, а ближе к концу проекта.

        Этап 3. Затем мы приступили к созданию сервера и сетевой части в клиенте. В качестве языка программирования был выбран С++, т.к. у нас уже имелись наработки и свои библиотеки на этом языке. На данном этапе сервер работал без БД, данные он подгружал из XML-файла. Задача этого этапа – протестировать выбранные серверные технологии, а так же дать возможность гейм-дизайнеру и всей команде поиграться «онлайн». Самое главное, что здесь нужно тестировать – с каким максимальным пингом в игру еще можно играть. То есть нужно выяснить, можно ли вообще играть по сети, или все так дергается, что играть невозможно. У нас на этом этапе корабли даже стрелять не могли, мы просто летали друг за другом и тестировали разные алгоритмы синхронизации.

        Этап 4. Дальше некоторое время шла итеративная разработка клиента и сервера. Первое, что появилось – это XML конфиги оборудования, чтобы гейм-дизайнер мог тестировать параметры пушек и кораблей. Так же на этом этапе было много экспериментов, создания различных видов вооружений и поиск механизма боя.

        Этап 5. Когда механика игры более-менее устоялась, можно было подключать БД к серверу. В качестве СУБД был выбран MySQL. Подключение подразумевало, прежде всего, перенос загрузки данных оборудования из XML файлов в БД, а также загрузку и сохранение состояния пользователей. Естественно, необходимо было создать админку, которая позволила бы гейм-дизайнеру создавать/редактировать предметы и локации. Админка была написана на PHP. Когда отпала необходимость редактировать XML файлы, гейм-дизайнер был очень рад, и процесс наполнения игры предметами и локациями стал продвигаться существенно быстрее.

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

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

        Этап 8. Мы приближались к закрытому бета-тесту (ЗБТ). Стало очевидным, что потребуется сбор статистики. Доработки затронули сервер и БД, плюс отображение в админке. Работы было много, но, в основном рутина, за исключением проектирования БД.

        Этап 9. После ЗБТ мы пофиксили баги и выполнили некоторые модификации, после чего стали готовиться к открытому бета-тесту (ОБТ). Конечно же, необходимо было реализовать возможность приема платежей. Такие доработки затронули клиент, сервер, БД, а так же пришлось создать специальный скрипт. Здесь, опять же, никакой особой магии – все на РНР.

        Этап 10. Пришло время разобраться с поставщиками трафика. С ними мы работаем по двум схемам: фиксированная стоимость в месяц независимо от количества переходов/регистраций или оплата за регистрацию (СРА). Для работы по модели СРА необходимо было провести интеграцию с API этих поставщиков трафика. Доработки затронули клиент, сервер, БД, веб-сайт и админку (фильтры в статистике).

        Этап 11. Непосредственно перед ОБТ мы создали сайт игры (во время ЗБТ игроки переходили на страницу с Flash, а регистрация и логин были реализованы во флеше). Больше всего времени заняла интеграция игры с базой форума, чтобы обеспечить сквозной логин форум/игра.

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

        Этап 13. Непосредственно перед релизом была добавлена интеграция с социальными сетями, а именно возможность авторизации через социальные сети. Это увеличило конверсии переходов в регистрации примерно на 10%.

        Заключение

        В следующей статье цикла «Разработка ММО РПГ – практическое руководство» мы подробно ознакомимся с серверной часть, её компонентами, затронем работу с БД и многое другое.

Как сделать MMORPG своими руками. Медленно, сложно, интересно / Хабр

Привет, хабрахабр! Меня зовут Егор Курьянович и ты, возможно, помнишь меня по паре интернет-проектов: Кьюби и Идейнику. А быть может, ты даже слышал о других моих начинаниях. Сегодня я хочу рассказать тебе, чем занимался последние пару лет.

Ты ведь любишь игры, не так ли? То, что ты видишь на КДПВ, называется FAR7. Чтобы было немного понятнее, скажу, что молодежь сравнивает её с Космическими Рейнджерами, те кто постарше, вспоминают StarControl2, а совсем уже хардкорные геймеры постоянно твердят об Elite. Сойдемся на том, что это браузерный космосим. В игре вы можете путешествовать между звездными системами, торговать, воевать и выполнять различные миссии.

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

Награды

За три года разработки игра засветилась на нескольких конкурсах. Получила приз за лучшие технологии в конкурсе GAME_ON от корпорации Mozilla и за лучший игровой проект на конкурсе IT-JUMP 2012 в беларуском Парке Высоких Технологий.

Архитектура

Поскольку я все-таки программист, то начну изнутри — с архитектуры проекта.

Ядро системы состоит из веб-приложения написанного на Perl/Catalyst, демона имитации жизни на Perl/AnyEvent (мы, кстати, называем его Лапласом) и отдельного WebSocket-сервера на базе SockJS.

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

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

На клиенте работает MooTools+JxLib, а для рендера используется CAATjs, позволяющий скомпилировать игру в нативное приложение для мобильных платформ. К сожалению, при разработке клиентской части я допустил одну большую ошибку — как и все начинающие разработчики, я написал свой движок. Хотя у меня есть оправдание — на момент начала разработки, подобных движков не существовало в принципе. Это сейчас игровых движков на HTML5 уже чуть ли не больше чем игр, а тогда мы разрабатывали как могли.

Инди — путь страданий

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

Жизнь стартапера в основном состоит из адского труда и отчаяния. Если он, то есть я, и пьет кофе, то только для того, чтобы проработать ещё несколько часов ночью. Солнце редко касается его макбука, как, впрочем, и его самого — стартапер работает весь день: на рассвете, в полдень, на закате, и даже, когда через несколько часов снова будет рассвет. Про выступления, аплодисменты и щедрые чеки, пожалуй, тоже стоит забыть — выступать вы будете редко и уж точно не перед собранием директоров венчурных фондов, а редкие пойманные инвесторы будут просить пояснить, что такое «MMORPG» и нужен ли для ее запуска компьютер, а после спрашивать, сколько миллионов человек в день посещает ваш — то есть моего проекта — сайт.

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

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

Мы начинали втроем, но уже к концу первого года разработки я остался один. Другие ребята просто не выдержали такого темпа, и я их за это не виню. Они клевые, но что поделать — путь стартапера оказался не для всех. Если вы сейчас хотите начать масштабный проект, но чтобы «в свободное время 2 часа в день после работы», то будьте готовы к тому, что потребуется 20 часов в день, а энтузиазм будет переливаться в желание поспать, а не доделать очередную фичу. Что через пару недель случится со всевозможными кофаундерами, партнерами, будущими СЕО и СТО «за процент» можете предположить сами.

Но любая разработка рано или поздно начинает приносить плоды: от биллинг-провайдера приходит письмо на заключение договора, форма логина начинает пускать игроков, и бездушным NPC перестает быть скучно и одиноко в огромной вселенной. Это называется открытое бета-тесирование или ОБТ.

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

И каждый хабрапользователь, и его друг, и жена, и даже бабушка зашедшая в FAR7 очень поддержат меня. Это были долгие 3 года, и путь еще далеко не закончен: впереди нас ждет клевая система имитации жизни, подземелья (в космосе, вы представьте!), батлграунды, новый контент и многие другие прекрасные вещи.

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

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

СОЗДАНИЕ ИГР #1: Создание 2D MMORPG. Урок 1.Увидев название статьи, вы подумали: «Сейчас зайду, и замучу свой WOW ил …: panovit | Паб

СОЗДАНИЕ ИГР #1: Создание 2D MMORPG. Урок 1.
Увидев название статьи, вы подумали: «Сейчас зайду, и замучу свой WOW или Lineage 2, пусть в 2D, но игра найдёт своего геймера.». Но это далеко не так, я объясню и покажу вам, как можно создать и запустить свою простую 2D MMORPG игру.
Движок (а если быть точнее, конструктор), один из самых удобных и простых в использовании. Несмотря на то, что движок довольно ограничен (из за устаревшей версии), создать небольшую MMORPG для своих друзей можно.
Уроки довольно простые, и движок освоят даже самые «криворукие» пользователи сайта (хотя таких то на КаНоБу нет наверное? =)).
Супер мощный компьютер для создания не нужен, а вот что бы держать сервер, найдите нормальный, мощный компьютер.
Итак, приступим.
ШАГ №1: Качаем и устанавливаем движок.
Качаем движок с официального сайта http://mmorpgmaker.org/?page_id=2.
Распаковываем в удобную для вас папку.*
*Тут я приостановлюсь, советую вам удобней расположить клиент и сервер, создать ярлыки, что бы было удобней запускать. Но об этом позже.
В распакованном архиве мы видим папки: Client, Docs, Server, WorldMap, GFX Converter.
Разберём по отдельности каждую папку:
Clients – папка отвечающая за файлы клиента, в неё находится EXE файл запуска клиента, файлы интерфейса, данные карты.
Docs – документация (в последней версии её мало)
GFX Converter – содержит конвертер обычных картинок, в картинки которые понимает движок игры, полезная вещь.
Server – папка, в которой находятся все файлы, которые нужны для запуска сервера.
WorldMap – программа, которая генерирует карту мира. (Пока работает не особо стабильно)
Шаг №2: Запускаем Сервер и Клиент.
Процесс довольно муторный и не интересный, но без этого никуда.
Заходим в папку SERVER, Запускаем файл Server.EXE, Ждём пока появится окошко сервера и закончится загрузка всех файлов сервера.

После того как файлы сервера прогрузились, заходим в папку Client, и запускаем файл Client.EXE. Появляется главное меню игры. Жмём Register.

Шаг №3: Регистрация аккаунта, создание персонажа, создание админа.
Регистрируем аккаунт (не важно, какой логин и пароль, главное не забудьте). После того как высветиться сообщение «You’r account has been created» (Ваш аккаунт создан) Жмём LOGIN, вводим Логин и Пароль. Дальше высвечивается список персонажей, жмём NEW.

Пишем любой ник, любой класс (неважно какой, потом свои создадите всё равно). После того, как вы удачно создали персонажа, выходим из клиента.
Заходим в папку Server, запускаем AcctMngr (Account Manager – Менеджер Аккаунтов). Видим вот такое окно, с уже созданным аккаунтом и персонажем:

Нажимаем на персонажа (Characters – ADMIN(M)), Дальше жмём на вкладку Stats, и в строке Admin ставим значение — 9.

После того как вы нажали SAVE, выходим из аккаунт менеджера и выключаем сервер (просто выключаем экзешник, часто он находиться в трее).
Перезапускаем сервер (Server — Client)
ШАГ №4: Админка, Редактор Карт.
Итак, после того как мы запускаем сервер, запускаем клиент и логинимся. Вы респаетесь на стандартной карте, на которой находится пару NPC и здание. Жмём F1 и попадаем в Админку, сейчас разберём админку по подробнее.

Ребят, вот тут надо понять одно, левая колонка отвечает за те действия, которые вы можете применить к определенному игроку (Кроме Редактора Карт, Респауна, и ОтчётаКарты), а правая за редактирование ВАШЕЙ игры.
Разберём сначала левое меню.

Player Name – Имя игрока, к которому вы хотите применить действия.
Warning – Дать предупреждение игроку, который указан в Player Name (далее PN)
Kick – Выкинуть из игры игрока, который указан в PN.
Info – Получить информацию о игроке, который указан в PN.
Location – Выдаёт местонахождение игрока из PN.
!!!Map Editor – самая главная вещь в движке, РЕДАКТОР КАРТ. Но к нему по позже.
WarpToMe – Игрок из PN, появляется около вас, не важно где он был до этого.
WarpMeTo – Обратный WarpToMe процесс, вы появляетесь рядом с игроком из PN.
WarpPlayer – перенести игрока из PN, на карту, которая указана в Map Number.
SetSprite – поменять спрайт игрока из PN, указав порядковый номер Sprite в колонке SpriteNumber.
Respawn – Перерождает всех NPC и все предметы на карте, указанной в MapNumber (если значение равно 0, то Респавнятся все карты на сервере).
MapReport – перемещает вас на нужную вам карту. (Помогает при редактировании карт)
BanList – Список за баненных игроков.
Ban – запретить доступ входа в игру персонажу из PN.
Jail – посадить в тюрьму игрока из PN.
Так, с первой колонкой разобрались, перейдём ко второй колоночке. Она довольно важна, так что читаем внимательнее.

Search – ищет всё и вся на вашем сервере.
Arrow Editor – редактор стрел (которыми лук стреляет).
NPC Editor – редактор NPC, как квестовых, так и монстров, торговцев.
Item Editor – Редактор вещей.
Shop Editor – редактор магазинов или торговцев.
Spell Editor – редактор скиллов.
Edit Dialogue – Редактор Диалогов
Quest Editor – Редактор Квестов
Sign Editor –Редактор Окошечек
Book Editor – Редактор книг, работает не очень хорошо.
Edit Morals – Редактор различных зон (PvP, PvE, SAVE ZONE и т.д.)
Create Guild – Создание гильдии (клана).
Edit Stats – Редактирование Персонажа
Rename – Переименование Персонажа
Edit Scripting – Знаете язык скриптинга? Вам сюда.
Сlass Editor – Редактор классов персонажей.
Chat Viewer – Показывает лог чата.
Guild/Admin Editor – Редактирование рангов Гильдии и Админки.
Движок Xtreme Worlds версии 1.0.3 Пока полностью не поддерживает Русский Язык, и расширить карту с помощью скриптинга невозможно. Но мы же хотим просто побаловаться, а вот есть движок Eclipse MMORPG Creator, там все эти возможности есть. Думаю позже мы разберём этот движок.
А сейчас, изучайте движок методом тыка, и ждите следующий урок, который расскажет вам о редактировании вещей, NPC, квестов.
http://narod.ru/disk/30493760001/GameCreating%20%231.docx.html
С Уважением, PanovIT.

Создание MMORPG игр. — Разработка игр

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

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


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

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

Шаг 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.
Перевод: AlexKom
Правка и дополнение: SanAV

• Создание MMORPG — Стоит Ли? Расчёт Времени Разработки « Геймдев: Основы Разработки Игр •

Это седьмая статья в цикле материалов для начинающих создателей игр — Создание MMORPG — стоит ли? Расчёт времени разработки 

1. Создание игр для начинающих
2. Специальности в геймдеве
3. Создание команды разработчиков игр
4. Управление командой разработчиков игр
5. Игровой движок — написать самому или взять готовый?
6. Как выбрать игровой движок или конструктор игр
7. Создание MMORPG или любого крупного проекта — стоит ли? Показательный расчёт времени разработки
8. Создание Модов для Игр — Удачный Старт для Разработчика!

Наверное, самая распространённая ошибка среди многих начинающих разработчиков, да и среди чуть более опытных коллег — это желание получить всё и сразу, то есть попытка откусить такой кусок пирога, который они не смогут проглотить. Стоит посетить любой геймдев-форум — и вы обязательно увидите эти бесконечные темы со сборами команды на «убийц ГТА», эпические MMORPG, «Сталкеры» и прочие-прочие-прочие, вызывающие лишь снисходительную улыбку у тех, кто хотя бы отдалённое представляет, какой объём работы стоит за громкими обещаниями и уникальными «фичами» таких проектов.

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

Почему Не Стоит Браться за Крупный Проект

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

Простой пример — все знают, сколько варится картошка, потому что делали это неоднократно, видели её в разрезе, щупали, пробовали и т.д. Но вот вам показывают кокос — и вы ничего о нём не знаете. Кокос опускают в кипящую воду и спрашивают — как долго он должен вариться, чтобы кожура стала мягкой? Вы делаете примерный расчёт, исходя из его размеров, и говорите, что вариться он будет… ну, скажем, 3 часа. Затем вам дают потрогать другой кокос, и вы понимаете, что этот орех с твёрдой скорлупой может не свариться никогда.

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

Показательный Расчёт Времени Создания Мини-MMORPG

Перейдём к более конкретному, прикладному примеру. Расчёт будет весьма грубым, но показательным. Итак, предположим, что мы хотим создать мини-MMORPG с игровым миром размером в одну локацию того же World of Warcraft. Сперва может показаться — чего же тут сложного, она ведь относительная невелика, да ещё если это и будет вся игра! А ведь дьявол, как говорится, кроется в деталях.

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

Теперь же пройдёмся по художественной составляющей, то есть по арту. Итак, средняя локация в MMORPG-игре. Чтобы наполнить её жизнью, нам понадобятся ( по минимуму ):

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

2) минимальный набор предметов экипировки для них — 5-6 предметов

3) 3-4 вида врагов с соответствующими анимациями

4) 5-6 видов NPC ( + анимация )

5) 5-10 зданий для создания города и отдельных «точек интереса» в пределах локации

6) мелкие элементы наполнения игрового мира, так называемые «properties», props, пропсы — бочки, заборы, телеги, ящики, дорожные указатели и т.д. — предположим, что нужно штук 15-20 различных мелких объектов такого рода

7) элементы ландшафта и природы — деревья, камни, трава, кусты. Допустим, 3-4 вида деревьев, столько же вариаций трав, 2-3 кустарника, 4-5 видов камней.

8) хотя бы 2 условных подземелья в пределах локации для квестов — скажем, рудник и некие древние руины

9) музыкальный трек для звукового сопровождения

10) звуковые эффекты для озвучивания игрового процесса

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

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

1) Создание качественной модели игрового персонажа в среднем занимает 10 часов. Два персонажа — 20 часов. Одна анимация — 4 часа. На двоих получается ещё 40 часов. Итого — 60 часов на двух персонажей.

2) Предметы экипировки. Пусть будет по 4 часа на каждый с учётом текстурирования. +50 часов для двоих персонажей.

3) 4 вида врагов. 40 часов на моделирование+текстурирование, по 10 часов на создание анимаций для каждого — итого 80 часов на врагов.

4) 6 NPC — 60 часов. По 6 часов на анимацию каждому — выходим на ~100 часов.

5) 5-10 зданий. Возьмём 7. Домик, думаю, также часов за 10 вполне можно сделать. 70 часов.

6) 15 мелких объектов — пусть будет по 2 часа на каждый, итого ещё 30 часов.

7) Природа — возьмём 12 элементов, по 4 часа в среднем на каждый. Итого 50 часов.

8) Рудник + руины = ~ 100 часов в сумме.

9-10) Будем надеяться, что звук к игре удастся сделать за 30 часов.

Итого получается 570 человеко-часов только на то, что приведено в списке. Или 23 дня круглосуточной работы, или 71 день работы по 8 часов в день.

Добавляем столько же на программную часть и 35 дней ( половину от 71 дня ) на реализацию геймплея, скриптов и т.д. — выходим на 180 человеко-дней. То есть один человек, имеющий все необходимые навыки, будет заниматься этим минимум полгода.

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

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

Если принять за логичный факт то, что без выходных работать никто не будет, то даже для профессионального разработчика 180 человеко-дней превратятся в 235 календарных дней, то есть почти 8 месяцев.

Начинающий разработчик, естественно, не профессионал, поэтому посвятить игре может лишь свободное время ( после учёбы либо работы ). Допустим, он фанат своего дела, который не отступает и не даёт себе поблажек — и работать над игрой он может в среднем 4 часа в день. Значит, 8 месяцев превращаются в 16.

И ведь это ещё не всё… За рамками расчёта оказалось громадное количество аспектов, таких как рисование скетчей, проработка экономики, создание ландшафта ( террейна ), дизайн локации, танцы с бубном вокруг различных багов, ошибок, которые не позволяют всему работать «как надо», не было сделано поправок на опыт — вернее, его отсутствие, то есть это будет эдакое «обучение на лету». Кроме того, ведь есть ещё тестирование, а после релиза любую MMORPG нужно поддерживать — исправлять баги, баланс, работать с сообществом… В общем, всего и не упомянешь.

Эти 16 месяцев можно смело умножать на 2, а то и на 3 — и только так можно получить примерную, более-менее адекватную оценку  того, сколько же всё-таки времени займёт разработка такой игры. Вообще это очень правильный ход — умножать свои расчёты времени минимум на 2. Если вы думаете, что создание игры займёт у вас месяц — смело рассчитывайте на два. И чем сложнее проект — тем больше коэффициент умножения. В IT известно множество случаев, когда расчёты времени оказывались неверными на порядок, то есть в 10 или более раз!

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

Надеюсь, мне удалось наглядно показать, почему же подавляющее большинство любительских MMORPG-проектов изначально обречены остаться незавершёнными — это банальная нехватка необходимых ресурсов. Подобный же расчёт можно провести и для любого другого жанра игр, требующего большого количества контента и объёма выполняемых работ — например, «убийца GTA» потребует от своего создателя ничуть не меньше времени, чем средняя MMORPG, а возможно даже и больше.

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

Добавлено: один из комментариев к этой статье, оставленный читателем, подсказал мне, что её завершение на столь минорной для начинающего разработчика ноте делает материал обескураживающим и оставляет впечатление разочарования, поэтому я решил уточнить и дополнить своё мнение на счёт разработки подобных проектов. Как это обычно и бывает, не стоит бросаться в крайности, а из любого правила бывают исключения. Так что — такое ли уж зло эти «MMORPG-проекты»? Очевидно, что всё далеко не так просто, как кажется на первый взгляд.

Даже проект разработки MMORPG усилиями начинающих разработчиков может быть оправдан и более чем полезен и адекватен, если целью такого проекта является получение опыта и совершенствование навыков работы его участниками. Иными словами, если с самого начала отказаться от декларирования обязательного коммерческого успеха будущего продукта, не думать о своей игре как о «убийце World of Warcraft», а вместо этого сосредоточиться на самосовершенствовании, получении опыта работы в команде, обучении новым приёмам и технике работы над игровыми проектами, формировании понимания игровой индустрии как таковой и разработке игр в частности — то такой проект заслуживает всяческого поощрения и поддержки.

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

В завершение могу лишь добавить — дерзайте!

Создавая миры: — как создать свою РПГ?: Hzpriezz | Паб

— создание алгоритма смены погодных условий и воздействия погодных условий на персонажа;

— создание дроп листа, привязка дропа к предметам и персонажам, ввод определения «редкости» и условий получения свойств и качеств, либо системы генерации свойств оружия и предметов в рамках заранее прописанных параметров и свойств;

— расчет показателей урона от скиллов, взаимодействия скиллов, создание конечных автоматов для анимаций(объем), условий взаимодействия скиллов, програмирование шейдеров (для Unity есть Shader Graph, он упрощает в разы все);

— создание гибкой и крутой боевой системы, с расчетом времени нажатия кнопок, задержкой между ударами, различными сериями, привязка направления движения к удару. с этим любой проект превращается в зубодробительный слешер с крутой боевкой, но если нам это не нужно то задача становится в разы проще. Как пример любая игра из серии Batman ,Devil May Cry, Street Fighter , Witcher;

С — Создание УЛЬТРАСЛОЖНЫХ ФИШЕК:

— создание AI Director, это АИ который сам натравливает на тебя врагов в зависимости от того КАК ТЫ ИГРАЕШЬ , меняет погодные условия, регулирует динамику происходящего. Подобная система есть в Left 4 Dead. Это удобно для того чтобы подстраиваться под игрока и делать его жизнь невыносимой, объем работы очень большой;

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

Заставить все это работать как единый механизм — MISSION IMPOSSIBLE

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

Как во все это ИГРАТЬ а не страдать, как вести повествование? АИ режиссер справится с сценами и будет создавать экшен там где игрок есть, но это слишком большая и сложная комплексная система, для того чтобы использовать ее где угодно, как все это упростить, но оставить мир живым и интересным?

Например

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

Вывод

Нам не нужно быть очевидцем события, нам нужно ЗНАТЬ о них, иными словами нам нужна информация.

Т.е игра должна донести до нас что Вася жлоб, через Петю. Нам будет достаточно просто скрипта и заранее заготовленных сцен , заранее заскриптованных сцен, заранее ПРОПИСАННЫХ , пусть их будет 200-300 событий, но это проще чем заставить игру СОЗДАТЬ эти события.

Ведь игре нужно будет учитывать характер НПС (!) их показатели и МОТИВЫ (никто не говорил что будет легко) симулировать действия и ВЫБОР НПС (!) , затем сообщать о результате события игроку, создавать условия на месте действия (раскидать трупы дроп и тд.)

И еще все это должно быть НАРРАТИВНЫМ , т.е вписываться в сюжет и не противоречить созданной ИГРОВОЙ РЕАЛЬНОСТИ. Т.е если средневекового рыцаря забили фаллосами инопланетяне, это здорово, но если это не игра по лицензии South Park , то подобное событие не должно существовать в НАШЕЙ ИГРОВОЙ ВСЕЛЕННОЙ.

Именно это ключевой момент для создания УБЕДИТЕЛЬНОСТИ происходящего.

Поэтому в многих ММО трудно вжиться в роль, есть голдселлеры, куча лишенго в чате и прочие радости.

О том как все это систематизировать, отрезать лишнее, оставить лучшее и при этом сохранять единство вселенной в следующем материале.

UPD

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

Для начала — почему мана? почему хп? везде одно и тоже, когда появится
НОРМАЛЬНЫЙ рандом а не ВКР от которого глаз не дергается только у мертвых? Почему нельзя взять и сделать офигенную симуляцию жизни окружающих персонажей?

P.S. Если тема понравилась, жду фидбеков. Ваше мнение отличается от моего? — объективная критика приветствуется. Хотите дополнить? — пожалуйста.

Хороших выходных

Как устроен левел-дизайн в MMORPG — Gamedev на DTF

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

Левел-дизайн ранних ММО отталкивался от уже устоявшихся принципов других жанров. Ultima Online опиралась на популярные изометрические RPG, а первая трёхмерная MMORPG Meridian 59 — на Might & Magic и Wizardry. Впервые мир, более-менее похожий на современные MMORPG, появился в EverQuest в 1999 году.

А в 2004-м вышла World of Warcraft и задала стандарты левел-дизайна в MMORPG на следующие 15 лет.

Пространство и контент

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

1. Сделать так, чтобы никто никому не мешал

Основной вопрос левел-дизайна в MMO, — «как сделать так, чтобы на одной локации игроки не мешали друг другу?» Эта проблема преследует жанр ещё с выхода World of Warcraft, и разработчики пытались решить её самыми разными способами.

Как сделать MMORPG

Предисловие

Создание MMORPG (массовой многопользовательской сетевой ролевой игры) инди-разработчиком действительно возможно. Эта статья посвящена проблемам разработки MMORPG. Если вас интересует только решение, ознакомьтесь с нашим активом Unity MMORPG — uMMORPG, в котором используется новая сетевая система Unity UNET.

Большой, Большой, Большой

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

Что большинство людей забывает о MMORPG, так это то, что это огромные программные проекты с сотнями тысяч строк кода. Разработка такой большой архитектуры — действительно сложная задача. Если вы немного задумаетесь, то даже создание простой MMORPG с базовыми функциями — это так же важно, как создание ранней версии Firefox, Photoshop или любого другого крупного программного обеспечения, о котором вы можете подумать прямо сейчас.Это невероятно много работы.

Дорого, Дорого, Дорого

По слухам, разработка ранней версии World of Warcraft стоила около 50 миллионов долларов. Если вы только начали заниматься разработкой игр, велики шансы, что у вас не так много денег, чтобы инвестировать в игру.

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

Давай займемся математикой. Если мы предположим, что около 30 миллионов из этих 50 миллионов пошли на оплату разработчиков за создание кода, и если мы предположим, что эти разработчики работали за 30 долларов в час, это означает, что для создания кода потребовалось около один миллион часов . Предполагая, что вы можете работать над ним 10 часов в день и предполагая, что вы работаете в два раза быстрее, чем эксперты, которые работали над WoW, это составляет 5000 дней или 14 лет работы только над кодом. Это много времени.

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

Список бесконечен …

Используя то, что уже есть

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

Игровые движки — звери , не меньше. Над ними постоянно работают команды высококвалифицированных разработчиков, поэтому мы можем сосредоточиться на самой игре. И самая важная часть использования игрового движка — это то, насколько до смешного мы можем быть продуктивными. Не имеет значения, простая ли это игра, такая как Pong, или трехмерная игра, такая как шутер от первого лица, мы можем создать ее за несколько часов с менее чем 100 строками кода. Unity Engine не так давно выпустила свою сетевую систему UNET, что является огромным шагом на пути к цели MMORPG.UNET позволяет нам разрабатывать клиент и сервер в одном проекте, который использует одни и те же скрипты для обоих (что экономит нам месяцы или даже годы работы).

Игровые движки

великолепны, именно то, что нам нужно!

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

Та же концепция может быть применена к звукам, текстурам, ландшафтам и многим другим частям игры.Повторное использование того, что уже есть, может изменить время разработки от 7 до 15 лет.

Хакеры

Если ваша игра добьется большого успеха, она также привлечет внимание хакеров. Возникает вопрос: что вы знаете о создании защищенных инфраструктур для серверов? Как вы можете гарантировать, что не каждый 14-летний хакер, желающий стать хакером, сможет проникнуть на ваши серверы? Как дублирование предметов работает в современных MMO и как его предотвратить? Что такое DDoS-атаки и что мы можем с ними сделать? Как сделать так, чтобы ни у кого из игроков не было миллиардов монет, которые внезапно разрушили бы экономику?

Что вы знаете о бизнесе?

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

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

Что делать, если вы проиграете?

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

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

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

Проект «Это твоя жизнь»

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

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

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

Сводка

Да, это возможно. Если вы можете это мечтать, значит, вы сможете это сделать.Если вы на этой земле делаете MMORPG, то простая статья, подобная этой, вас не отпугнет. Вы можете воплотить свою мечту в реальность, если действительно этого достаточно сильно хотите.

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

Если вы все еще не боитесь, то обязательно попробуйте uMMORPG!

.

Что такое MMORPG? — Полное руководство по MMO-играм

Игры

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

• Что означает MMORPG?
• Как играть в MMORPG онлайн?
• Какие жанры MMORPG самые популярные?
• В чем разница между MMO и MMORPG?

Что такое MMORPG-игры?

Акроним MMORPG означает «многопользовательские онлайновые ролевые игры».

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

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

Проще говоря, некоторые из самых громких имен в мире MMORPG имеют миллионы подписчиков, которые регулярно погружаются в игры.

Однако, чтобы понять, что же в конечном итоге составляет MMORPG-игру, стоит потратить некоторое время на изучение компонентов, которые обычно используются при создании RPG-игры.

Что такое ролевые игры?

Как вы уже догадались, RPG означает «Ролевые игры». Такие названия включают в себя некоторый элемент, когда игрок принимает новый образ и выполняет действия в качестве этого другого персонажа.

ролевых игр существуют уже несколько лет и многие годы существовали офлайн в других формах.

Настольные игры, такие как Dungeons & Dragons, являются ярким примером, в то время как в других автономных играх люди буквально берут на себя другую роль, физически одеваясь и взаимодействуя с другими в качестве этого человека.

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

Текстовые ролевые игры — ранний пример этого, но по мере того, как технологии становились все более сложными, появились новые игры.

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

Где и как играть в MMORPG игры

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

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

Самые известные имена в мире MMORPG по-прежнему прочно связаны с ПК и Mac, но есть ряд популярных игр, в которые также можно играть на других платформах, включая консоли и даже мобильные телефоны и планшеты.

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

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

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

В чем разница между MMO и MMORPG?

Как мы уже обсуждали в другом месте этого руководства, MMO относится к многопользовательским онлайн-играм.

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

Таким образом, MMORPG — это, по сути, поджанр в более широком мире MMO, с их ключевым аргументом в пользу использования ролевых элементов. Поскольку вы увидите, что MMORPG и MMO часто упоминаются вместе, важно помнить о ключевых различиях между ними.

ММОРПГ — самые популярные ММО

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

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

Как и во многих других областях игр, MMORPG-игры могут охватывать огромное количество различных настроек. Имея это в виду, смотрите ли вы что-то в жанре научной фантастики, с уклоном на исторические события или игру в мультяшном стиле — вы всегда можете найти заголовок, который в конечном итоге соответствует вашим вкусам.

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

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

.

Что такое MMO, что такое MMORPG и чем они отличаются

В чем разница между MMO и MMORPG?

Это одно и то же? Как их отличить? В какую из них я играю прямо сейчас, и какое отношение это имеет к реактивным гранатам?

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

Как ни странно, ответы на все эти вопросы довольно просты:

MMORPG — это разновидность MMO-игры.

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

Что такое MMO?

Давайте начнем с основ: что означает MMO? MMO-игра — это «многопользовательская онлайн-игра» .

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

Что такое MMORPG?

MMORPG означает «Многопользовательская ролевая онлайн-игра».

Еще одно несколько комичное определение — «Многие мужчины в сети играют роль девочек в ролевых играх» (это забавно, потому что это правда).

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

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

В чем разница между MMO и MMORPG?

Когда кто-то спрашивает, что такое игра, они часто ссылаются на ее жанр или поджанр. Игра «это» шутер от первого лица, игра на выживание или ролевая игра. То же самое и с MMO.

Нет игры — это просто MMO-игра.Это все равно, что сказать, что игра — это «многопользовательская игра». Это хорошо, но на самом деле ничего не говорит вам о самой игре, кроме того факта, что вы можете играть в нее с другими людьми (или против). Игра должна относиться к определенному жанру.

Многопользовательские онлайновые ролевые игры или MMORPG — это MMO-игры, принадлежащие к жанру RPG.

Это ролевые игры, в которые может играть онлайн большое количество игроков одновременно.

Разница между MMO и MMORPG заключается в том, что все MMORPG являются MMO, но не все MMO являются MMORPG.

MMORPG по определению является ролевой игрой, в то время как MMO может быть чем угодно: от боевиков Battle Royale до стратегии в реальном времени или даже нового типа интерактивного опыта, бросающего вызов жанрам.

MMORPG — это разновидность MMO-игр .

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

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

Как распознать MMORPG

Давайте разберем жанр MMORPG на его основные компоненты — MMO и RPG. Мы уже рассмотрели, что такое MMO, поэтому давайте поговорим о том, что делает хорошую ролевую игру.

видеоигр RPG, часто называемых CRPG (Computer Role-Playing Games), во многом заимствовали у своих предков, написанных ручкой и бумагой. Например, у них одинаковый уровень настройки персонажа.Игроки могут создавать и настраивать своих персонажей, представленных цифровым аватаром.

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

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

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

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

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

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

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

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

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

Хорошими примерами популярных MMORPG являются World of Warcraft, Guild Wars 2, The Elder Scrolls Online, Star Wars: The Old Republic и EVE Online.

Надеюсь, теперь вы знаете, как отличить MMO и MMORPG, и как распознать MMORPG, когда вы играете в нее.

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

.Независимость от языка

— как сделать частный игровой сервер?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

2. Авторизоваться
   зарегистрироваться

3. текущее сообщество
   

.