С 2021 года я начал делать свою MMO игру обнаружив что нет готовых сервисов ни в России, ни за рубежом. Но сделать игру я мечтал со времен «Бойцовского клуба» и текстового «Амулета дракона», вдобавок уже был неплохим программистом.
Так и родилась идея написать свое решение Авторитарного сервера для 2D Mmo RPG игр и, как говорил Илон Маск: «Батут работает».
Есть сервисы-аналоги, но для ММО они либо не подходили либо требовали существенных доработок и непонятно как их теперь из РФ оплачивать (они для сессионных игр, их исчерпывающий список ниже).
Сервер нужен был авторитарный (P2P соединения или с проверками на клиенте для жанра MMO был не вариант), для тех кто не знает что это такое пример сравнения серверов ниже.
Это добавляло с одной стороны сложность (нужны были инструменты для изменения/добавления кода на сервере), так появился инструмент редактирования кода игровых механик — Web IDE.
Конечно, нужны были инструменты для настройки характеристик, игрового баланса, предметов и прочего (гейм дизайнер не полезет учить PHP и JS — максимум цифры поправит), и так я сделал редактор существ.
Нужно было что бы сервер имел представление о мире, его препятствиях для расчета пути NPC (игровых существ под управлением ИИ) и проверки проходимости области, так родилось приложение для загрузки 2D игровых карт.
И только в самом конце нужно было позаботиться что бы сервер мог обслуживать и рассылать данные сотням и тысячам игроков, придумать систему оркестрации, горизонтального масштабирования и бесконечного бесшовного 2D мира. Так спустя 3 года разработки вишенкой на торте стала сервисная архитектура, где одни из сервисов выступал работающий в параллели WebSocket сервер.
Моя разработка в серии статей встретила критику со стороны читателей в вопросе производительности. Требовались инструменты замера скорости работы. Сложность была в том, что т.к. сервер авторитарный таких метрик как PING было не достаточно — сервер тратил время не только на отправку и получение пакетов игроков, но и на вычисления команд игроков, расчета, что делает NPC, периодического сохранение в БД (последнее было вынесено в отдельный сервис).
Я написал приложение, что замеряло все: время отправки / сжатия пакетов, отдельных механик, обмена данными между сервисами — все с точностью до тысячной миллисекунды, а так же использование CPU и RAM.
Если не вдаваться в детали то на VPS за 10$ (Ubuntu, 2 CPU, 2Gb RAM) могут одновременно играть +-300 игроков, формулы расчета есть на моем сайте.
И таких серверов может бесконечно и это останется единый бесшовный мир, где игроки со всего мира будут играть вместе (я лично проехал от юго-восточной Африки до Индии при PING 150-250 добавляя интерполяцию и экстраполяцию).
Демонстрационная игра пока простенькая, не замысловатая, без сюжета и музыки, мало механик, но игровой сервер одинаково хорошо работает как для браузерных игр, так и для версии на ПК, мобильных устройствах (код я выложил на GitHub). С готовой архитектурой сервера я не вижу того, что потребовало бы выход за рамки Web IDE.
Конечно, есть и 3D игры и кому, то хочется нестандартных режимов, новых жанров (типа стратегий или баталий). Для этого я сделал возможность не только редактировать отдельные механик (выстрел, движение к цели, дебафы, крафт, прокачка и т.д), но и самим, из личного кабинет на WEB, не погружаясь в иерархию всего проекта, приложений, сетевого взаимодействия редактировать тот код, который отвечает только за игровое взаимодействие — я назвал это Игровые Фреймворки (пока доступен только для RPG игр, в планах матчмейкинг и стратегии).
Как видите игровой сервер не просто шлет пакеты и ошибочно полагать что любой с ходу может сделать онлайн игру более чем на 20 человек (такое ограничение у западных аналогов).
За 3 года разработки был проделан колоссальный труд и получилось что-то типа Тильды / Битрикса, но для онлайн игры.
Я стою перед выбором: сконцентрироваться над B2B продуктом предоставляя новые инструменты разработчикам или делать свою игру, и я спрашиваю вас:
Нужен ли Вам — разработчикам игр подобный сервис?
Ваша обратная связь в опросе ниже и в комментариях будет ценна для меня. Я так же рассматриваю партнерство сделать MMO игру в команде.
В моих планах сделать сервис для 3D игр, добавление без программирования в игру музыки, анимацию героев, список друзей, новые игры
История:
Выбор технологий, протокола и архитектурный шаблон Entity Component System
FPS, Ping, паузы между командами, интерполяция и экстраполяция
Event-driven паттерн, JSON-RPC и почему не сервисная (SOA) архитектура
Сетевая карта и задержка кадра (Latency frame) по RFC 2544 (1242)
Готовое MVP сервиса 2D MMO RPG игр (realtime)
Комментарии (48)
MANAB
15.05.2024 14:11К вашим вычислениям FPS на сайте вопросы.
Почему вы включаете туда время на отправку данных игрокам, если это вообще параллельный процесс и на FPS никак влиять не должен? По идее во время обработки включается только обработка пришедших команд от пользователей, обсчет их действий и изменения мира и упаковка результатов для отправки?
-
В расчетах указано про 50 созданий и время обсчета, но ведь у всех игр логика взаимодействия с миром и друг другом разной степени тяжести. Более того, привзаимодейиствии игроков в области каждый с каждым количество взаимодействий для обсчета растет экспоненциально, поэтому говорить, что раз 50 созданий обсчитывается за 30% CPU, то на 2х ядрах получим 350 комфортно играющих игроков совсем некорректно.
Не знаю, почему у меня статья вызывает много злости и агрессии. Наверное сам был когда то таким же. Приминительно к моим замечанием выше хотелось бы увидеть более применительные цифры к вашему движку, типа: 50, 100, 400 игроков взаимодействуют только с миром (набор встроенеых в движок действий/механик) - загрузка CPU и тоже самое, но взаимодействуют все друг с другом в одном месте, аля массовое побоище.
webrobot Автор
15.05.2024 14:11Вопрос 1: Максимально возможный FPS в данном случае скорость работы сервера. Я считаю более честным считать конец кадра моментом когда последнему игроку будет отправлен пакет с очередного кадра.
Жизненный цикл кадра
WebSocket принял пакеты от N игроков, настало время отправить в сервер физики их
WebSocket отправляет в сервер физики это занимает 1/2 от Overhead на обмен пакетов Websocket <-> сервер физики (константное значение)
WebSocket может пока ждет от сервера физики ответа принимать новые команды
WebSocket получает ответ от сервера физики (будто и вот он FPS) в который включен вторая часть 1/2 Overhead на обмен пакетов Websocket <-> сервер физики
WebSocket рассылает игрокам данные (0.05 это не совсем время отправки пакетов это overhead вызова неблокируемой функции отправки)
Когда на сетевое устройство переданы все пакеты я считаю это завершение кадра - все вышеперечисленное это единая функция которая вызывается по таймеру (в зависимости от того какой FPS настроен в настройках игры, он меньше возможного. Обычно значение установлено в 30 FPS, т.е. каждые 0.33 мс)
Вы считаете не стоит учитывать 0.05 мс overhead на отправку каждому игроку ?
MANAB
15.05.2024 14:11Теперь когда вы объяснили, что это оверхед на передачу между сервером физики и сервером отправки - я согласен. Но исходя из описания на сайте сложилось ощущение, что вы включаете время отправки сообщений игрокам из-за того, что указывали размер пакета и скорость соединения на обоих концах и расположение сервера и игроков. Поэтому я и стал задавать вопрос.
Когда на сетевое устройство переданы все пакеты я считаю это завершение кадра
Опять же, выглядит, что ваш websocket server отделен логически от сервера физики, значит концом кадра является передача от сервера физики на сервер вебсокета, а не на сетевое устройство. Т.к. у сервера websocket там может быть еще логика по компрессии данных например, а сервер физики уже мог бы начать новый кадр считать, компрессия данных не его задача.
webrobot Автор
15.05.2024 14:11а как вы считаете кратко перефразировать какой блок что было понять ?)
Все не идеально написано, согласенЛогика по компрессии данных действительно есть
webrobot Автор
15.05.2024 14:11Вопрос 2: да , механики разные. Но сейчас такие показатели (мобы ходят, ищут других, стреляют постоянно, ищут короткий путь до целей, регенерируют, воскрешаются).
Я и не скрываю данный факт , и на сайте приписку об этом сделал.
Можно например поиск пути что бы не все возможные пути искал, а лишь если не встретил хуже того что уже нашел и будет еще быстрее (не все механики прям отточены, но изменить одну просто - код каждый отдельно каждая хранится и замеряются, считайте что на каждую механику свой фаил).
Можно анализировать каждую механику конкретно, пример на фото ниже и в админ панели по ссылке Производительность (можно по демо доступам зайти)
Вот код который их замеряет (часть кода моего сервиса открыто) https://github.com/webrobot1/framework-rpg2d/blob/master/Frame.php#L127
Экспонент там нет. Все существа обрабатываются по очереди и в каждом существе обрабатываются все механики если им пришло врем выполняться в этом кадре (код чуть выше того ссылку на который я дал). Например регенерации обрабатывается раз в 10 секунд (эти параметры уже не в Git записаны а редактируются на каждую игру в админ панели)
MANAB
15.05.2024 14:11Еще раз уточню - во время драки если рядом много противников, кого мы можем задеть и если рядом никого или 1 противник - это разные сложности обсчета. Я и говорю про случай, сколько выдержит сервер при худшем варианте, когда все собрались в одном месте и бьются и много коллизий каждый с каждым. Когда каждый где то отдельно гасит 1го моба - понятно из расчетов.
webrobot Автор
15.05.2024 14:11У меня пока нет механик массовых коллизий (типа взрыва который задевает в радиусе кого то), но я заранее могу сказать что сильно не изменится ничего (шутеры и гонки - согласен на моем продукте не сделать, но там и не нужна авторитарность)
Точных метрик на все случаи жизни не сделать (да и не каждый игрок будет постоянно стрелять). Я привел метрики в худшем варианте текущих механикСистема горизонтально масштабируется и обработку части NPC и игроков можно поручить отдельной физической машине (при этом все продолжат играть в едином мире)
,
webrobot Автор
15.05.2024 14:11для этого я сделал SAAS версию где каждый может взять мою демку игры на Unity и написать свои механики в личном кабинете (там бесплатный режим есть).
Это ведь не шаблоны - можно как угодно код менять (только в БД напрямую слать запросы нельзя и сетевые ресурсы не доступны)
azTotMD
15.05.2024 14:11Еще раз уточню - во время драки если рядом много противников, кого мы можем задеть и если рядом никого или 1 противник - это разные сложности обсчета.
Зависит от архитектуры программы, можно сделать примерно константно, особенно на дискретных сетках
webrobot Автор
15.05.2024 14:11Про злость и агрессию - мой наставник говорит что такое в РФ постоянно ко всему новому. А на западе не так - там с интересом относятся ко всему новому (сам не проверял не знаю).
Если это так то полагаю что в РФ люди привыкли что все новое делают что бы нажиться, а не для людей. И делают плохо (может поэтому и мало кто что делает в РФ. Страна большая а доля игрового рынка 1.8% по официальной статистике)
Тем не менее я делаю и игру свою и продолжу делать. Если по итогу окажется что как B2B решение в РФ оно не нужно - сделаю на запад или переключусь делать игру. Сейчас у всех NPC массовое побоище (по умолчанию они активны когда игрок рядом, я настроил в админке что и без игроков они друг друга бьют и стреляют)
Я буду честен с вами - я не думаю что будет результат хуже того FPS чем я указал (NPC выстрелит милилсекунда в миллисекунду когда пройдет дебаф на заклятие. Тоже и на другие механики. Игрок живой не так активен будет и не постоянно в режиме побоища)MANAB
15.05.2024 14:11Про злость и агрессию - мой наставник говорит что такое в РФ постоянно ко всему новому.
Ну, сама статья у меня вызвала такие эмоции.
В коментариях пообщался, и эмоции в другую сторону поменялись - на уважение к проделанной работе.
azTotMD
15.05.2024 14:11могут одновременно играть +-300 игроков, формулы расчета есть на моем сайте.
И таких серверов может бесконечно и это останется единый бесшовный мир, где игроки со всего мира будут играть вместе
А как это реализуется, что игроки играющие на разных серверах играют вместе?
webrobot Автор
15.05.2024 14:11Сервера программы (назовем их комнатами-локациями) друг с другом соединяются по tcp (как игроки с сервером - тот же принцип) и обмениваются данными (не важно на одной машине они или нет)
На каждой машине по несколько запущенных комнат небольшой локации (как часть единой карты, что бы по максимум cpu использовать)
Стоя на границе локации не важно что дальше (другая машина или локация на этой же) - игрок видит что там происходит (если дизайн подходящий то и не заметны границы)
Для примера фаербол может лететь через разные машины по локациям, как и npc и игроки ходить
azTotMD
15.05.2024 14:11ну получается клиент получает пакеты с нескольких серверов, если игрок стоит на стыке? Или есть какой-то главный сервер, который собирает со всех нужных и отсылает клиенту?
webrobot Автор
15.05.2024 14:11Если быть точнее: смежные сервер-локации сами передают данные друг другу, после чего рассылают "своим" игрокам
Так что тот сервер на котором сейчас стоит игрок при получении с соседнего каких то обновлений разошлет игроку что на смежном сервере происходит
Какие локации смежные - я в админ панели на сетке размещаю.
Например здание магазина в игре скорее всего не смежная ни с какой локация - перед его входом на клетке можно разместить телепорт - таким образом игрок попадает на НЕ смежные локации
azTotMD
15.05.2024 14:11Если быть точнее: смежные сервер-локации сами передают данные друг другу, после чего рассылают "своим" игрокам
спасибо, принцип понял
webrobot Автор
15.05.2024 14:11Но и сервер другому серверу может не только пакеты исполненные в нем передавать, а так за запрос выполнить что то у себя.
Пример - на границе карт применена магия взрыва что затрагивает в радиусе 10 клеток существ (в механики будет поиск существ в радиусе и не важно на каком они сервере отправлена команда - Повесить событие получение урона в 10 жизней)
webrobot Автор
15.05.2024 14:11игровые карты я выкладываю на GitHub постепенно (там есть превью как они выглядят - можно из них собрать свой игровой мир)
Хотите помогу в ваш клиент сделать плагин к сервису ? Или на пару сделать на Unity игру (он может и громоздкий, но его много кто знает, включая меня - почитал тут вашу статью)
azTotMD
15.05.2024 14:11Хотите помогу в ваш клиент сделать плагин к сервису ?
не понял, это как и зачем?
на пару сделать на Unity игру
я не работал с юнити
webrobot Автор
15.05.2024 14:11я вижу вы делаете игру. Я могу к вашему клиенту игры соединить свое ПО (выдам вам бесплатный доступ, потом захотите договоримся и на Ваш сервер поставим - будите в админ панели механики скриптами описывать, а клиент будет визуализировать у себя на основе пакетов приходящих изменения). так быстрее MMO сделаете )
там и карты игровые можете слать в свой клиент (я их делаю в программе Tiled - оф сайт может без vpn не открыться https://www.mapeditor.org/)
azTotMD
15.05.2024 14:11к вашему клиенту игры соединить свое ПО
каким образом?
механики скриптами описывать
я не очень понимаю, как из вашей админ панели скрипты с механиками проникнут в мой работающий бинарник, можете пояснить?
а клиент будет визуализировать у себя на основе пакетов приходящих изменения
у меня так и сделано. Только не изменения (потому что тогда надо где-то запоминать, что изменилось, а что нет), а просто то, что видит игрок. Поэтому у меня нативным образом игра бесшовная и скорость исполнения не зависит от числа игроков рядом.
так быстрее MMO сделаете
дак у меня уже сделано. Вопрос в том, как накидать побольше контента, но это больше упирается в рисование. И сейчас думаю о новом типе искусственного интеллекта.
ПС: только не надо больше скриншотов, пожалуйста
webrobot Автор
15.05.2024 14:11каким образом?
Главный вопрос - интересно ли Вам.
Сервер работает с клиентом по API (игрок оправляет команды - сервер возвращается что меняется, тут я постарался описать как это работает)как проникнут в мой работающий бинарник, можете пояснить
возьмем механику выстрела - вы отправляете команду в сервер Стрелять, сервер возвращает json что у вас стало меньше маны и что на сцене появился фаерболт (и далее шлет пакеты что меняются его позиции) - в клиенте вы анимируете
azTotMD
15.05.2024 14:11игрок оправляет команды - сервер возвращается что меняется
у меня так и сделано, только сервер не возвращает ответ сразу, а в своем цикле рассылает всем игрокам то, что они видят/слышат. Т.к. окружении игрока может изменится, даже если он ничего не отправлял.
возьмем механику выстрела - вы отправляете команду в сервер Стрелять, сервер возвращает json что у вас стало меньше маны и что на сцене появился фаербол
Вы всё время даёте какое-то внешнее объяснение, но я пытаюсь понять, как это работает внутри. Во-первых, что тут сервер? Мне кажется мы разное под этим понимаем. Для меня сервер - это программа, где крутится игровой цикл и она же обменивается пакетами с внешним миром. У вас, похоже, сервер - это какая-то прослойка между ядром игры и клиентом.
Откуда ваш сервер узнает, сколько у меня стало маны, в какой координате появился фаербол и т.д.? Как оперировать с внутриигровыми переменными из скрипта?
webrobot Автор
15.05.2024 14:11Если вам интересно посмотреть как устроена архитектура - у меня ряд статей , вот одна из них (фото архитектуры там есть) - https://habr.com/ru/articles/780602/
azTotMD
15.05.2024 14:11Там очень поверхностно:
WebSocket сервер - принимает и отправляет пакеты, про игру он не знает ничего
Игровой сервер - загружает из БД данные введенные в админ панели (загруженные карты, данные игроков, npc, анимации) для отправки в сервис WebSocket на отправку игрока и сохраняя изменения и запуская игровой кадр сервиса ниже...
Песочница (сервер Game механик) - это тот процесс в котором выполняется пользовательский код добавленный через админ панель. Здесь происходят расчеты текущего кадра: физики, поиска путей, что какой npc в этом кадре делает (двигается, регенерирует, атакует и т.д.)
Что из этого мы можем понять? Вебсокет сервер перенаправляет пакет в игровой сервер, тот добавляет какую-то свою инфу и отправляет это в "песочницу" там они прогоняются через какие-то скрипты якобы произвольного содержимого, полученный результат обратно в игровой или сразу в вебсокет.
Чтобы всё это работало нужно какое-то соглашение о форматах, данных и прочем.
И поэтому мне непонятно, что вы предлагаете? Мой сервер не поймёт содержимого ваших пакетов, ваших карт, нпс и уж тем более ему не нужны анимации. Переписать его для совместимости или вообще заново сделать?
webrobot Автор
15.05.2024 14:11Я предлагал вам бесплатно сделать серверную часть на своем ПО.
Считаю что при особом интересе разобраться можно во всем, но несмотря на то что вы задаете вопросы интереса сильного не чувствуется. Давайте забудем о моем предложении
EGarrus
Если вы обращаетесь к серверным программистам, то тут не подскажу. Но как геймдизайнер могу сказать, что
Это не так как минимум.
Не буду касаться темы серверов и прочих пингов, буду только про "игру". Вы создаёте движок для разработки игры? Если да, то текущая реализация, судя по циклу статей, является только одним из модулей? Геймдизайнерам не нужны поля для настройки персонажей - выставить пауку урон 10 вместо 5 можно и в экселе. Блок с компонентами лепится программистом за несколько минут, код для компонента или параметра пишется одинаково долго и для юнити и для вашего движка.
Я хочу сказать, что если вы сосредоточились на игровом движке для ММО, то нужно быть движком. Если же вы создаёте конструктор прототипов или простеньких игр для обучения, то нужно тогда быть больше конструктором или обучающим инструментом.
Демонстрационную игру посмотрел - как геймдизайнер не понял демонстрацию. Может быть разработчик поймет.
webrobot Автор
Я делаю такой продукт, что бы быстро запускать и проверять игры MMO.
Самое сложное что для такого жанра он должен поддерживать огромное количество игроков , а все расчеты должны делаться где то на сервере. С одной стороны кажется что ничего сложного, а с другой...В мире нет сервисов для создания ММО игр (сервисов что бы этот режим поддерживался из коробки)
webrobot Автор
Сейчас это готовый MVP состоящих из модулей. Ниже их краткий перечень
Редактор NPC и игроков (что бы не в эксель, а изменил - и сразу все в игре)
Редактор игровых механик (что бы вообще не завесить от программиста клиента и не обновлять игрокам клиенты, тоже поменял - и сразу все в игре применилось. Например скоро я реализую крафт, инвентарь - в клиенте один раз UI только сделать надо)
Импорт игровых карт - можно менять карты как душе угодно, создавать эвенты на новых локациях - даже не ходя к программисту клиента (при этом сервер будет знать где препятствия что бы NPC знали куда можно куда нельзя ходить)
Редактор ИИ для NPC (описывать скриптами их поведение и все игроки будут видеть что они делают - продукт только для онлайн игр)
EGarrus
Ну вот я про это и говорю.
Для этого в играх делается импортер конфигов или админка. Это разрабатывается вместе с игрой.
Как это? Я ввожу механику погоды, которая влияет на скорость регенерации растений в мире, из-за чего необходимость в растениях у NPC-фермеров снижается и они реже выдают квест на поиск растений — и это будет из коробки? Звучит здорово!
У этого маловато практической пользы. Как обучающая штука пойдет, но как движок для игры — это вообще не туда. Крафт — одна из самых сложных игровых систем. А уж в ММО сделать её интересной — это отдельный челлендж. Я не особо понимаю, как можно "реализовать крафт" универсально. Для этого сначала должен быть дизайн и механика крафта, а потом уже админка для настройки. Если вы реализуете универсальный крафт, то конечно моё почтение, но это где-то на стыке гениального и невозможного.
У геймдизайнеров нет потребности реализовывать однотипные игры по шаблонам. Такая потребность есть у инвесторов. Но даже при создании "клонов" мобильных игр появляется очень много нюансов и там дело совсем не в том, что разработчик не знает, как объявить класс "Предмет" с параметром "Создаваемый" и загрузить в него список требуемых предметов для крафта.
Я хочу сказать, что такую вещь как ММОРПГ очень сложно унифицировать, поэтому админка с сущностями чуть более сложными, чем "отредактировать параметр в строке" вряд ли будет пользоваться спросом.
А чтобы пользовалась — нужно писать движок для игры, а не серверный модуль.
webrobot Автор
- так почему бы не сделать что бы на каждую игру не делать свою админку ? в этом и идея
- да и это понадобиться описать скриптами (обычно скриптами Lua делают , у меня PHP). Из под коробки вы можете добавлять на сервере любой игровой код (разве что напрямую с БД нельзя из под скриптов постучаться). Для этих целей в личном кабинете есть некий WEB редактор кода. В вашем случае я вижу что каждый раз когда попытка взять квест у NPC мы шлем команду проверки наличия квестов у него проверяются других вводные . тоже и регенерация
- на каждую игру можно создавать свои механники и описать ее в виде кода сервера (тк все это будет считать сервер - какие материалы, что выйдет какие шансы. и описать в виде скриптов)
- движок остается unity (или unreal или на чем там пишите). Тут промежуточное программное обеспечение. а именно серверная часть
тут как раз не про шаблоны а то про что встроенный инструмент дает возможность как угодно программировать сервер механики, добавлять свои
webrobot Автор
вот пример редактора кода механик с условным параметров погоды
webrobot Автор
вот как пример механика атака (все можно поменять в коде)
webrobot Автор
и таких механик может быть целая куча. их можно вешать на npc или их могут вызывать игроки по команде. И без разницы какой у вас движок (движком я понимаю Unity или UE).
Просто это сейчас каждый раз движки делать дл сложных задач. а я предлагаю отделить все в серверный модуль
webrobot Автор
для понимания как это работает :
Клиент с Unity игры отправляет команду - создай молоток
Сервер принимает команду смотрит что есть для молотка, если все ок - отнимает ресурсы и добавляет молоток , отправляя на клиент что ресурсов стало меньше и появился в инвентаре молоток
Как видите сам движок тут не играет значение. А вы уже на сервере в модуле добавляете черед UI редактор что у игрока могут быть (как пример, можно вписать что угодно)
железо
камень
древесина
и создаете команду - создай молоток в которой пишите небольшой скрипт где описываете шанс создать предмет и что для этого требуется и что в итоге появиться в инвентаре
сервер передает все что изменилось в кадре, клиент лишь анимирует
EGarrus
Ну вот видите, по итогу уже оказывается, что редактор механик не нужен, нужны правила для их связки между собой, а без разработчика игру сделать редактором механик не выйдет. И ещё проблема тут в том, что у вас пока в примерах простые механики. Как только механика станет чуть сложнее, сразу и скрипты внутри вашей админки станут сложнее. По итогу мне это видится как необходимость разрабатывать игру в двух местах.
Я понял принцип и цель, но для разработки игр это какая-то очень амбициозная машина, учитывая, как сложны бывают игры. А в особенности ММОРПГ.
Пример. Нужна механика уворота. Геймдизайнер её описал, разработчик написал скрипт. И вместо того, чтобы внутри своей привычной среды разработки он потом написал "если %уворот% == true, то income_dmg = 0", он это напишет внутри вашей админки.
Я правильно понимаю, что это плата за то, что серверное взаимодействие уже выстроено вами?
Ну и админку всё равно надо будет переписывать под каждую игру ведь.
Это я просто цепляюсь за:
Не получится это делать быстро, используя только ваш инструмент. К тому же, в каждой игре разные понятия, что должно обрабатываться на сервере, что - на клиенте. Т.е. это всё опять же к тому, что возможно вы сделали хороший модуль в помощь, но универсальным такому модулю стать — очень тяжело.
webrobot Автор
редактор механик - это инструмент где вы вводите код. только это не тот разработчик который будет разбираться как потом пакеты слать, разбираться во всем проекте - это некий набор правил что бы манипулировать игровыми существами
webrobot Автор
скрипты можно уже сейчас добавлять любой сложности (для этого не понадобиться менять редактор или что то на сетевом взаимодействии менять). Грубо говорят уже сейчас можно написать игру не меняя ни одного фаила на сервере
webrobot Автор
своей привычной среды разработки - моя идея разрушить стереотип что разработчик клиентской части должен писать сервер. Разработчику клеента вообще не надо писать скрипты, пусть он делает отображение анимации и визуальную реакцию на пришедшие пакеты. А гейм дизайнер контролит какие скрипты у него в проекте и полностью понимает что откуда идет
webrobot Автор
серверное взаимодействие уже выстроено вами - мной не выстроено серверное взаимодействие. Есть примеры механик и пример фреймворка который для MMO RPG подходит (https://github.com/webrobot1/framework-rpg2d) - таких фреймворком можно добавить сколько угодно , в тч менять текущий (без изменений фаилов на сервере - все через редактор)
webrobot Автор
Ну и админку всё равно надо будет переписывать - зачем переписывать админку. Вот у вас новая игра где появился параметр "Размер инвентаря"
Вы добавляете новый компонент Размер Инвентаря (в классическом сценарии разработки это как колонка в БД, у меня не совсем колонка, но допустим она), указываете у кого может он быть (у игроков например только)
Вы в редакторе какой то механики (это может механика положить предмет в инвентарь) вы описываете что количество ячеек ограничено этим параметром
С получением уровня этот стат увеличивается
Я к тому что нет такого пока параметра или механики что заставит переписать админку или менять на сервере мне фаилы в модуле - все настраивается через тулсеты и редактор (вы кодом можете что угодно описать и такую возможность я даю - это как облачный код от Amazon)
webrobot Автор
каждой игре разные понятия - вы можете привести любой и в итоге выйдет что все можно реализовать в моем инструменте. Это не шаблонные игры, не сборка сервера из типовых настроек. Это UI тулсеты для вещей которые нужны в любой игре (например добавление новых статов-параметров игрокам и существам) и редактор кода (который можно описать ВСЕ что угодно. Просто это делается не где то там в фаилах и экселях, в а специальной web панели)
webrobot Автор
Не получится это делать быстро - разработка MMO это десятки специалистов и миллионные бюджеты и под каждую игру придумать архитектуру сервера, бд и прочее.
Билу Гейству когда он презентовал windows тоже говорили что никому не нужно, и ПК тока для программистов и невозможно будет с мышкой, и папками нормально ничего написать
Потом двинемся немного в будущее , к изобретателю Тильды - ему наверняка говорили что каждый дизайн сайта уникальный и невозможно сделать универсального ничего (думаю в в Тильде даже свой дизайн и тему можно делать)
webrobot Автор
нужны правила для их связки между собой - эти правила уже давно известны для игровых движков , называется Сущностное компонентная архитектура - ее Unity использует (а на ней можно какие угодно игры делать). В моем проекте именно она. И при желании можно и от этого отойти в редакторе описать что то свое.
webrobot Автор
Я настолько уверен что этот инструмент работает и что игру можно сделать в тч уровня одной из ныне популярных Warspear Online , что готов бесплатно предоставить ПО и участвовать в разработке сейчас за % от монетизации в будущем (с оговоркой что моя часть только сервер и я должен быть уверен в серьезности что и партнер готов будет довести до конца)
webrobot Автор
Но модули будут и новые , например я хочу сделать по аналогии с загрузкой карты загрузку анимации существ , предметов, добавление музыки и звуковых эффектов в WEB кабинет.
Таким образом можно добавлять предметы как и карты по щелчку мышки , а игровые клиенты будут подтягивать обновления и сразу видеть их.
Благодаря реактору NPC можно легко добавить из кого будет и эта вся информация будет не в экселях а в БД (каждый с доступом в любой момент может посмотреть и поменять когда надо)
Скажем так - я создаю не какой то аналог чего то и пытаюсь убедить что это лучше. Я создаю пока первый в мире готовый сервис для MMO (альтернатива это писать под каждую игру свою сервер, что сейчас и происходит) и набором тулсетов