Для этого в играх делается импортер конфигов или админка. Это разрабатывается вместе с игрой.
- так почему бы не сделать что бы на каждую игру не делать свою админку ? в этом и идея
Как это? Я ввожу механику погоды,
- да и это понадобиться описать скриптами (обычно скриптами 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 у вас нет блокировки - вы отправляете пакет и возвращается управление (и у вас приходят пакеты , хотя ваш еще может и не быть обработан, но спустя какое то время и результат на ваш запрос придет и других игроков пакетом. Например когда много игроков отправили команды движения)
Людей "Персонажами" не называют. К вопросу у кого чвс и хамство. Вы завидуете, как еще объяснить внимание к лично моей персоне (а не к тому, о чем пишу). И сайт опубликовал и работу продолжил и завершу несмотря на критику
И сервер авторитарный. Это посложнее чем на клиенте расчитывать и просто готовые пакеты передавать. Так что ненадо сравнивать известный ммо (название которого вы боитесь сказать) и мой проект , где я делюсь всем с другими
Я незнаю вашу область и игру. А это 14 по счету статья и 3й год моих исследований в этой области и имеется игра прототип в которой видно как все работает и она realtime
В третьих на устройства игроков должны приходить пакеты обновления мира в постоянном режиме. В четвертых есть очереди. Игры типа запрос-ответ на http делают разве что пошаговые.
Медленно для игр. Не про какие базы и 10мс речи на одну команду быть не может в ММО играх - это во первых. А во вторых игровой сервер это постоянно работающий процесс где обрабатываются и команды других игроков и npc
Сами игровые механик - их код на разных языках доступен в админ панели на моем сайте. Исходный код (актуальный) игры так же есть в git https://bitbucket.org/_catalogs/unity/src
вот пример редактора кода механик с условным параметров погоды
- так почему бы не сделать что бы на каждую игру не делать свою админку ? в этом и идея
- да и это понадобиться описать скриптами (обычно скриптами 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 года оказалось все еле работает.
Есть выражение : не указывайте человеку что ему делать, а он не будет говорить куда идти.
Мои статьи содержать отметку не "туториал", а "роадмап" и читать Вас их никто не заставлят.
И сервер авторитарный. Это посложнее чем на клиенте расчитывать и просто готовые пакеты передавать. Так что ненадо сравнивать известный ммо (название которого вы боитесь сказать) и мой проект , где я делюсь всем с другими
Я незнаю вашу область и игру. А это 14 по счету статья и 3й год моих исследований в этой области и имеется игра прототип в которой видно как все работает и она realtime
В третьих на устройства игроков должны приходить пакеты обновления мира в постоянном режиме. В четвертых есть очереди. Игры типа запрос-ответ на http делают разве что пошаговые.
Медленно для игр. Не про какие базы и 10мс речи на одну команду быть не может в ММО играх - это во первых. А во вторых игровой сервер это постоянно работающий процесс где обрабатываются и команды других игроков и npc
Http протокол , а с ним и его сервера слишком медленные
исходный код первых версий (старых) я jпубликовал в git https://github.com/webrobot1
Сами игровые механик - их код на разных языках доступен в админ панели на моем сайте.
Исходный код (актуальный) игры так же есть в git https://bitbucket.org/_catalogs/unity/src
если я привожу в пример в своих статьях библиотеки - они так же для PHP
Эта статья 14-ая по счету. Я рассказываю только об архитектуре. Сам проект имеет прототип на моем сайте (http://my-fantasy.ru/) и написан на PHP