Создание мморпг игр: Разработка ММО РПГ – практическое руководство. Эпизод 1 / Хабр

Содержание

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

Вам интересно, сколько стоит разработка онлайн-игры?
Вы хотите узнать, как организовать разработку ММО от идеи до релиза?
Задумывались ли вы о технических трудностях создания онлайн-игр?

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

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

Начнем мы, пожалуй, с самого интересного – со стоимости разработки.

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

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

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

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

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

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

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

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

Таблица 1.

Роль	Затраты, человеко-месяцев
Директор, менеджер, архитектор, программист сервера, клиента и админки	26
Программист клиента	12
Арт-директор, концепт-художник, 2D художник	16
3Д-моделер, текстуровщик	16
Гейм-дизайнер	16
Тестер-1 (на полставки)	1,5
Тестер-2 (на полставки)	1,5

Выводы

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

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

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

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

Основной клиент
«Пробирка» для 3Dшников.
Основной сервер
БД
Админка (частично: создание предметов, локаций, ботов)
Авто-скрипты
Чат-сервер
Админка (все остальное)
Драйверы для платежной системы
Драйверы для поставщиков трафика
Веб-сайт
Рег.

сервер и рег. клиент
Драйверы социальных сетей (авторизация).

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

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

Этап 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%.

Заключение

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

Мой опыт создания ММО с открытым миром — Инди на DTF

https://www.instagram.com/pol_mousquetaire/

5459 просмотров

Приветствую DTF. Я расскажу немного о своей игре.

Я разрабатываю ММО в жанре privateer на HTML5, на разработку уже ушло 2+ года, как таковой команды у меня не было работал с фрилансерами, бюджет у игры моя месячная зарплата, а разработкой занимался в свободное от работы время и вот что из этого вышло.

Попробовать в нее поиграть можно вот тут http://veliri.ru:8080/, (если на сервер зайдет много людей то он не вытянет и скорее всего будет дико тормозить, возможны ошибки, так что если что простите :С). Регистрация обязательна в поле мейл и пароль можно вбить 123.

На текущий момент игра выглядит вот так

Об игре

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

По геймплею игра классический privateer (я только недавно узнал что такой жанр существует и что я его делаю).

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

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

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

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

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

О том, как родилась идея.

Это самый сложный раздел потому что реально 99% времени я тупо писал/читал код и надоедал в чатах своим друзьям. Тут нет никаких технических подробностей, а просто о том как я докатился до этого)

Идея сделать игру возникла немного не из-за любви к играм и желание их разрабатывать ¯\_(ツ)_/¯. Пару лет назад я работал сис.админом в небольшой компании и сидел рядом с серьезными дядьками которые писали компьютерные программы. В какой-то момент я подумал что тоже умею писать код, но опыта не было. Я подумал что нужен какой-то пет проект для прокачки скилов. Игра мне показалось довольно комплексной задачей которая отлично для этого подойдет.

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

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

Видя на работе мои мучения один программист мне посоветовал посмотреть в сторону go. И вот на нем я смог за очень малый промежуток времени (я хз сколько, но мало), реализовать все то, что пытался 2 месяца сделать на java и это в целом определило вектор разработки.

Спустя +-пол года я родил вот это. И это мне казалось прекрасным, тут даже туман войны есть! Примерно тут я впервые познакомился с JS/CSS/HTML)

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

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

Меня немного затянула разработка и ещё много времени я ковырял этот прототип, но в целом на все это ушло +- год.

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

Идея проекта примерна такая: сделать реалтайм ртс, открытый мир и все такое. Отказался от изометрии т.к. мне она показалось крайне сложной, начал использовать игровой движок Phaser2 CE.

План вырисовывался такой:

