серверное взаимодействие уже выстроено вами - мной не выстроено серверное взаимодействие. Есть примеры механик и пример фреймворка который для MMO RPG подходит (https://github.com/webrobot1/framework-rpg2d) - таких фреймворком можно добавить сколько угодно , в тч менять текущий (без изменений фаилов на сервере - все через редактор)
своей привычной среды разработки - моя идея разрушить стереотип что разработчик клиентской части должен писать сервер. Разработчику клеента вообще не надо писать скрипты, пусть он делает отображение анимации и визуальную реакцию на пришедшие пакеты. А гейм дизайнер контролит какие скрипты у него в проекте и полностью понимает что откуда идет
скрипты можно уже сейчас добавлять любой сложности (для этого не понадобиться менять редактор или что то на сетевом взаимодействии менять). Грубо говорят уже сейчас можно написать игру не меняя ни одного фаила на сервере
редактор механик - это инструмент где вы вводите код. только это не тот разработчик который будет разбираться как потом пакеты слать, разбираться во всем проекте - это некий набор правил что бы манипулировать игровыми существами
Клиент с Unity игры отправляет команду - создай молоток
Сервер принимает команду смотрит что есть для молотка, если все ок - отнимает ресурсы и добавляет молоток , отправляя на клиент что ресурсов стало меньше и появился в инвентаре молоток
Как видите сам движок тут не играет значение. А вы уже на сервере в модуле добавляете черед UI редактор что у игрока могут быть (как пример, можно вписать что угодно)
железо
камень
древесина
и создаете команду - создай молоток в которой пишите небольшой скрипт где описываете шанс создать предмет и что для этого требуется и что в итоге появиться в инвентаре
сервер передает все что изменилось в кадре, клиент лишь анимирует
и таких механик может быть целая куча. их можно вешать на npc или их могут вызывать игроки по команде. И без разницы какой у вас движок (движком я понимаю Unity или UE).
Просто это сейчас каждый раз движки делать дл сложных задач. а я предлагаю отделить все в серверный модуль
Для этого в играх делается импортер конфигов или админка. Это разрабатывается вместе с игрой.
- так почему бы не сделать что бы на каждую игру не делать свою админку ? в этом и идея
Как это? Я ввожу механику погоды,
- да и это понадобиться описать скриптами (обычно скриптами Lua делают , у меня PHP). Из под коробки вы можете добавлять на сервере любой игровой код (разве что напрямую с БД нельзя из под скриптов постучаться). Для этих целей в личном кабинете есть некий WEB редактор кода. В вашем случае я вижу что каждый раз когда попытка взять квест у NPC мы шлем команду проверки наличия квестов у него проверяются других вводные . тоже и регенерация
"реализовать крафт" универсально.
- на каждую игру можно создавать свои механники и описать ее в виде кода сервера (тк все это будет считать сервер - какие материалы, что выйдет какие шансы. и описать в виде скриптов)
но как движок для игры
- движок остается unity (или unreal или на чем там пишите). Тут промежуточное программное обеспечение. а именно серверная часть
У геймдизайнеров нет потребности реализовывать однотипные игры
тут как раз не про шаблоны а то про что встроенный инструмент дает возможность как угодно программировать сервер механики, добавлять свои
Но модули будут и новые , например я хочу сделать по аналогии с загрузкой карты загрузку анимации существ , предметов, добавление музыки и звуковых эффектов в WEB кабинет.
Таким образом можно добавлять предметы как и карты по щелчку мышки , а игровые клиенты будут подтягивать обновления и сразу видеть их.
Благодаря реактору NPC можно легко добавить из кого будет и эта вся информация будет не в экселях а в БД (каждый с доступом в любой момент может посмотреть и поменять когда надо)
Скажем так - я создаю не какой то аналог чего то и пытаюсь убедить что это лучше. Я создаю пока первый в мире готовый сервис для MMO (альтернатива это писать под каждую игру свою сервер, что сейчас и происходит) и набором тулсетов
Сейчас это готовый MVP состоящих из модулей. Ниже их краткий перечень
Редактор NPC и игроков (что бы не в эксель, а изменил - и сразу все в игре)
Редактор игровых механик (что бы вообще не завесить от программиста клиента и не обновлять игрокам клиенты, тоже поменял - и сразу все в игре применилось. Например скоро я реализую крафт, инвентарь - в клиенте один раз UI только сделать надо)
Импорт игровых карт - можно менять карты как душе угодно, создавать эвенты на новых локациях - даже не ходя к программисту клиента (при этом сервер будет знать где препятствия что бы NPC знали куда можно куда нельзя ходить)
Редактор ИИ для NPC (описывать скриптами их поведение и все игроки будут видеть что они делают - продукт только для онлайн игр)
Я делаю такой продукт, что бы быстро запускать и проверять игры MMO.
Самое сложное что для такого жанра он должен поддерживать огромное количество игроков , а все расчеты должны делаться где то на сервере. С одной стороны кажется что ничего сложного, а с другой...В мире нет сервисов для создания ММО игр (сервисов что бы этот режим поддерживался из коробки)
Я считаю что создавать для каждого коннекта отдельный процесс или thread параллели как либо это не нужной задачей.
И даже не потому что игра на 3 человека - явно игроки шлют небольшие пакеты до 100 байт, и на получение этого пакета уйдет менее 1мс и можно делать в одном потоке. ну и пауза между следующим пакетом у вас явно есть (если конечно пакеты не летят как в стриминг сервере без пауз, что неправильно)
Вы потеряете куда больше времени на синхронизацию данных между этими потоками/процессами . Я полагаю можно реализовать на питоне подписку на каждый сокет которая при приеме пакетов отправляет в очередь команду игрока и продолжает слушать.
Я рекомендую делать 2 процесса - первый на websocket соединения, второй для расчета команд из очереди (если у вас там npc есть - там же будут расчитываться вместе со всей физикой)
Статья про frame latency , а не про нагрузку заголовков tcp и я как раз НЕ смешиваю их. В конце концов мне решать как подавать материал о котором я рассказываю
На них* (описался). Тут речь про то, что в классическом http взаимодействии вы отправляете запрос и ждете ответа (например когда ждете загрузку страницы).
А с WebSocket у вас нет блокировки - вы отправляете пакет и возвращается управление (и у вас приходят пакеты , хотя ваш еще может и не быть обработан, но спустя какое то время и результат на ваш запрос придет и других игроков пакетом. Например когда много игроков отправили команды движения)
Людей "Персонажами" не называют. К вопросу у кого чвс и хамство. Вы завидуете, как еще объяснить внимание к лично моей персоне (а не к тому, о чем пишу). И сайт опубликовал и работу продолжил и завершу несмотря на критику
И сервер авторитарный. Это посложнее чем на клиенте расчитывать и просто готовые пакеты передавать. Так что ненадо сравнивать известный ммо (название которого вы боитесь сказать) и мой проект , где я делюсь всем с другими
серверное взаимодействие уже выстроено вами - мной не выстроено серверное взаимодействие. Есть примеры механик и пример фреймворка который для MMO RPG подходит (https://github.com/webrobot1/framework-rpg2d) - таких фреймворком можно добавить сколько угодно , в тч менять текущий (без изменений фаилов на сервере - все через редактор)
своей привычной среды разработки - моя идея разрушить стереотип что разработчик клиентской части должен писать сервер. Разработчику клеента вообще не надо писать скрипты, пусть он делает отображение анимации и визуальную реакцию на пришедшие пакеты. А гейм дизайнер контролит какие скрипты у него в проекте и полностью понимает что откуда идет
скрипты можно уже сейчас добавлять любой сложности (для этого не понадобиться менять редактор или что то на сетевом взаимодействии менять). Грубо говорят уже сейчас можно написать игру не меняя ни одного фаила на сервере
редактор механик - это инструмент где вы вводите код. только это не тот разработчик который будет разбираться как потом пакеты слать, разбираться во всем проекте - это некий набор правил что бы манипулировать игровыми существами
для понимания как это работает :
Клиент с Unity игры отправляет команду - создай молоток
Сервер принимает команду смотрит что есть для молотка, если все ок - отнимает ресурсы и добавляет молоток , отправляя на клиент что ресурсов стало меньше и появился в инвентаре молоток
Как видите сам движок тут не играет значение. А вы уже на сервере в модуле добавляете черед UI редактор что у игрока могут быть (как пример, можно вписать что угодно)
железо
камень
древесина
и создаете команду - создай молоток в которой пишите небольшой скрипт где описываете шанс создать предмет и что для этого требуется и что в итоге появиться в инвентаре
сервер передает все что изменилось в кадре, клиент лишь анимирует
и таких механик может быть целая куча. их можно вешать на npc или их могут вызывать игроки по команде. И без разницы какой у вас движок (движком я понимаю Unity или UE).
Просто это сейчас каждый раз движки делать дл сложных задач. а я предлагаю отделить все в серверный модуль
вот как пример механика атака (все можно поменять в коде)
вот пример редактора кода механик с условным параметров погоды
- так почему бы не сделать что бы на каждую игру не делать свою админку ? в этом и идея
- да и это понадобиться описать скриптами (обычно скриптами Lua делают , у меня PHP). Из под коробки вы можете добавлять на сервере любой игровой код (разве что напрямую с БД нельзя из под скриптов постучаться). Для этих целей в личном кабинете есть некий WEB редактор кода. В вашем случае я вижу что каждый раз когда попытка взять квест у NPC мы шлем команду проверки наличия квестов у него проверяются других вводные . тоже и регенерация
- на каждую игру можно создавать свои механники и описать ее в виде кода сервера (тк все это будет считать сервер - какие материалы, что выйдет какие шансы. и описать в виде скриптов)
- движок остается unity (или unreal или на чем там пишите). Тут промежуточное программное обеспечение. а именно серверная часть
тут как раз не про шаблоны а то про что встроенный инструмент дает возможность как угодно программировать сервер механики, добавлять свои
Но модули будут и новые , например я хочу сделать по аналогии с загрузкой карты загрузку анимации существ , предметов, добавление музыки и звуковых эффектов в WEB кабинет.
Таким образом можно добавлять предметы как и карты по щелчку мышки , а игровые клиенты будут подтягивать обновления и сразу видеть их.
Благодаря реактору NPC можно легко добавить из кого будет и эта вся информация будет не в экселях а в БД (каждый с доступом в любой момент может посмотреть и поменять когда надо)
Скажем так - я создаю не какой то аналог чего то и пытаюсь убедить что это лучше. Я создаю пока первый в мире готовый сервис для MMO (альтернатива это писать под каждую игру свою сервер, что сейчас и происходит) и набором тулсетов
Сейчас это готовый MVP состоящих из модулей. Ниже их краткий перечень
Редактор NPC и игроков (что бы не в эксель, а изменил - и сразу все в игре)
Редактор игровых механик (что бы вообще не завесить от программиста клиента и не обновлять игрокам клиенты, тоже поменял - и сразу все в игре применилось. Например скоро я реализую крафт, инвентарь - в клиенте один раз UI только сделать надо)
Импорт игровых карт - можно менять карты как душе угодно, создавать эвенты на новых локациях - даже не ходя к программисту клиента (при этом сервер будет знать где препятствия что бы NPC знали куда можно куда нельзя ходить)
Редактор ИИ для NPC (описывать скриптами их поведение и все игроки будут видеть что они делают - продукт только для онлайн игр)
Я делаю такой продукт, что бы быстро запускать и проверять игры MMO.
Самое сложное что для такого жанра он должен поддерживать огромное количество игроков , а все расчеты должны делаться где то на сервере. С одной стороны кажется что ничего сложного, а с другой...В мире нет сервисов для создания ММО игр (сервисов что бы этот режим поддерживался из коробки)
Я считаю что создавать для каждого коннекта отдельный процесс или thread параллели как либо это не нужной задачей.
И даже не потому что игра на 3 человека - явно игроки шлют небольшие пакеты до 100 байт, и на получение этого пакета уйдет менее 1мс и можно делать в одном потоке. ну и пауза между следующим пакетом у вас явно есть (если конечно пакеты не летят как в стриминг сервере без пауз, что неправильно)
Вы потеряете куда больше времени на синхронизацию данных между этими потоками/процессами . Я полагаю можно реализовать на питоне подписку на каждый сокет которая при приеме пакетов отправляет в очередь команду игрока и продолжает слушать.
Я рекомендую делать 2 процесса - первый на websocket соединения, второй для расчета команд из очереди (если у вас там npc есть - там же будут расчитываться вместе со всей физикой)
Я делаю так в своем проекте с 2D открытым миром
Статья про frame latency , а не про нагрузку заголовков tcp и я как раз НЕ смешиваю их. В конце концов мне решать как подавать материал о котором я рассказываю
На них* (описался). Тут речь про то, что в классическом http взаимодействии вы отправляете запрос и ждете ответа (например когда ждете загрузку страницы).
А с WebSocket у вас нет блокировки - вы отправляете пакет и возвращается управление (и у вас приходят пакеты , хотя ваш еще может и не быть обработан, но спустя какое то время и результат на ваш запрос придет и других игроков пакетом. Например когда много игроков отправили команды движения)
Если безразличен какое вам дело о моем Вузе, что я там хочу/нехочу, что я там сайт сделал и вообще предыдущей комментарий только обомне лично
Я рассказываю о своей работе. А вы даже сами себе врете что вам безразлично.
Пытаться оскорблять авторов лично не признак большого ума знаете ли
Людей "Персонажами" не называют. К вопросу у кого чвс и хамство. Вы завидуете, как еще объяснить внимание к лично моей персоне (а не к тому, о чем пишу). И сайт опубликовал и работу продолжил и завершу несмотря на критику
Вот без теории у человека - только код на C#. Но через 3 года оказалось все еле работает.
Есть выражение : не указывайте человеку что ему делать, а он не будет говорить куда идти.
Мои статьи содержать отметку не "туториал", а "роадмап" и читать Вас их никто не заставлят.
И сервер авторитарный. Это посложнее чем на клиенте расчитывать и просто готовые пакеты передавать. Так что ненадо сравнивать известный ммо (название которого вы боитесь сказать) и мой проект , где я делюсь всем с другими