Как создать мморпг

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

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

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

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

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

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

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

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

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

В таблице (см. табл.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 года, и путь еще далеко не закончен: впереди нас ждет клевая система имитации жизни, подземелья (в космосе, вы представьте!), батлграунды, новый контент и многие другие прекрасные вещи.

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

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

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

Наша новая идея ((вставьте название концепта, который уже был сделан 10000 раз))
и мы думаем, это будет действительно круто. Я дизайнер игры, и несколько человек мне
помогают, но нам нужны программисты. Если Вы хотите присоединиться, пишите нам на
убогий.адрес@бесплатнаяпочта.ру

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

Это *оскорбляет* нас, как программистов

Игры ещё не являются зрелым средством массовой информации, и многие люди не принимают их всерьёз. По разным причинам бесчисленные люди думают, что программирование игр — лёгкая работа для бездельников, когда на самом деле — это одна из самых сложных трудовых карьер, по которой может пойти человек. Результат очень поощряет, но только потому, что это настолько безумно сложно. Такой тип сообщения на форуме буквально оскорбителен для нас, потому что сказать «у меня нет опыта в программировании, но я легко сделаю MMO», на самом деле звучит как «То, чем вы, парни, гордитесь, *таааак* легко сделать.»

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

Вы не являетесь дизайнером, и вам он не нужен

Писатель? Хорошо. Дизайнер характеров и персонажей? Хорошо. Дизайнер уровней? Да. Дизайнер? Нет.

«Дизайнер» — это один из самых общих существующих терминов, и весьма мало людей знают, что означает это слово. Идея игры, где вы находитесь на Луне, в виде ниндзь и сражаетесь с крабами-мутантами это НЕ дизайн, это концепт (и к тому же весьма убогий в этом случае). Дизайн вычёсывает всевозможные аспекты игры очень мелкой гребёнкой и продумывает все мелочи.

• Что определяется, как укрытие.
• Может ли укрытие «сломаться», прийти в негодность?
• Какие анимации понадобятся персонажу, чтобы присесть (встать) в укрытие, стрелять оттуда, перезарядиться, выйти из укрытия, и т.д.
• Какие клавиши игрок должен нажать, чтобы присесть за стену или встать за угол?
• Как насчёт выйти из укрытия?
• Как не дать врагу, идущему из-за вашей спины, убить вас, когда вы в укрытии и не видите, что происходит сзади?
• Предыдущий вопрос не может быть решён универсально, поэтому для каждого игрового уровня нам нужно убедиться, что такая ситуация не возникнет.
• Как вы укроетесь от Берсеркера? (проблема, с которой, я думаю, они не очень хорошо справились)
  Берсеркеры — слепые существа, чувствующие запах и тепло, атакующие на звук, могут с разбегу пробить обычную кирпичную стену
• Как насчёт предотвращения случайного использования укрытия, когда вы этого не хотите? (Проблема, на самом деле, не была решена в первой части GoW)
• Этот список может продолжаться до 60 или 70, но я остановлюсь здесь.

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

Это хорошо составленный и достаточно длинный список, но даже в нём далеко не всё раскрыто.

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

Команда, которую вы собираете

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

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

Хорошие участники команды ищут хороших лидеров.

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

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

Если Вы задаёте пространные вопросы о языках программирования и движках, вы не готовы создать 3D игру, не говоря уже про MMO.

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

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

Примечание: Как я упомянул ниже, мне следовало подчеркнуть разницу между глупыми вопросами о движках, обычными вопросами о движках и обычными вопросами новичков. Вы можете спросить «какой движок мне использовать», но лучше всего задать такой вопрос с предоставлением информации о вашем проекте. Не существует движка-повелителя, выкованного в огне Роковой Горы, который бы делал всё, что может вообразить простой смертный. На каждый сценарий имеется движок, примерно подходящий под его потребности. Это нормально — задавать вопросы о движках, но указывайте ваши потребности и цели. Если вы новичок, и вам требуется хорошая инструкция как научиться программировать, просмотрите некоторые старые темы и статьи на форуме, перед тем, как задавать вопросы на форумах. Задавать вопросы хорошо, но оглянитесь вокруг, скорее всего на них уже есть ответы.

Не существует уроков «как сделать MMO».

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

Все эти аргументы даже не должны были прозвучать, потому что:

Это просто бесцельно и непрактично

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

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

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

Создайте многопользовательскую игру

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

Но прежде всего, повторю что-то, что надо повторять постоянно:

Устанавливайте себе реальные цели

Pong -> Крестики-нолики -> Тетрис -> Mario -> doom

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

Когда-то я слышал, как кто-то сказал «Если вы стартовали на Луну и промахнулись, то вы летите к звёздам», и мой ответ был «А, вы имеете в виду тот марсианский зонд, который промахнулся мимо точки посадки, разбился и сгорел?»

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

18 декабря 2009 (Обновление: 3 авг 2014)

Создание MMORPG — Стоит Ли? Расчёт Времени Разработки

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

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

Рекомендуемые Материалы По Теме:
Об авторе: Сергей “Treidge” Данченко

Сергей «Treidge» Данченко — автор блога 3DG.Me, вольный 3D-художник и разработчик игр, веб-разработчик на Drupal и человек-оркестр с опытом в некоторых других областях. Личное кредо — «хочешь сделать что-нибудь хорошо, сделай это сам». В моменты особого вдохновения пишет стихи и играет в волейбол. Основные профессиональные инструменты — Autodesk Maya, Autodesk Mudbox и Adobe Photoshop. Без ума от индюков и попугаев. Спасибо за внимание, заходите снова!

• 32505 просмотров

Комментарии
Виталий 18 Июн, 2011

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

Treidge 19 Июн, 2011

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

анОним 18 Апр, 2012

Идеи — самое дорогое в геймдеве. Также, как в кино. Уникальный сценарий дороже золота. Но, к сожалению, современный менеджмент с потрясающей легкостью любую конфетку превращает в дерьмецо.
Статья — полнейший бред. Если так работают разрабы, тогда понятен бесконечный поток фейлов, выдаваемый игровой индустрией.
По поводу художников. я понимаю, хочется выделить своих)) Но. согласование концептов, окончательные варианты на подпись. и всё. Художник свободен. Кстати, какое отношение художники имеют к аниматорам и моделерам??
А вот со скриптами как-раз и происходит основной геморрой. Риск превращения проекта в бесконечную альфу.