Открытый мир поделенный на сектора, перемещение между секторами по системе телепортов как в EVE
На планете идет война 3х фракций
Игрок является независимым отрядом из “Мазертрака” и 6ти юнитов которые тусят в трюме. Так же у него есть трюм для сбора всякого хлама и перевозок.
На карте есть базы которые являются островками безопасности, торговли, производства.
Юниты делятся на боевых, добывающих, саппорты.
Игроки могут строить фортификации в виде турелей, силовых щитов, радаров и тд.
Игроки участвую в боях, захватыват территорий, добывают ресурсы, крафтят всякое, выполняют задания, ищут аномалии…

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

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

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

Спустя 2 месяца ничегонеделания мой мозг перезагрузился и продолжил делать игру ¯\_(ツ)_/¯. На этот раз начал разработку не с написания кода, а наметил план, выделил важные пункты и двигался по нему почти не отклоняясь от курса. И это не диздок. Диздок я писал с самого начала, а на этом моменте на него как раз забил и руководствовался только kabana из github’a.

До какого то времени я писал код в опенсорс, и покоится он там по сей день. Код который там лежит… на самом деле за него стыдно и он ужасный).

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

В итоге нафиг выпилил из игры отряд, переделал управление главной машиной отряда на WASD, а управление оружием и снаряжение в мышку. Удалил или адаптировал чисто под ии почти весь код который являлся составляющей ртс. И вот ртс игра уже совсем не ртс).

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

Из всей этой истории можно выделить некоторые ошибки которые я делал:

Ну я нехера не умел когда взялся чето делать) (это мой первый проект, вообще в программировании)
Я не использовал готовые решения и по-сути частично написал свой движок когда [пункт 1]
Я часто менял вектор разработки что привело к частому переписывания кода. (За все время я сменил 3 жанра игры)
Я не планировал заранее (часто я придумывал что то тупо на ходу и сразу это делал)
Я не коммуницировал с gamedev сообществом

Но в целом цель была научится программировать и эта цель достигнута)

Техническая реализация

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

Стек технологий который используется в игре:

бекенд: go/postgreSQL тут происходят все вычисления, принятия решений и сохранение данных, все алгоритмы (поиск пути, обзор, обнаружение коллизий, ии, полеты пуль и тд.) имеют мою имплементацию найденных решений в интернете 🙂
фронтенд: Vue/webpack/Phaser3: это все что видит игрок

Архитектура приложение вкратце выглядит так:

5 модулей для api фронтенда связанные общим объектом “игрок”: магазин, инвентарь, база, игровая карта, “остальное”(чат, нотификации, диалоги и другие оч маленькие модули).
Независимый модуль выделен под работы ИИ игры, он в свою очередь делится на подмодули (строения, боты, транспорты, игра жизнь, облачка, базы, “слушатели” (некие точки на карте которые что то делают когда на них попадает игрок, например телепортирует на базу)).
Модуль заданий, проверяет выполнения условий задач в заданиях взятыми игроками.

Все это работает параллельно благодаря многопоточности go. Весь этот многопоточный ад синхронизируется за счет того что объект игрока создается 1 раз (как и все игровые объекты), кешируется в хранилище и пуляет его везде по ссылке + мьютексы, каналы и другие нюансы. Это работает довольно быстро, но в противовес этому мои реализации алгоритмов работают очень медленно. ¯\_(ツ)_/¯

Управление

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

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

Ну с движение понятно, нажато W — машина движется вперед, A — поворачивает налево. Со стрельбой немного интересней, если в рукаве игрока выбрано оружие то оно всегда пытается быть повернуто в сторону курсора, но может не успевать или врезаться в препятствие на пути (в игре есть высоты), поэтому на клиенте есть “серверный прицел” который показывает куда приземлится пуля если игрок решить стрельнуть. Ну и если игрок нажимает мышку то происходит выстрел.

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

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

Радар и обзор:

Обзор в игре поделен на 4 уровня.

