Комментарии 48
Нужен ли Вам - разработчикам игр подобный сервис ?
Если вы обращаетесь к серверным программистам, то тут не подскажу. Но как геймдизайнер могу сказать, что
(гейм дизайнер не полезет учить PHP и JS - максимум цифры поправит)
Это не так как минимум.
Не буду касаться темы серверов и прочих пингов, буду только про "игру". Вы создаёте движок для разработки игры? Если да, то текущая реализация, судя по циклу статей, является только одним из модулей? Геймдизайнерам не нужны поля для настройки персонажей - выставить пауку урон 10 вместо 5 можно и в экселе. Блок с компонентами лепится программистом за несколько минут, код для компонента или параметра пишется одинаково долго и для юнити и для вашего движка.
Я хочу сказать, что если вы сосредоточились на игровом движке для ММО, то нужно быть движком. Если же вы создаёте конструктор прототипов или простеньких игр для обучения, то нужно тогда быть больше конструктором или обучающим инструментом.
Демонстрационную игру посмотрел - как геймдизайнер не понял демонстрацию. Может быть разработчик поймет.
Я делаю такой продукт, что бы быстро запускать и проверять игры MMO.
Самое сложное что для такого жанра он должен поддерживать огромное количество игроков , а все расчеты должны делаться где то на сервере. С одной стороны кажется что ничего сложного, а с другой...В мире нет сервисов для создания ММО игр (сервисов что бы этот режим поддерживался из коробки)
Сейчас это готовый MVP состоящих из модулей. Ниже их краткий перечень
Редактор NPC и игроков (что бы не в эксель, а изменил - и сразу все в игре)
Редактор игровых механик (что бы вообще не завесить от программиста клиента и не обновлять игрокам клиенты, тоже поменял - и сразу все в игре применилось. Например скоро я реализую крафт, инвентарь - в клиенте один раз UI только сделать надо)
Импорт игровых карт - можно менять карты как душе угодно, создавать эвенты на новых локациях - даже не ходя к программисту клиента (при этом сервер будет знать где препятствия что бы NPC знали куда можно куда нельзя ходить)
Редактор ИИ для NPC (описывать скриптами их поведение и все игроки будут видеть что они делают - продукт только для онлайн игр)
Ну вот я про это и говорю.
Редактор NPC и игроков (что бы не в эксель, а изменил - и сразу все в игре)
Для этого в играх делается импортер конфигов или админка. Это разрабатывается вместе с игрой.
Редактор игровых механик (что бы вообще не завесить от программиста клиента
Как это? Я ввожу механику погоды, которая влияет на скорость регенерации растений в мире, из-за чего необходимость в растениях у NPC-фермеров снижается и они реже выдают квест на поиск растений — и это будет из коробки? Звучит здорово!
Например скоро я реализую крафт, инвентарь - в клиенте один раз UI только сделать надо)
У этого маловато практической пользы. Как обучающая штука пойдет, но как движок для игры — это вообще не туда. Крафт — одна из самых сложных игровых систем. А уж в ММО сделать её интересной — это отдельный челлендж. Я не особо понимаю, как можно "реализовать крафт" универсально. Для этого сначала должен быть дизайн и механика крафта, а потом уже админка для настройки. Если вы реализуете универсальный крафт, то конечно моё почтение, но это где-то на стыке гениального и невозможного.
У геймдизайнеров нет потребности реализовывать однотипные игры по шаблонам. Такая потребность есть у инвесторов. Но даже при создании "клонов" мобильных игр появляется очень много нюансов и там дело совсем не в том, что разработчик не знает, как объявить класс "Предмет" с параметром "Создаваемый" и загрузить в него список требуемых предметов для крафта.
Я хочу сказать, что такую вещь как ММОРПГ очень сложно унифицировать, поэтому админка с сущностями чуть более сложными, чем "отредактировать параметр в строке" вряд ли будет пользоваться спросом.
А чтобы пользовалась — нужно писать движок для игры, а не серверный модуль.
Для этого в играх делается импортер конфигов или админка. Это разрабатывается вместе с игрой.
- так почему бы не сделать что бы на каждую игру не делать свою админку ? в этом и идея
Как это? Я ввожу механику погоды,
- да и это понадобиться описать скриптами (обычно скриптами Lua делают , у меня PHP). Из под коробки вы можете добавлять на сервере любой игровой код (разве что напрямую с БД нельзя из под скриптов постучаться). Для этих целей в личном кабинете есть некий WEB редактор кода. В вашем случае я вижу что каждый раз когда попытка взять квест у NPC мы шлем команду проверки наличия квестов у него проверяются других вводные . тоже и регенерация
"реализовать крафт" универсально.
- на каждую игру можно создавать свои механники и описать ее в виде кода сервера (тк все это будет считать сервер - какие материалы, что выйдет какие шансы. и описать в виде скриптов)
но как движок для игры
- движок остается unity (или unreal или на чем там пишите). Тут промежуточное программное обеспечение. а именно серверная часть
У геймдизайнеров нет потребности реализовывать однотипные игры
тут как раз не про шаблоны а то про что встроенный инструмент дает возможность как угодно программировать сервер механики, добавлять свои
вот пример редактора кода механик с условным параметров погоды
вот как пример механика атака (все можно поменять в коде)
и таких механик может быть целая куча. их можно вешать на npc или их могут вызывать игроки по команде. И без разницы какой у вас движок (движком я понимаю Unity или UE).
Просто это сейчас каждый раз движки делать дл сложных задач. а я предлагаю отделить все в серверный модуль
для понимания как это работает :
Клиент с Unity игры отправляет команду - создай молоток
Сервер принимает команду смотрит что есть для молотка, если все ок - отнимает ресурсы и добавляет молоток , отправляя на клиент что ресурсов стало меньше и появился в инвентаре молоток
Как видите сам движок тут не играет значение. А вы уже на сервере в модуле добавляете черед UI редактор что у игрока могут быть (как пример, можно вписать что угодно)
железо
камень
древесина
и создаете команду - создай молоток в которой пишите небольшой скрипт где описываете шанс создать предмет и что для этого требуется и что в итоге появиться в инвентаре
сервер передает все что изменилось в кадре, клиент лишь анимирует
Ну вот видите, по итогу уже оказывается, что редактор механик не нужен, нужны правила для их связки между собой, а без разработчика игру сделать редактором механик не выйдет. И ещё проблема тут в том, что у вас пока в примерах простые механики. Как только механика станет чуть сложнее, сразу и скрипты внутри вашей админки станут сложнее. По итогу мне это видится как необходимость разрабатывать игру в двух местах.
Я понял принцип и цель, но для разработки игр это какая-то очень амбициозная машина, учитывая, как сложны бывают игры. А в особенности ММОРПГ.
Пример. Нужна механика уворота. Геймдизайнер её описал, разработчик написал скрипт. И вместо того, чтобы внутри своей привычной среды разработки он потом написал "если %уворот% == true, то income_dmg = 0", он это напишет внутри вашей админки.
Я правильно понимаю, что это плата за то, что серверное взаимодействие уже выстроено вами?
Ну и админку всё равно надо будет переписывать под каждую игру ведь.
Это я просто цепляюсь за:
быстро запускать и проверять игры MMO
Не получится это делать быстро, используя только ваш инструмент. К тому же, в каждой игре разные понятия, что должно обрабатываться на сервере, что - на клиенте. Т.е. это всё опять же к тому, что возможно вы сделали хороший модуль в помощь, но универсальным такому модулю стать — очень тяжело.
редактор механик - это инструмент где вы вводите код. только это не тот разработчик который будет разбираться как потом пакеты слать, разбираться во всем проекте - это некий набор правил что бы манипулировать игровыми существами
скрипты можно уже сейчас добавлять любой сложности (для этого не понадобиться менять редактор или что то на сетевом взаимодействии менять). Грубо говорят уже сейчас можно написать игру не меняя ни одного фаила на сервере
своей привычной среды разработки - моя идея разрушить стереотип что разработчик клиентской части должен писать сервер. Разработчику клеента вообще не надо писать скрипты, пусть он делает отображение анимации и визуальную реакцию на пришедшие пакеты. А гейм дизайнер контролит какие скрипты у него в проекте и полностью понимает что откуда идет
серверное взаимодействие уже выстроено вами - мной не выстроено серверное взаимодействие. Есть примеры механик и пример фреймворка который для MMO RPG подходит (https://github.com/webrobot1/framework-rpg2d) - таких фреймворком можно добавить сколько угодно , в тч менять текущий (без изменений фаилов на сервере - все через редактор)
Ну и админку всё равно надо будет переписывать - зачем переписывать админку. Вот у вас новая игра где появился параметр "Размер инвентаря"
Вы добавляете новый компонент Размер Инвентаря (в классическом сценарии разработки это как колонка в БД, у меня не совсем колонка, но допустим она), указываете у кого может он быть (у игроков например только)
Вы в редакторе какой то механики (это может механика положить предмет в инвентарь) вы описываете что количество ячеек ограничено этим параметром
С получением уровня этот стат увеличивается
Я к тому что нет такого пока параметра или механики что заставит переписать админку или менять на сервере мне фаилы в модуле - все настраивается через тулсеты и редактор (вы кодом можете что угодно описать и такую возможность я даю - это как облачный код от Amazon)
каждой игре разные понятия - вы можете привести любой и в итоге выйдет что все можно реализовать в моем инструменте. Это не шаблонные игры, не сборка сервера из типовых настроек. Это UI тулсеты для вещей которые нужны в любой игре (например добавление новых статов-параметров игрокам и существам) и редактор кода (который можно описать ВСЕ что угодно. Просто это делается не где то там в фаилах и экселях, в а специальной web панели)
Не получится это делать быстро - разработка MMO это десятки специалистов и миллионные бюджеты и под каждую игру придумать архитектуру сервера, бд и прочее.
Билу Гейству когда он презентовал windows тоже говорили что никому не нужно, и ПК тока для программистов и невозможно будет с мышкой, и папками нормально ничего написать
Потом двинемся немного в будущее , к изобретателю Тильды - ему наверняка говорили что каждый дизайн сайта уникальный и невозможно сделать универсального ничего (думаю в в Тильде даже свой дизайн и тему можно делать)
нужны правила для их связки между собой - эти правила уже давно известны для игровых движков , называется Сущностное компонентная архитектура - ее Unity использует (а на ней можно какие угодно игры делать). В моем проекте именно она. И при желании можно и от этого отойти в редакторе описать что то свое.
Я настолько уверен что этот инструмент работает и что игру можно сделать в тч уровня одной из ныне популярных Warspear Online , что готов бесплатно предоставить ПО и участвовать в разработке сейчас за % от монетизации в будущем (с оговоркой что моя часть только сервер и я должен быть уверен в серьезности что и партнер готов будет довести до конца)
Но модули будут и новые , например я хочу сделать по аналогии с загрузкой карты загрузку анимации существ , предметов, добавление музыки и звуковых эффектов в WEB кабинет.
Таким образом можно добавлять предметы как и карты по щелчку мышки , а игровые клиенты будут подтягивать обновления и сразу видеть их.
Благодаря реактору NPC можно легко добавить из кого будет и эта вся информация будет не в экселях а в БД (каждый с доступом в любой момент может посмотреть и поменять когда надо)
Скажем так - я создаю не какой то аналог чего то и пытаюсь убедить что это лучше. Я создаю пока первый в мире готовый сервис для MMO (альтернатива это писать под каждую игру свою сервер, что сейчас и происходит) и набором тулсетов
К вашим вычислениям FPS на сайте вопросы.
Почему вы включаете туда время на отправку данных игрокам, если это вообще параллельный процесс и на FPS никак влиять не должен? По идее во время обработки включается только обработка пришедших команд от пользователей, обсчет их действий и изменения мира и упаковка результатов для отправки?
В расчетах указано про 50 созданий и время обсчета, но ведь у всех игр логика взаимодействия с миром и друг другом разной степени тяжести. Более того, привзаимодейиствии игроков в области каждый с каждым количество взаимодействий для обсчета растет экспоненциально, поэтому говорить, что раз 50 созданий обсчитывается за 30% CPU, то на 2х ядрах получим 350 комфортно играющих игроков совсем некорректно.
Не знаю, почему у меня статья вызывает много злости и агрессии. Наверное сам был когда то таким же. Приминительно к моим замечанием выше хотелось бы увидеть более применительные цифры к вашему движку, типа: 50, 100, 400 игроков взаимодействуют только с миром (набор встроенеых в движок действий/механик) - загрузка CPU и тоже самое, но взаимодействуют все друг с другом в одном месте, аля массовое побоище.
Вопрос 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 на отправку каждому игроку ?
Теперь когда вы объяснили, что это оверхед на передачу между сервером физики и сервером отправки - я согласен. Но исходя из описания на сайте сложилось ощущение, что вы включаете время отправки сообщений игрокам из-за того, что указывали размер пакета и скорость соединения на обоих концах и расположение сервера и игроков. Поэтому я и стал задавать вопрос.
Когда на сетевое устройство переданы все пакеты я считаю это завершение кадра
Опять же, выглядит, что ваш websocket server отделен логически от сервера физики, значит концом кадра является передача от сервера физики на сервер вебсокета, а не на сетевое устройство. Т.к. у сервера websocket там может быть еще логика по компрессии данных например, а сервер физики уже мог бы начать новый кадр считать, компрессия данных не его задача.
Вопрос 2: да , механики разные. Но сейчас такие показатели (мобы ходят, ищут других, стреляют постоянно, ищут короткий путь до целей, регенерируют, воскрешаются).
Я и не скрываю данный факт , и на сайте приписку об этом сделал.
Можно например поиск пути что бы не все возможные пути искал, а лишь если не встретил хуже того что уже нашел и будет еще быстрее (не все механики прям отточены, но изменить одну просто - код каждый отдельно каждая хранится и замеряются, считайте что на каждую механику свой фаил).
Можно анализировать каждую механику конкретно, пример на фото ниже и в админ панели по ссылке Производительность (можно по демо доступам зайти)
Вот код который их замеряет (часть кода моего сервиса открыто) https://github.com/webrobot1/framework-rpg2d/blob/master/Frame.php#L127
Экспонент там нет. Все существа обрабатываются по очереди и в каждом существе обрабатываются все механики если им пришло врем выполняться в этом кадре (код чуть выше того ссылку на который я дал). Например регенерации обрабатывается раз в 10 секунд (эти параметры уже не в Git записаны а редактируются на каждую игру в админ панели)
Еще раз уточню - во время драки если рядом много противников, кого мы можем задеть и если рядом никого или 1 противник - это разные сложности обсчета. Я и говорю про случай, сколько выдержит сервер при худшем варианте, когда все собрались в одном месте и бьются и много коллизий каждый с каждым. Когда каждый где то отдельно гасит 1го моба - понятно из расчетов.
У меня пока нет механик массовых коллизий (типа взрыва который задевает в радиусе кого то), но я заранее могу сказать что сильно не изменится ничего (шутеры и гонки - согласен на моем продукте не сделать, но там и не нужна авторитарность)
Точных метрик на все случаи жизни не сделать (да и не каждый игрок будет постоянно стрелять). Я привел метрики в худшем варианте текущих механик
Система горизонтально масштабируется и обработку части NPC и игроков можно поручить отдельной физической машине (при этом все продолжат играть в едином мире)
для этого я сделал SAAS версию где каждый может взять мою демку игры на Unity и написать свои механики в личном кабинете (там бесплатный режим есть).
Это ведь не шаблоны - можно как угодно код менять (только в БД напрямую слать запросы нельзя и сетевые ресурсы не доступны)
Еще раз уточню - во время драки если рядом много противников, кого мы можем задеть и если рядом никого или 1 противник - это разные сложности обсчета.
Зависит от архитектуры программы, можно сделать примерно константно, особенно на дискретных сетках
Про злость и агрессию - мой наставник говорит что такое в РФ постоянно ко всему новому. А на западе не так - там с интересом относятся ко всему новому (сам не проверял не знаю).
Если это так то полагаю что в РФ люди привыкли что все новое делают что бы нажиться, а не для людей. И делают плохо (может поэтому и мало кто что делает в РФ. Страна большая а доля игрового рынка 1.8% по официальной статистике)
Тем не менее я делаю и игру свою и продолжу делать. Если по итогу окажется что как B2B решение в РФ оно не нужно - сделаю на запад или переключусь делать игру. Сейчас у всех NPC массовое побоище (по умолчанию они активны когда игрок рядом, я настроил в админке что и без игроков они друг друга бьют и стреляют)
Я буду честен с вами - я не думаю что будет результат хуже того FPS чем я указал (NPC выстрелит милилсекунда в миллисекунду когда пройдет дебаф на заклятие. Тоже и на другие механики. Игрок живой не так активен будет и не постоянно в режиме побоища)
могут одновременно играть +-300 игроков, формулы расчета есть на моем сайте.
И таких серверов может бесконечно и это останется единый бесшовный мир, где игроки со всего мира будут играть вместе
А как это реализуется, что игроки играющие на разных серверах играют вместе?
Сервера программы (назовем их комнатами-локациями) друг с другом соединяются по tcp (как игроки с сервером - тот же принцип) и обмениваются данными (не важно на одной машине они или нет)
На каждой машине по несколько запущенных комнат небольшой локации (как часть единой карты, что бы по максимум cpu использовать)
Стоя на границе локации не важно что дальше (другая машина или локация на этой же) - игрок видит что там происходит (если дизайн подходящий то и не заметны границы)
Для примера фаербол может лететь через разные машины по локациям, как и npc и игроки ходить
ну получается клиент получает пакеты с нескольких серверов, если игрок стоит на стыке? Или есть какой-то главный сервер, который собирает со всех нужных и отсылает клиенту?
Если быть точнее: смежные сервер-локации сами передают данные друг другу, после чего рассылают "своим" игрокам
Так что тот сервер на котором сейчас стоит игрок при получении с соседнего каких то обновлений разошлет игроку что на смежном сервере происходит
Какие локации смежные - я в админ панели на сетке размещаю.
Например здание магазина в игре скорее всего не смежная ни с какой локация - перед его входом на клетке можно разместить телепорт - таким образом игрок попадает на НЕ смежные локации
Если быть точнее: смежные сервер-локации сами передают данные друг другу, после чего рассылают "своим" игрокам
спасибо, принцип понял
Но и сервер другому серверу может не только пакеты исполненные в нем передавать, а так за запрос выполнить что то у себя.
Пример - на границе карт применена магия взрыва что затрагивает в радиусе 10 клеток существ (в механики будет поиск существ в радиусе и не важно на каком они сервере отправлена команда - Повесить событие получение урона в 10 жизней)
игровые карты я выкладываю на GitHub постепенно (там есть превью как они выглядят - можно из них собрать свой игровой мир)
Хотите помогу в ваш клиент сделать плагин к сервису ? Или на пару сделать на Unity игру (он может и громоздкий, но его много кто знает, включая меня - почитал тут вашу статью)
Хотите помогу в ваш клиент сделать плагин к сервису ?
не понял, это как и зачем?
на пару сделать на Unity игру
я не работал с юнити
я вижу вы делаете игру. Я могу к вашему клиенту игры соединить свое ПО (выдам вам бесплатный доступ, потом захотите договоримся и на Ваш сервер поставим - будите в админ панели механики скриптами описывать, а клиент будет визуализировать у себя на основе пакетов приходящих изменения). так быстрее MMO сделаете )
там и карты игровые можете слать в свой клиент (я их делаю в программе Tiled - оф сайт может без vpn не открыться https://www.mapeditor.org/)
к вашему клиенту игры соединить свое ПО
каким образом?
механики скриптами описывать
я не очень понимаю, как из вашей админ панели скрипты с механиками проникнут в мой работающий бинарник, можете пояснить?
а клиент будет визуализировать у себя на основе пакетов приходящих изменения
у меня так и сделано. Только не изменения (потому что тогда надо где-то запоминать, что изменилось, а что нет), а просто то, что видит игрок. Поэтому у меня нативным образом игра бесшовная и скорость исполнения не зависит от числа игроков рядом.
так быстрее MMO сделаете
дак у меня уже сделано. Вопрос в том, как накидать побольше контента, но это больше упирается в рисование. И сейчас думаю о новом типе искусственного интеллекта.
ПС: только не надо больше скриншотов, пожалуйста
каким образом?
Главный вопрос - интересно ли Вам.
Сервер работает с клиентом по API (игрок оправляет команды - сервер возвращается что меняется, тут я постарался описать как это работает)
как проникнут в мой работающий бинарник, можете пояснить
возьмем механику выстрела - вы отправляете команду в сервер Стрелять, сервер возвращает json что у вас стало меньше маны и что на сцене появился фаерболт (и далее шлет пакеты что меняются его позиции) - в клиенте вы анимируете
игрок оправляет команды - сервер возвращается что меняется
у меня так и сделано, только сервер не возвращает ответ сразу, а в своем цикле рассылает всем игрокам то, что они видят/слышат. Т.к. окружении игрока может изменится, даже если он ничего не отправлял.
возьмем механику выстрела - вы отправляете команду в сервер Стрелять, сервер возвращает json что у вас стало меньше маны и что на сцене появился фаербол
Вы всё время даёте какое-то внешнее объяснение, но я пытаюсь понять, как это работает внутри. Во-первых, что тут сервер? Мне кажется мы разное под этим понимаем. Для меня сервер - это программа, где крутится игровой цикл и она же обменивается пакетами с внешним миром. У вас, похоже, сервер - это какая-то прослойка между ядром игры и клиентом.
Откуда ваш сервер узнает, сколько у меня стало маны, в какой координате появился фаербол и т.д.? Как оперировать с внутриигровыми переменными из скрипта?
Если вам интересно посмотреть как устроена архитектура - у меня ряд статей , вот одна из них (фото архитектуры там есть) - https://habr.com/ru/articles/780602/
Там очень поверхностно:
WebSocket сервер - принимает и отправляет пакеты, про игру он не знает ничего
Игровой сервер - загружает из БД данные введенные в админ панели (загруженные карты, данные игроков, npc, анимации) для отправки в сервис WebSocket на отправку игрока и сохраняя изменения и запуская игровой кадр сервиса ниже...
Песочница (сервер Game механик) - это тот процесс в котором выполняется пользовательский код добавленный через админ панель. Здесь происходят расчеты текущего кадра: физики, поиска путей, что какой npc в этом кадре делает (двигается, регенерирует, атакует и т.д.)
Что из этого мы можем понять? Вебсокет сервер перенаправляет пакет в игровой сервер, тот добавляет какую-то свою инфу и отправляет это в "песочницу" там они прогоняются через какие-то скрипты якобы произвольного содержимого, полученный результат обратно в игровой или сразу в вебсокет.
Чтобы всё это работало нужно какое-то соглашение о форматах, данных и прочем.
И поэтому мне непонятно, что вы предлагаете? Мой сервер не поймёт содержимого ваших пакетов, ваших карт, нпс и уж тем более ему не нужны анимации. Переписать его для совместимости или вообще заново сделать?
Возможно в видео будет понятнее как это работает
ч.16 Сервер для 2D MMO RPG игры (realtime) — MVP готов