Treidge 18 Апр, 2012

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

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

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

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

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

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

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

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

Анонимно 30 Июл, 2012

присоединаюсь и от себя добавлю :
если честно,то в некоторых местах расчет времени просто бредовый.особенно по части моделирования.итак, цитата:
1) Создание качественной модели игрового персонажа в среднем занимает 10 часов. Два персонажа — 20 часов. Одна анимация — 4 часа. На двоих получается ещё 40 часов. Итого — 60 часов на двух персонажей.
про создание качественной модели более менее в точку.можно быстрее если руки прямые.насчет анимации — вранье сплошное.при наличии любого нормального 3д редактора создание анимации на персонажа с учетом наличия тех же рук не займет более 2-х часов.теперь вопрос: зачем на двух персонажей одинаковой функциональности делать разную анимацию. в чем смысл создания 2-х разных прыжков-взмахов рукой итд итп.в любой он-лайн игре у персонажей одна и та же анимация,иногда слегка модифицированая.создание пакета анимации с модификациями на разных персонажей — около 2-х с половиной часов(если их 2-е).итого 22,5 часа на персонажей.
предметы екипировки никогда не займут 4 часа если вы не создаете высокодетализированые модели с 10-ю миллионами полигонов на каждой.в мало продвинутых играх одежда и вовсе не модель,а лиш картинки натянутые на модель персонажа.максимум 2 часа с учетом текстурирования если это модель.24 часа если это по 6 предметов на каждого персонажа.в сумме 46,5 часов.
враги.возьмем 4 врага.в большом паке анимаций он не нуждается.ходьба-бег атака + какое то там заклинание.максимум по часу.44 часа. 90,5 часов всего.
циата:
4) 6 NPC — 60 часов. По 6 часов на анимацию каждому — выходим на ~100 часов.
вопрос : почему у нипов анимация должна занимать больше чем у игровых персонажей.
итак.нипу МАКСИМУМ периодические движения уками-головой чтобы не стоял как столб,+ взять уже сделанную в нескольких екземпляра ходьбу либо от персонажа либо от врага (если и те и другие не одноногие пираты или пришельцы-осьминоги ).+ вот уж для нипов НИКОГДА не делают индивидуальной анимации (если это трейдеры или нипы которые просто дают и принимают квесты, а не наглядно показывают как управлять летающей тарелкой, доить корову,танцевать брейк итд итп).анимация максимум полчаса для самых ламеров с минимальным опытом.60,5 часов.всего 151 час.уже в половину меньше того что предсказывал афтар.
5) 5-10 зданий. Возьмём 7. Домик, думаю, также часов за 10 вполне можно сделать. 70 часов.
ведь зависит то от самого домика.если вы хотите построить 7 Букингемских дворцов с екс- и интерьером высочайшей детализации то вам и полгода не хватит.создавать среднестатистический домик 8х8 площадь и 4 в высоту с скромненьким екс-и интерьером дело 3-х часов.допустим будут более большие и сложные домики в пару этажей и средней детализацией.по 5 часов на штуку.еще + 35 часов.итог : 186 часов.
6) 15 мелких объектов — пусть будет по 2 часа на каждый, итого ещё 30 часов.
живих или нет?если нет то по часу.и это еще с хорошей детализацией.+ 15 часов.201 час господа.
7) Природа — возьмём 12 элементов, по 4 часа в среднем на каждый. Итого 50 часов.
я возьму больше елементов что бы показать насколько заблуждается автор.
допустим 6 кустов и 6 деревьев средней детализации (все разные).1 анимация на деревья и 1 на кусты = час.сами модели по полтора часа каждая (с большоооооооооооооооооой натяжкой)19 часов.220 часов всего.3 камня = по 20 минут каждый.всего час.221 час.4 разных пучка травы дело 40-ка минут (с такой же огромной натяжкой).и это если не брать во внимание что трава АБСОЛЮТНО ВСЕГДА не является моделью,а плоским обьектом зачастую рисованым.222 часа (для удобства).
рудник и руины.100 часов — откровенно много,если у вас нормальный world editor с нормаальным интерфейсом создание кубиков труб и сфер и соединения их воедино у вас не займет более 30-ти часов на одну постройку.60 часов.положить текстуры по 2 часа тупого клацания туда сяюда.64 часа.+ свет займет еще по 2 часа на обе постройки.68 часов.290 часов.
про звук тоже не совсем верно.если есть программа и опыт работы в ней ну и конечно ты знаеш что хочеш написать то создание займет 10 часов максимум.+ придумать еще 5 часов.15 часов.звуковые эфекты уймами лежат на просторах интернета.их поиск займет 30 минут.15,5 часов.305 с половиной часов в итоге.НЕ 570.почти в 2 раза меньше.
програмная составляющая НАПРЯМУЮ зависит от того что было с начала.если и сам двиг и сервер-клиент к нему писал 1 человек с 0 на С# то это примерно 2 года.если были движок + сервер клиентская часть то обьем работы сокращается на многое множество.зависит от того что за двиг и клиент сервер.
далее это зависит от пряморукости и глубины познаний человека который этим занялся.так что высчитывать время затраченное на подготовку программной части методом приведеным автором — просто глупость.
снова цитата:
И ведь это ещё не всё. За рамками расчёта оказалось громадное количество аспектов, таких как рисование скетчей, проработка экономики, создание ландшафта ( террейна ), дизайн локации, танцы с бубном вокруг различных багов, ошибок, которые не позволяют всему работать «как надо», не было сделано поправок на опыт — вернее, его отсутствие, то есть это будет эдакое «обучение на лету». Кроме того, ведь есть ещё тестирование, а после релиза любую MMORPG нужно поддерживать — исправлять баги, баланс, работать с сообществом. В общем, всего и не упомянешь.
рисованием скетчей должен заниматся художник професионал,а не моделер-аниматор-програмист который в 1 рыло делает всю мини мо (ммо это нельзя назвать при таком обьеме игры).»проработка экономики» — ну какая тут *** экономика.тут 2 персонажа 6 нипов и 4 вида мобов на всю крохотюсенькую локу.создание ландшавта при готовом скетче дело пары часов.дизайном занимаетс явсе тот же художник профессионал.а мы потом тупо берем и растыкиваем модельки нипов и мобов по готовому ландшавту.еще пара часов.баги и ошибки — это вообще отдельная тема,и к созданию не имеет никакого отношения.если игра работает- она создана и пляшем.а процес фиксирования багов и ошибок это уже ее доработка.и какой баланс при наличии 12-ти вещей и 2-х персонажей. автор забыл что предлагал сделать в самом начале статьи.с каким сообществом. епический фейспалм вызвала у меня статья.

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

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

