У меня пока нет механик массовых коллизий (типа взрыва который задевает в радиусе кого то), но я заранее могу сказать что сильно не изменится ничего (шутеры и гонки - согласен на моем продукте не сделать, но там и не нужна авторитарность)
Точных метрик на все случаи жизни не сделать (да и не каждый игрок будет постоянно стрелять). Я привел метрики в худшем варианте текущих механик
Система горизонтально масштабируется и обработку части NPC и игроков можно поручить отдельной физической машине (при этом все продолжат играть в едином мире)
Про злость и агрессию - мой наставник говорит что такое в РФ постоянно ко всему новому. А на западе не так - там с интересом относятся ко всему новому (сам не проверял не знаю).
Если это так то полагаю что в РФ люди привыкли что все новое делают что бы нажиться, а не для людей. И делают плохо (может поэтому и мало кто что делает в РФ. Страна большая а доля игрового рынка 1.8% по официальной статистике)
Тем не менее я делаю и игру свою и продолжу делать. Если по итогу окажется что как B2B решение в РФ оно не нужно - сделаю на запад или переключусь делать игру. Сейчас у всех NPC массовое побоище (по умолчанию они активны когда игрок рядом, я настроил в админке что и без игроков они друг друга бьют и стреляют)
Я буду честен с вами - я не думаю что будет результат хуже того FPS чем я указал (NPC выстрелит милилсекунда в миллисекунду когда пройдет дебаф на заклятие. Тоже и на другие механики. Игрок живой не так активен будет и не постоянно в режиме побоища)
Вопрос 2: да , механики разные. Но сейчас такие показатели (мобы ходят, ищут других, стреляют постоянно, ищут короткий путь до целей, регенерируют, воскрешаются).
Я и не скрываю данный факт , и на сайте приписку об этом сделал.
Можно например поиск пути что бы не все возможные пути искал, а лишь если не встретил хуже того что уже нашел и будет еще быстрее (не все механики прям отточены, но изменить одну просто - код каждый отдельно каждая хранится и замеряются, считайте что на каждую механику свой фаил).
Можно анализировать каждую механику конкретно, пример на фото ниже и в админ панели по ссылке Производительность (можно по демо доступам зайти)
Экспонент там нет. Все существа обрабатываются по очереди и в каждом существе обрабатываются все механики если им пришло врем выполняться в этом кадре (код чуть выше того ссылку на который я дал). Например регенерации обрабатывается раз в 10 секунд (эти параметры уже не в Git записаны а редактируются на каждую игру в админ панели)
Вопрос 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 на отправку каждому игроку ?
Сервера программы (назовем их комнатами-локациями) друг с другом соединяются по tcp (как игроки с сервером - тот же принцип) и обмениваются данными (не важно на одной машине они или нет)
На каждой машине по несколько запущенных комнат небольшой локации (как часть единой карты, что бы по максимум cpu использовать)
Стоя на границе локации не важно что дальше (другая машина или локация на этой же) - игрок видит что там происходит (если дизайн подходящий то и не заметны границы)
Для примера фаербол может лететь через разные машины по локациям, как и npc и игроки ходить
Я настолько уверен что этот инструмент работает и что игру можно сделать в тч уровня одной из ныне популярных Warspear Online , что готов бесплатно предоставить ПО и участвовать в разработке сейчас за % от монетизации в будущем (с оговоркой что моя часть только сервер и я должен быть уверен в серьезности что и партнер готов будет довести до конца)
нужны правила для их связки между собой - эти правила уже давно известны для игровых движков , называется Сущностное компонентная архитектура - ее Unity использует (а на ней можно какие угодно игры делать). В моем проекте именно она. И при желании можно и от этого отойти в редакторе описать что то свое.
Не получится это делать быстро - разработка MMO это десятки специалистов и миллионные бюджеты и под каждую игру придумать архитектуру сервера, бд и прочее.
Билу Гейству когда он презентовал windows тоже говорили что никому не нужно, и ПК тока для программистов и невозможно будет с мышкой, и папками нормально ничего написать
Потом двинемся немного в будущее , к изобретателю Тильды - ему наверняка говорили что каждый дизайн сайта уникальный и невозможно сделать универсального ничего (думаю в в Тильде даже свой дизайн и тему можно делать)
каждой игре разные понятия - вы можете привести любой и в итоге выйдет что все можно реализовать в моем инструменте. Это не шаблонные игры, не сборка сервера из типовых настроек. Это UI тулсеты для вещей которые нужны в любой игре (например добавление новых статов-параметров игрокам и существам) и редактор кода (который можно описать ВСЕ что угодно. Просто это делается не где то там в фаилах и экселях, в а специальной web панели)
Ну и админку всё равно надо будет переписывать - зачем переписывать админку. Вот у вас новая игра где появился параметр "Размер инвентаря"
Вы добавляете новый компонент Размер Инвентаря (в классическом сценарии разработки это как колонка в БД, у меня не совсем колонка, но допустим она), указываете у кого может он быть (у игроков например только)
Вы в редакторе какой то механики (это может механика положить предмет в инвентарь) вы описываете что количество ячеек ограничено этим параметром
С получением уровня этот стат увеличивается
Я к тому что нет такого пока параметра или механики что заставит переписать админку или менять на сервере мне фаилы в модуле - все настраивается через тулсеты и редактор (вы кодом можете что угодно описать и такую возможность я даю - это как облачный код от Amazon)
серверное взаимодействие уже выстроено вами - мной не выстроено серверное взаимодействие. Есть примеры механик и пример фреймворка который для MMO RPG подходит (https://github.com/webrobot1/framework-rpg2d) - таких фреймворком можно добавить сколько угодно , в тч менять текущий (без изменений фаилов на сервере - все через редактор)
своей привычной среды разработки - моя идея разрушить стереотип что разработчик клиентской части должен писать сервер. Разработчику клеента вообще не надо писать скрипты, пусть он делает отображение анимации и визуальную реакцию на пришедшие пакеты. А гейм дизайнер контролит какие скрипты у него в проекте и полностью понимает что откуда идет
скрипты можно уже сейчас добавлять любой сложности (для этого не понадобиться менять редактор или что то на сетевом взаимодействии менять). Грубо говорят уже сейчас можно написать игру не меняя ни одного фаила на сервере
редактор механик - это инструмент где вы вводите код. только это не тот разработчик который будет разбираться как потом пакеты слать, разбираться во всем проекте - это некий набор правил что бы манипулировать игровыми существами
Клиент с Unity игры отправляет команду - создай молоток
Сервер принимает команду смотрит что есть для молотка, если все ок - отнимает ресурсы и добавляет молоток , отправляя на клиент что ресурсов стало меньше и появился в инвентаре молоток
Как видите сам движок тут не играет значение. А вы уже на сервере в модуле добавляете черед UI редактор что у игрока могут быть (как пример, можно вписать что угодно)
железо
камень
древесина
и создаете команду - создай молоток в которой пишите небольшой скрипт где описываете шанс создать предмет и что для этого требуется и что в итоге появиться в инвентаре
сервер передает все что изменилось в кадре, клиент лишь анимирует
и таких механик может быть целая куча. их можно вешать на npc или их могут вызывать игроки по команде. И без разницы какой у вас движок (движком я понимаю Unity или UE).
Просто это сейчас каждый раз движки делать дл сложных задач. а я предлагаю отделить все в серверный модуль
для этого я сделал SAAS версию где каждый может взять мою демку игры на Unity и написать свои механики в личном кабинете (там бесплатный режим есть).
Это ведь не шаблоны - можно как угодно код менять (только в БД напрямую слать запросы нельзя и сетевые ресурсы не доступны)
У меня пока нет механик массовых коллизий (типа взрыва который задевает в радиусе кого то), но я заранее могу сказать что сильно не изменится ничего (шутеры и гонки - согласен на моем продукте не сделать, но там и не нужна авторитарность)
Точных метрик на все случаи жизни не сделать (да и не каждый игрок будет постоянно стрелять). Я привел метрики в худшем варианте текущих механик
Система горизонтально масштабируется и обработку части NPC и игроков можно поручить отдельной физической машине (при этом все продолжат играть в едином мире)
а как вы считаете кратко перефразировать какой блок что было понять ?)
Все не идеально написано, согласен
Логика по компрессии данных действительно есть
Про злость и агрессию - мой наставник говорит что такое в РФ постоянно ко всему новому. А на западе не так - там с интересом относятся ко всему новому (сам не проверял не знаю).
Если это так то полагаю что в РФ люди привыкли что все новое делают что бы нажиться, а не для людей. И делают плохо (может поэтому и мало кто что делает в РФ. Страна большая а доля игрового рынка 1.8% по официальной статистике)
Тем не менее я делаю и игру свою и продолжу делать. Если по итогу окажется что как B2B решение в РФ оно не нужно - сделаю на запад или переключусь делать игру. Сейчас у всех NPC массовое побоище (по умолчанию они активны когда игрок рядом, я настроил в админке что и без игроков они друг друга бьют и стреляют)
Я буду честен с вами - я не думаю что будет результат хуже того FPS чем я указал (NPC выстрелит милилсекунда в миллисекунду когда пройдет дебаф на заклятие. Тоже и на другие механики. Игрок живой не так активен будет и не постоянно в режиме побоища)
Вопрос 2: да , механики разные. Но сейчас такие показатели (мобы ходят, ищут других, стреляют постоянно, ищут короткий путь до целей, регенерируют, воскрешаются).
Я и не скрываю данный факт , и на сайте приписку об этом сделал.
Можно например поиск пути что бы не все возможные пути искал, а лишь если не встретил хуже того что уже нашел и будет еще быстрее (не все механики прям отточены, но изменить одну просто - код каждый отдельно каждая хранится и замеряются, считайте что на каждую механику свой фаил).
Можно анализировать каждую механику конкретно, пример на фото ниже и в админ панели по ссылке Производительность (можно по демо доступам зайти)
Вот код который их замеряет (часть кода моего сервиса открыто) https://github.com/webrobot1/framework-rpg2d/blob/master/Frame.php#L127
Экспонент там нет. Все существа обрабатываются по очереди и в каждом существе обрабатываются все механики если им пришло врем выполняться в этом кадре (код чуть выше того ссылку на который я дал). Например регенерации обрабатывается раз в 10 секунд (эти параметры уже не в Git записаны а редактируются на каждую игру в админ панели)
Вопрос 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 на отправку каждому игроку ?
Возможно в видео будет понятнее как это работает
Сервера программы (назовем их комнатами-локациями) друг с другом соединяются по tcp (как игроки с сервером - тот же принцип) и обмениваются данными (не важно на одной машине они или нет)
На каждой машине по несколько запущенных комнат небольшой локации (как часть единой карты, что бы по максимум cpu использовать)
Стоя на границе локации не важно что дальше (другая машина или локация на этой же) - игрок видит что там происходит (если дизайн подходящий то и не заметны границы)
Для примера фаербол может лететь через разные машины по локациям, как и npc и игроки ходить
Я настолько уверен что этот инструмент работает и что игру можно сделать в тч уровня одной из ныне популярных Warspear Online , что готов бесплатно предоставить ПО и участвовать в разработке сейчас за % от монетизации в будущем (с оговоркой что моя часть только сервер и я должен быть уверен в серьезности что и партнер готов будет довести до конца)
нужны правила для их связки между собой - эти правила уже давно известны для игровых движков , называется Сущностное компонентная архитектура - ее Unity использует (а на ней можно какие угодно игры делать). В моем проекте именно она. И при желании можно и от этого отойти в редакторе описать что то свое.
Не получится это делать быстро - разработка MMO это десятки специалистов и миллионные бюджеты и под каждую игру придумать архитектуру сервера, бд и прочее.
Билу Гейству когда он презентовал windows тоже говорили что никому не нужно, и ПК тока для программистов и невозможно будет с мышкой, и папками нормально ничего написать
Потом двинемся немного в будущее , к изобретателю Тильды - ему наверняка говорили что каждый дизайн сайта уникальный и невозможно сделать универсального ничего (думаю в в Тильде даже свой дизайн и тему можно делать)
каждой игре разные понятия - вы можете привести любой и в итоге выйдет что все можно реализовать в моем инструменте. Это не шаблонные игры, не сборка сервера из типовых настроек. Это UI тулсеты для вещей которые нужны в любой игре (например добавление новых статов-параметров игрокам и существам) и редактор кода (который можно описать ВСЕ что угодно. Просто это делается не где то там в фаилах и экселях, в а специальной web панели)
Ну и админку всё равно надо будет переписывать - зачем переписывать админку. Вот у вас новая игра где появился параметр "Размер инвентаря"
Вы добавляете новый компонент Размер Инвентаря (в классическом сценарии разработки это как колонка в БД, у меня не совсем колонка, но допустим она), указываете у кого может он быть (у игроков например только)
Вы в редакторе какой то механики (это может механика положить предмет в инвентарь) вы описываете что количество ячеек ограничено этим параметром
С получением уровня этот стат увеличивается
Я к тому что нет такого пока параметра или механики что заставит переписать админку или менять на сервере мне фаилы в модуле - все настраивается через тулсеты и редактор (вы кодом можете что угодно описать и такую возможность я даю - это как облачный код от Amazon)
серверное взаимодействие уже выстроено вами - мной не выстроено серверное взаимодействие. Есть примеры механик и пример фреймворка который для MMO RPG подходит (https://github.com/webrobot1/framework-rpg2d) - таких фреймворком можно добавить сколько угодно , в тч менять текущий (без изменений фаилов на сервере - все через редактор)
своей привычной среды разработки - моя идея разрушить стереотип что разработчик клиентской части должен писать сервер. Разработчику клеента вообще не надо писать скрипты, пусть он делает отображение анимации и визуальную реакцию на пришедшие пакеты. А гейм дизайнер контролит какие скрипты у него в проекте и полностью понимает что откуда идет
скрипты можно уже сейчас добавлять любой сложности (для этого не понадобиться менять редактор или что то на сетевом взаимодействии менять). Грубо говорят уже сейчас можно написать игру не меняя ни одного фаила на сервере
редактор механик - это инструмент где вы вводите код. только это не тот разработчик который будет разбираться как потом пакеты слать, разбираться во всем проекте - это некий набор правил что бы манипулировать игровыми существами
для понимания как это работает :
Клиент с Unity игры отправляет команду - создай молоток
Сервер принимает команду смотрит что есть для молотка, если все ок - отнимает ресурсы и добавляет молоток , отправляя на клиент что ресурсов стало меньше и появился в инвентаре молоток
Как видите сам движок тут не играет значение. А вы уже на сервере в модуле добавляете черед UI редактор что у игрока могут быть (как пример, можно вписать что угодно)
железо
камень
древесина
и создаете команду - создай молоток в которой пишите небольшой скрипт где описываете шанс создать предмет и что для этого требуется и что в итоге появиться в инвентаре
сервер передает все что изменилось в кадре, клиент лишь анимирует
и таких механик может быть целая куча. их можно вешать на npc или их могут вызывать игроки по команде. И без разницы какой у вас движок (движком я понимаю Unity или UE).
Просто это сейчас каждый раз движки делать дл сложных задач. а я предлагаю отделить все в серверный модуль
вот как пример механика атака (все можно поменять в коде)