Прямая видимость: ну тут все понятно это то что видит игрок вокруг себя в мельчайших подробностях
Радар: радар показывает метки на тумане войны объектов которые испускают сигналы и типы этих сигналов (воздушное, неземное, строение, метеориты, ресурсы), радар можно глушить в определенной области с помощью некоторых строений или эквипа, тот кто играл в supcom тому должно быть знакомо 🙂
Память: если игрок видит какое то строение/куст то он его запомнил и будет видеть всегда, но он не будет видеть изменений если он повредился или умер например. Информация об объекте обновляется когда зона где он находится будет открыта снова.
Статичная карта: ну это объекты являются статичными на карте, горы или базы, видны всегда и не изменяются.

У своих сооружений тоже есть своя зона видимости а еще можно построить отдельно радар.

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

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

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

Задания:

Я закончил разрабатывать модуль заданий и хочу о нем тоже поведать т.к. он работает :D. Еще оч.давно я сделал схему структур и примерную архитектуру того как это должно работать. Вот она:

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

Что сейчас

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

Если кому то удастся поиграть отпишите как вышло)

Как сделать 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-моделей, ни текстур, ни звуков, ни сюжета, ни навыков. Есть еще юристы, которым нужно платить, чтобы не подать в суд через неделю после релиза, и есть еще центр обработки данных, который должен работать 24/7, чтобы поддерживать тысячи игроков каждый день. Есть администраторы, которым нужно платить за то, чтобы они следили за серверами. Есть секретари, которым нужно платить за скучную бумажную работу.

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

Использование того, что уже есть

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

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

Игровые движки великолепны, как раз то, что нам нужно!

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

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

Хакеры

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

Если вы все еще не боитесь, то обязательно загляните в uMMORPG!

Создайте MMORPG Web3 с Unity за 10 минут — Moralis Web3

Массовые многопользовательские ролевые онлайн-игры (MMORPG), такие как World of Warcraft и RuneScape, чрезвычайно популярны среди разных возрастных групп. Более того, поскольку Web3 и игры на блокчейне становятся все более популярными, нам нужно поговорить о развитии MMORPG Web3. Как вы, возможно, знаете, массовое внедрение Web3 ожидается в ближайшие пять лет или около того. Таким образом, сейчас самое подходящее время научиться создавать MMORPG-игру на блокчейне с помощью Unity. Конечно, некоторые крупные игроки уже присоединяются к сфере Web3 MMORPG. Однако смелых разработчиков, стремящихся создать MMORPG Web3, ждет множество возможностей.

Как вы узнаете из этой статьи, в вашем распоряжении феноменальные инструменты, которые могут дать вам дополнительное преимущество, когда вы хотите быстро создать MMORPG Web3 с Unity. Помимо Unity, мы покажем вам, как использовать движок Photon и Moralis. Первый упрощает многопользовательский режим, а второй покрывает все потребности вашего бэкенда Web3.

Стремясь вдохновить и обучить вас, мы создали простую MMORPG Web3. По мере продвижения вперед у вас будет возможность увидеть предварительный просмотр этой игры с блокчейном. Кроме того, используя наш код, доступный на GitHub, у вас будет возможность самостоятельно создать MMORPG-игру с блокчейном на Unity всего за десять минут. Таким образом, вы узнаете, как объединить Unity с мощью движка Photon и Moralis. Последнее позволит вам использовать эти незаменимые инструменты для уверенной работы над вашими собственными проектами Web3 MMORPG.

Независимо от того, хотите ли вы создавать dApps (децентрализованные приложения) или токены, Moralis (он же «Firebase для криптографии») поддержит вас. Скорость, надежность, совершенный API Web3, включая NFT API Moralis, и межсетевое взаимодействие делают Moralis лучшей серверной платформой Web3.

Создание MMORPG Web3 с Unity, Moralis и Photon

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

Демо-пример нашей MMORPG Web3

Давайте сначала посмотрим на экран входа в систему:

Глядя на скриншот выше, вы можете видеть, что наш пример игры Web3 сначала требует, чтобы пользователи возможно, мы решили использовать QR-код. Таким образом, пользователи могут просто сканировать этот код с помощью своих устройств и выполнять аутентификацию Web3 с помощью своих кошельков Web3. В этом аспекте Moralis предлагает вам несколько вариантов. Возможность аутентификации с помощью MetaMask — лучшая альтернатива для веб-пользователей с некоторым опытом работы с криптографией. С другой стороны, WalletConnect лучше всего подходит для входа в Web3 на мобильных устройствах. Однако, если вы хотите повысить адаптацию пользователей Web3, возможно, стоит придерживаться методов Web2. К счастью, Moralis позволяет вам легко выполнять аутентификацию Web3 по электронной почте или использовать вход через социальную сеть Web3.

Как только новые пользователи сканируют QR-код и подписывают подтверждающее сообщение с помощью своих горячих кошельков, они входят в систему. Затем у них есть возможность присоединиться к игре, нажав кнопку «ПРИСОЕДИНИТЬСЯ В КОМНАТЕ»:

Кроме того, сообщение появится в нижней части экрана после успешного входа в систему. Это позволяет пользователям узнать, что их адрес кошелька зарегистрирован. После нажатия кнопки «ПРИСОЕДИНИТЬСЯ В КОМНАТЕ» игра загружает сцену:

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

При обращении к другим игрокам пользователи могут проверить свои имена пользователей и адреса кошельков:

Создание MMORPG-игры с блокчейном с помощью Unity — обзор инструментов

Теперь, когда у вас есть четкое представление о том, что мы собираемся создать, давайте рассмотрим его поближе. посмотрите на инструменты, которые мы будем использовать. Как упоминалось ранее, мы будем использовать Unity, Moralis и движок Photon.

Unity — кроссплатформенный игровой движок. На наш взгляд, это наиболее полное решение для создания игр. Кроме того, здорово иметь возможность использовать инструменты Web2, с которыми мы знакомы для разработки Web3.

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

Moralis — совершенная платформа для разработки Web3. При рассмотрении текущего стека технологий Web3 Moralis — это инструмент, который следует использовать. Кроме всего прочего, это позволяет вам сэкономить 87% времени разработки. Таким образом, Moralis делает развертывание dApps в нескольких программируемых цепочках невероятно простым. Кроме того, Moralis позволяет избежать всех ограничений узлов RPC. Таким образом, вы сможете уделить максимум внимания интерфейсу. Следовательно, вы можете предложить своим клиентам отличный пользовательский интерфейс Web3.

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

Создайте MMORPG-игру с блокчейном на Unity за 10 минут

Как упоминалось выше, мы сделали весь код для MMORPG Web3, представленный ранее, доступным на GitHub. Таким образом, вы можете начать с клонирования кода или загрузки ZIP-файла проекта:

После загрузки ZIP-файла разархивируйте его, а затем откройте основную папку с помощью Unity. Затем внутри Unity найдите сцену «Вход»:

Когда дело доходит до инструментов входа на стороне пользователей, мы рекомендуем использовать Trust Wallet. Исходя из нашего опыта, это один из самых надежных доступных. К счастью, SDK Moralis делает реализацию входа в систему довольно простой. Он предоставляет нам два «префаба»:

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

Первоначальная настройка Moralis

Независимо от того, создаете ли вы MMORPG Web3 с Unity или создаете децентрализованные приложения с использованием окончательного шаблона Ethereum dApp, вы должны сначала выполнить начальную настройку Moralis. Целью этой настройки является создание вашего сервера Moralis и доступ к его данным. Таким образом, выполните следующие действия.

Доступ к вашей административной области Moralis и создание сервера Moralis

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

Создайте сервер Moralis . После входа в административную область Moralis нажмите кнопку «+ Создать новый сервер», расположенную в правом верхнем углу на вкладке «Серверы». Руководство на странице также поможет вам:

После того, как вы нажмете кнопку «Создать новый сервер», вам нужно будет выбрать тип сети, который лучше всего подходит для вашего проекта (см. снимок экрана ниже). При работе с примерами проектов или при тестировании dApp лучше всего использовать «Testnet Server» или «Local Devchain Server». Однако, когда придет время запуска, вам нужно будет нажать «Mainnet Server».

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

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

Заполнить Unity – Имея в своем распоряжении данные вашего сервера Moralis, пришло время заполнить соответствующие поля внутри Unity. Таким образом, не забудьте вставить каждую из двух деталей в правильное поле:

Теперь, когда ваш сервер запущен, вы также можете получить доступ к панели инструментов Moralis. Это можно сделать, нажав на стрелку рядом с кнопкой «Подробнее». Затем нажмите «Панель инструментов», чтобы получить доступ к вашей базе данных. Там записываются все соответствующие события в сети:

Вот предварительный просмотр панели инструментов Moralis:

Внутри класса «Пользователь» вы сможете просматривать логины пользователей. Кроме того, внутри «_EthAddress» вы увидите адреса кошельков, используемые для входа в систему. Таким образом, все эти данные в цепочке находятся в вашем распоряжении. Следовательно, вы можете легко прочитать его и использовать для правильного программирования вашей MMORPG Web3. Последнее аккуратно делается с помощью методов MoralisInterface. Вы можете просмотреть подробную информацию о внутренних функциях, открыв «AppManager» из сцены рядом с «Script» внутри Unity:

Затем вы можете использовать строку поиска и ввести «MoralisInterface». При этом будут отмечены все соответствующие методы:

Настройка многопользовательской игры Web3

Когда Moralis позаботится о вашем бэкэнде, ваша MMORPG-игра Web3 уже запущена. Тем не менее, вам все еще нужно включить многопользовательские функции. В этой части нашего квеста «Создание MMORPG-игры с блокчейном с помощью Unity» мы будем использовать Photon.

Для начала перейдите на сцену «Игра» внутри Unity ( активы > проект > сцены ):

Глядя на иерархию сцены «Игра», можно увидеть, что префабы Photon отсутствуют. Однако наш «GameManager» выбирает игроков случайным образом:

Таким образом, наши префабы «PhotonPlayer» включены в каждый «PhotonPlayer»:

сборные. К ним относятся «Photon View», «Photon Transfer View» и «Photon Animator View». Однако, чтобы все это работало, вам нужно вставить свой идентификатор приложения Photon в «Настройки сервера Photon». Чтобы получить доступ к этим настройкам, используйте инструмент поиска и введите «Настройки». Далее открываем «PhotonSer…»:

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

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

Затем обязательно выберите «PUN» в разделе «Тип Photon»:

Остальные детали могут быть какими угодно. Затем нажмите на кнопку «Создать». Наконец, скопируйте идентификатор своего приложения и вставьте его в Unity:

На этом наш квест «Создание MMORPG-игры с блокчейном с помощью Unity» завершен!

Вот также видеоверсия приведенного выше руководства:

Создайте MMORPG Web3 с Unity за 10 минут — Резюме

Мы надеемся что вы следовали приведенному выше руководству и предприняли необходимые шаги для создания MMORPG-игры с блокчейном с помощью Unity. Если это так, вы узнали, как легко выполнить первоначальную настройку Moralis и настройку Photon, чтобы получить надлежащую функциональность. Более того, хотя наш пример игры Web3 MMORPG довольно крут, мы призываем вас использовать свои навыки и воображение, чтобы выйти на новый уровень. Однако, если вам сначала нужно повысить свою уверенность, мы рекомендуем пройти обучение по развитию блокчейна.

Если вы предпочитаете бесплатный контент, нет ничего лучше, чем канал Moralis на YouTube и блог Moralis.