Treidge 30 Июл, 2012

Пожалуйста. Позволю себе лишь заметить, что так рьяно оспаривать цифры в показательном рассчёте, полном приближений и грубых округлений — это всё равно, что критиковать промышленные весы за то, что они не взвешивают килограммы, а оперируют центнерами. Пресвятая ряженка! Какая для начинающего разработчика разница, понадобится ему 2000 часов или «всего лишь» 500? С одинаковой долей вероятности он не осилит любую из этих цифр. Впрочем, с приведёнными вами цифрами спорить нет смысла — если вы действительно работаете так, как расписали, то это вызывает только радость. В некоторых местах вы, безусловно, правы, но это не меняет всей картины.

Также не стоит забывать, что в последние 1-2 года всё больше людей хотят видеть MMORPG не как клон World of Warcraft с примитивной графикой, а как «Кризис, но только онлайн, и чтобы много-много людей на одном сервере и чтобы пыщ-пыщ и ололо!». Вполне очевидно, что в такой игре качество графики уже должно быть на совсем другом уровне, а следовательно и затраты времени на её создание значительно возрастают. Хоть в начале статьи и сказано, что рассчёт относится к игре с технически достаточно простой графикой, большинство новичков без промедления перенесут его и на свой «Crysis Online», посему, как мне кажется, лучше преувеличить, чем серьёзно недобрать в цифрах.

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

Виталий 19 Июн, 2011

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

Treidge 19 Июн, 2011

Если хочется что-то реализовать на практике — могу порекомендовать «качать скилл» художника, так как сценарист-идейник — это хорошо, но только в дополнение к чему-то более осязаемому. А с хорошими навыками художника как минимум игру в 2D можно будет сделать по большому счёту своими силами. К просто сценаристу-идейнику люди не пойдут, а если пойдут — это будет постоянная война с тем, что и как нужно делать и, собственно, почему это не делается . Об этом подробнее я уже писал в статье Создание команды разработчиков игр.

PechenkOo 19 Июн, 2011

Посоветуйте )) попробую что это такое создание игр )
рисовать умею ) будем учиться кодить 😀

PechenkOo 19 Июн, 2011

теперь у вас +1 пользователь )))
тот же Виталий 😀

Treidge 19 Июн, 2011

Как говорят буржуи — welcome и enjoy your stay

Mana_Banana 29 Июн, 2011

А я пожалуй сейчас закончу универ, докончу сценарий, на расслабончике соберу хорошую бригаду за год и возможно года через 3. с половиной закончу проект.
Благо уже более менее раскидал стратегический план и немного текущий.
Конечно, дело тяжелое. Работа есть работа. Одно радует — никто не будет подгонять. Ибо со своими идеями я не пойду к большинству современных издателей. Сроки катастрофически малы и если делать сиквел — они еще больше уменьшаются, от чего следующая игра в серии становится казуальной из-за недостатка времени.
Буду еще читать, что у тебя здесь есть. Хорошо пишешь ]:3

Treidge 29 Июн, 2011

>> на расслабончике соберу хорошую бригаду

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

Если будет что рассказать по своему проекту — милости прошу в Форум, всегда буду рад поучаствовать в обсуждении чего-то интересного . Да и может подскажу чего, если потребуется .

Рад что нравится, как пишу — стараюсь

Mana_Banana 29 Июн, 2011

Понимаш. Если мой проект графически будет выглядеть устаревшим — это не беда, потому что я буду, да буду, делать его хардкорным(!).
Внимание к деталям, к вещам, к характеристикам героев. Заправим все это хорошей историей. В общем олдскул, в котором к тому времени конечно же будут все нуждаться. (но это титанический труд)
Но это пока все планы, планы над которыми я уже 3 года с лихвой и работаю. Все началось с заметок в блокноте ]:)
Мне 22, уже. почти. И чем больше я расту, тем больше желаю этого.
Насчет выложить, это только к концу лета. Диплом сдам, перееду, за месяц приведу книжку в порядок и буду по тихому выкладывать. Спешить мне некуда. ]:3

Treidge 29 Июн, 2011

Могу посоветовать изучить историю создания MMORPG Eternal Lands — в сети плавает несколько статей от её создателя, Radu Pivantu. Наверное, единственный пример MMORPG, созданной энтузиастом(и) и живущей по сей день вот уже в течение 8 лет. Их опыт наверняка пригодится.

Mana_Banana 29 Июн, 2011

И да, «на расслабончике» я имел ввиду то, что хочу привлечь знакомых в проект.
Как ты сам понимаешь — ошибка новичка — черезмерная импульсивность. Большинство начинают превлекать в проект каких-то незнакомых и смонительных личностей, все это так же быстро разваливается, как и строилось.
У меня есть пара креативненьких занкомых для арта, прикуренный програмист и я . стратег-сценарист. хехе.
А там посмотрим, кто еще к нам присоединиться. Обычно по форумам исЧу. Общаюсь, знакомлюсь, смотрю, но не предлогаю.
Общение со временем перерастет в дело.
Просто не буду торопить все это. ]:3

Treidge 29 Июн, 2011

О, локальное ядро команды — это плюс. Вокруг такого уже можно что-то строить.

PechenkOo 29 Июн, 2011

Если нужна помощь в прорисовке и создании различных картинок, пейзажей, текстур и тд обращайся )) буду рад помочь ))

Анонимно 14 Авг, 2011

Я щас попробую написать ММОРПГ напишу сюда через 3 дня чего получилося по моему это чуш все что тут написано

Treidge 14 Авг, 2011

Дерзай, будет очень интересно посмотреть, что получилося

Тиумр 14 Авг, 2011

Ок напишу ссылку на сайт с клиентом кому интересно дня через 3-6 примерно 🙂 прикольный сайт как раз в тему статья я как раз пишу ММОРПГ которая порвет WOW и тому подобное причем в одиночку пишу :))) и не полтора года вовсе

Treidge 14 Авг, 2011

А можешь дать какуя-нибудь дополнительную инфу о проекте? Про что, на чём пишется, какой функционал планируется и т.д. Если есть желание поделиться — Форум будет рад принять всех страждущих . Ну а если нет — подождём 3-6 дней.

Тиумр 14 Авг, 2011

Краткое описание ПРежде чем начать писать мморпг Нужно точно знать в чем Она будет Лучше А рисовать можно И до пенсии БЫЛОБЫ в Чем :)))))) Есть Ряд технических вопросов которые некоторые не смогут решить и за всю жизнь у меня примерно 3 пункта которые опрежают время лет на 6 Описание игры примерно одним словом что бы раньше времени рынки не баламутить НЕВОЗМОЖНО это что смогут сказать NcSoft Blizzard Entertainment Beijing Perfect World Только при этом условии есть смысл заниматься созданием ММОРПГ

Тиумр 15 Авг, 2011

Эксклюзивно выложил Информацию о будущей игрушке На форуме в разделе содание MMORPG :))) ПИшу дальше посмотрим чего получиться Очень не хотелося но да ладно фиг с ним порвем WOW и EVA

Тиумр 15 Авг, 2011

На форму в разделе Создание MMORPG