Comments 46
Периодически выполняет апдейт игрового мира с течением времени (в нашем случае — 10 раз в секунду).
Тикрейт 10 раз в секунду — не слишком мало? Обычно в динамичных играх используется обновление не меньше 30 раз в секунду
Сначала я тоже сомневался, но потом сделал дополнительную интерполяцию на клиенте, и оказалось что этого вполне достаточно.
В таком случае, я не совсем понимаю, почему я не вижу адских лагов в игре.
Получается, клиент видит остальной мир в прошлом, отставая от сервера на 100мс? Т.е. ему приходит состояние мира, и он в течение следующих 100мс интерполирует текущее состояние до последнего полученного?
А клиент отправляет данные серверу также каждые 100мс или чаще?
P.S. Медуз стоит заменить на каких-нибудь акул, странно выглядит, когда милая медузка пожирает половину стаи...
100 мс — это не адские лаги, возьмите секундомер и посмотрите сколько длится 1/10 секунды — это очень быстро :) Видит ли клиент мир в прошлом — вопрос сложный, поскольку время на сервере идет точечными скачками, между которыми вселенная находится в замороженном состоянии :) Скорее нет, клиент видит мир таким, каким он был то время назад, которое потребовалось чтобы доставить TCP-пакет с сервера на клиент — это может быть гораздо быстрее, чем 100 мс. И Ping в углу экрана пусть вас не смущает — внутриигровой понг отправляется не сразу, а в конце ближайшего update. Поэтому он часто близок к dt -100 мс. Клиент отправляет данные серверу да, каждые 100 мс.
Ну в WoT сервер все обрабатывает на 15 FPS в секунду, если мне не изменяет память. И это не помешало игре стать киберспортивной дисциплиной.
Получается, клиент видит остальной мир в прошлом, отставая от сервера на 100мс?
Очень во многих играх так делают специально — все клиенты живут немного в «прошлом». А вот на сервере идет «предсказание» того как себя поведут игроки, и пост-коррекция.
Так получается замаскировать лаги.
игра будет без звука (чтобы не привлекать лишнего внимания у начальства на работе)
Так и просится название plankton.io
Что с нагрузкой, можете показать конфигурацию сервера и какое число игроков онлайн держит? Сколько игроков в одной комнате?
Тоже есть идеи сделать .io игру, планирую на NodeJS + uWebSockets (судя по бенчмарку, превосходит WebSocket). Однако для реализации нужно держать в одной комнате от 25 000 игроков, это сильно ресурсозатратно?
Тоже есть идеи сделать .io игру, планирую на NodeJS + uWebSockets (судя по бенчмарку, превосходит WebSocket). Однако для реализации нужно держать в одной комнате от 25 000 игроков, это сильно ресурсозатратно?
Intel® Xeon® E3 Quad-Core, 32 GB RAM, точные модели уже не помню. Лимит комнаты 150 игроков, но это вопрос пока открытый. Держит 4к онлайн, но это если боты запущены на том же сервере (а они тоже жрут). 25к онлайн? Смотря какой dt, смотря какие алгоритмы на апдейте. Это все будет равномерно размазано по ядрам?
> uWebSockets (судя по бенчмарку, превосходит WebSocket)
Не понял, почему вы сравниваете протокол как таковой с одной из его реализаций? В любом случае — транспорт это далеко не боттлнек.
> uWebSockets (судя по бенчмарку, превосходит WebSocket)
Не понял, почему вы сравниваете протокол как таковой с одной из его реализаций? В любом случае — транспорт это далеко не боттлнек.
Не понял, почему вы сравниваете протокол как таковой с одной из его реализаций?
Нет, имелось ввиду WebSocket не как технология, а чего-то подумал, что Вы используете (github.com/websockets).
Лимит комнаты 150 игроков, но это вопрос пока открытый.
Поставив к примеру 5 обновлений в сек. можно будет 300 чел держать в комнате без увеличения ресурсов? Не проводили тесты, сколько может максимум держать людей одна комната для комфортной игры?
а чего-то подумал, что Вы используете (github.com/websockets).
Не используем :)
Поставив к примеру 5 обновлений в сек. можно будет 300 чел держать в комнате без затраты на производительность?
С точностью до небольшой погрешности — да.
Не проводили тесты, сколько может максимум держать людей одна комната для комфортной игры?
Комфортность игры зависит от плотности игроков, а не их количества — чтобы было не слишком одиноко, но и не слишком тесно. С теми геометрическими размерами, которые сейчас, 250 игроков в комнате — нагрузка на сервер всего ничего, но играть уже не комфортно, потому что тесновато. Поэтому пока что поставили 150. Слишком большую комнату делать не стали, иначе от края до края плыть очень долго, и мало кто увидит, что у нас отдельно нарисовано красивое дно и водная поверхность :)
Прикольная игрушка :)
Рассматривалась ли идея с одной большой комнатой, динамически расширяемой для сохранения постоянной плотности игроков, и обработкой ситуации динамическим же пулом ядер/потоков по принципу телефонных сот с перекрытием зон?
Рассматривалась, но возникают различные вопросы относительно геймплея. Идея сделать бесшвовый мир с размазыванием его обработки по всем ядрам есть относительно одной из наших следующих игр, но это уже немного другая история :)
У такого мира чисто гипотетически должно получиться одно интересное свойство: если сгруппировать пользователей по мастерству (типа как в фэйсбучном ангрибёрдс френдс — по «лигам»), и спавнить соответственно, пользователи смогут сами регулировать «степень сложности», просто переплывая в другие области.
P.S. всётаки графически рыба — не самое удачное решение, поскольку переориентация делает анимацию дёрганой и ломает непрерывность восприятия.
(А в качестве решения можно былобы сделать разворачивание рыбы анимированным)
(А в качестве решения можно былобы сделать разворачивание рыбы анимированным)
У меня в лисе заметно лагают .io игры. Но в хроме на той же машине лагов нет. У вас нет проблем с фпс в .io играх?
Сильно лагает игровой персонаж. Дергается туда-сюда. Пинг нормальный, все остальные игроки двигаются плавно. Смотрю на десктопе.
Тоже пилю игрушку похожую на www.realmofthemadgod.com.
И у меня к Вам такой вопрос. На клиенте после получения события от контрола вы просто отсылаете его на сервер и изменения начнут отображаться только после получения сообщения об изменении состояния от сервера? Или сразу же применяете действие на клиенте одновременно с отправкой сообщения на сервер и потом как-то синхронизируйте клиентский стейт с актуальным серверным?
И у меня к Вам такой вопрос. На клиенте после получения события от контрола вы просто отсылаете его на сервер и изменения начнут отображаться только после получения сообщения об изменении состояния от сервера? Или сразу же применяете действие на клиенте одновременно с отправкой сообщения на сервер и потом как-то синхронизируйте клиентский стейт с актуальным серверным?
Можно я отвечу.
Конечно второе, а потом обманывать игрока интерполяцией исходя из дельт. Иначе получите пальцедроч в точку на экране и минусы в карму за неоптимизированную бету.
Конечно второе, а потом обманывать игрока интерполяцией исходя из дельт. Иначе получите пальцедроч в точку на экране и минусы в карму за неоптимизированную бету.
Тогда сразу же следующий вопрос: в случае коллизий позволительно ли подправлять стейт на сервере в разумных пределах, либо править стейт можно исключительно на клиенте? Не всегда можно обмануть игрока. Если расхождения в положении можно более-менее незаметно подправить в процессе движения, то, например, в случае рассинхронизации направления движения (вектор движения строго равен вектору взгляда) нельзя игрока незаметно повернуть, потому что если он будет нажимать вперед, а идти вперед и попутно разворачиваться, это игроку будет очень неприятно. И ждать момента когда игрок начнет крутиться тоже нельзя, потому что до поворота он может пройти достаточно много и, вследствие рассинхронизации, коллизия положения еще больше усугубится.
Править на сервере — сгать себе на ноги, ну или стрелять в них, что не суть. В некоторых редких ситуациях поможет, но я бы в данном случае так не делал.
Сделайте «ширину» интерполяции длинее максимальной задержки апдейта (100+100=200мс) — и вам даже не придется голову ломать, т.к. всё само исправится на следующем тике. Конечно если у вас не с каждым апдейтом прут разногласия.
Сделайте «ширину» интерполяции длинее максимальной задержки апдейта (100+100=200мс) — и вам даже не придется голову ломать, т.к. всё само исправится на следующем тике. Конечно если у вас не с каждым апдейтом прут разногласия.
Исправить на следующем тике или на следующих нескольких тиках — это вообще не проблема. Проблема сделать это незаметно для игрока. Пример: игрок стоит на месте и нажимает поворот направо. нажимает в течении 5 тиков и соответственно, клиент его сразу и поворачивает. Но 1 пакет до сервера не доходит, сервер рассчитывает поворот на 4 тика и в итоге при синхронизации клиент начнет крутить игрока в противоположную сторону. А это, на мой взгляд, полный фэйл. Или я чего-то недопонимаю? Как можно исправить такое разногласие незаметно для игрока?
Не привязывайтесь никогда к вещественным мерилам (метры, градусы, тики, ...). И не поворачиваются персы «на 4 тика». У объектов есть свои свойства, которые, при изменении, отправляются на сервер.
Например, у него есть:
Вот и оперируйте последними двумя на клиенте (цепляясь ко времени, прошедшему с последнего тика), отправляя первые три на сервер.
Это как пример реализации, с коленки так сказать. Да и движки наверное предоставляют матричные вычисления, что упростит математику.
И вообще я не игродел )))
Нарисуйте на бумажке схему, станет проще понять суть взаимодействия в целом, и интерполирования в частности ;)
Например, у него есть:
{ xPos, yPos, rotation, walkSpeed, rotationSpeed }
Вот и оперируйте последними двумя на клиенте (цепляясь ко времени, прошедшему с последнего тика), отправляя первые три на сервер.
Это как пример реализации, с коленки так сказать. Да и движки наверное предоставляют матричные вычисления, что упростит математику.
И вообще я не игродел )))
Нарисуйте на бумажке схему, станет проще понять суть взаимодействия в целом, и интерполирования в частности ;)
Серверу не отправляется ничего, кроме статусов нажатых клавиш. Поэтому и привязка к тикам: каждый тик сервер получает от клиента статусы клавиш и апдейтит по ним состояние. Клиент сам ничего не считает, он только отображает то, что к нему пришло от сервера (за исключением персонажа). Когда клиент получает от сервера одно состояние, а сам находится в другом — это коллизия. Способ исправления такой коллизии лежит на поверхности — просто подгоняем состояние на клиенте к тому, что приходит от сервера. Проблема тут в плавности такой подгонки, которую не всегда можно незаметно совершить.
Ок. Но я лично бы не стал нагружать сервер ничем, кроме хранения состояния игрового мира.
У нас разное мышление по архитектуре, на том и расстанемся без мордобоя ))
У нас разное мышление по архитектуре, на том и расстанемся без мордобоя ))
Вернее, клиент конечно-же считает все эти параметры, но исключительно для того, чтобы проинтерполировать кадры рендера в промежутке между тиками.
А это разве не ответ на ваш вопрос? Т.е. клиент отправляет «я поворачиваюсь», сервер принимает и поворачивает, в следующий кадр клиент всё-еще отправляет «я поворачиваюсь», сервер опять соглашается, и так далее. Но ведь сервер в то же время отправляет состояние клиенту, который и «подтягивает» состояние персов интерполяцией. Т.е. на клиенте состояние сервера уже есть, просто мы рисуем плавненько.
Тут проблема в том, что между клиентом и сервером целый интернет. Сколько будет идти каждый из пакетов — неизвестно. Игрок нажимает вперед, клиент рисует что персонаж сделал шаг вперед, пакет теряется (идет слишком долго), на сервере персонаж стоит там где стоял. Чтобы подтянуть клиентское состояние до серверного нужно сделать шаг назад. А это очень не круто.
Я потому и задал изначально вопрос, как это сделано в данной игре.
Потому что есть очень простой способ избежать вообще всех проблем — на клиенте заранее ни чего не делать. Отправил серверу сообщение, что нажата кнопка вперед, сервер это обработал, на следующий тик оправил уже обновленное состояние, клиент его получит и только теперь начал отображать.
Но тут другая проблема — латенси и как следствие менее отзывчивое управление.
И вот до тех пор пока я не пойму, как сделать приличную синхронизацию, я буду использовать этот тупой способ через увеличение латенси.
Но во многих играх эту проблему как-то решают. В том же ВоВе, например, управление отзывчивое и очевидно, что клиент ничего не ждет и сразу отрисовывает события от контролов.
Я потому и задал изначально вопрос, как это сделано в данной игре.
Потому что есть очень простой способ избежать вообще всех проблем — на клиенте заранее ни чего не делать. Отправил серверу сообщение, что нажата кнопка вперед, сервер это обработал, на следующий тик оправил уже обновленное состояние, клиент его получит и только теперь начал отображать.
Но тут другая проблема — латенси и как следствие менее отзывчивое управление.
И вот до тех пор пока я не пойму, как сделать приличную синхронизацию, я буду использовать этот тупой способ через увеличение латенси.
Но во многих играх эту проблему как-то решают. В том же ВоВе, например, управление отзывчивое и очевидно, что клиент ничего не ждет и сразу отрисовывает события от контролов.
Нет, на клиенте действия сразу же не применяются, клиент просто отправляет инпут на сервер, и продолжает смотреть кино, которое ему оттуда показывают.
Интуитивно не понял, что надо делать в игре. Пару раз меня сожрали, бросил, закрыл вкладку. Все же во время регистрации надо бы в трех картинках объяснить суть игры. И хотя бы первые секунд 20-30 сделать ее вэри изи. А то игрок сразу в кучу попадает и его сжирают.
Спасибо, именно такой статьи мне не хватало.
Сегодня впервые узнал про этот жанр игр, сыграл по очереди во все вами предложенные, ваша была последней.
Дольше всего залип в чашку петри, змейку почти сразу закрыл, в танки сыграл три боя, вашу — один бой.
Попытаюсь проанализировать почему так вышло, может вам будет этот отзыв полезен.
Мне кажется все дело в сложности игра. Змейка слишком легкая и скучная. Танки довольно сложные, и профи имеют очень сильное преимущество, я их не вижу, а они меня убивают случайным потоком из пуль. Чашка петри вышла идеальной, т.к. мелкие игроки не интересные крупным, т.е. можно легко от стариков убегать и попутно понимать суть игры. А ваша оказалась очень сложной, я вообще ни чего не понял, где еда, где враги. По моему там все враги и все меньше меня, и жрут меня моментально. Когда я нападаю на кого-то то жрут тоже меня. Как понять на кого стоит нападать я не понял. Ну и я не из тех кто готов давать второй шанс казуальным играм, т.е. либо любовь с первого взгляда, либо до свиданья.
Как мне кажется было бы прикольно сделать мануал — сплеш скрин, и более доходчиво на уровне графики объяснить какие игроки круче.
Но это лишь мнение полного новичка в ИО играх.
Дольше всего залип в чашку петри, змейку почти сразу закрыл, в танки сыграл три боя, вашу — один бой.
Попытаюсь проанализировать почему так вышло, может вам будет этот отзыв полезен.
Мне кажется все дело в сложности игра. Змейка слишком легкая и скучная. Танки довольно сложные, и профи имеют очень сильное преимущество, я их не вижу, а они меня убивают случайным потоком из пуль. Чашка петри вышла идеальной, т.к. мелкие игроки не интересные крупным, т.е. можно легко от стариков убегать и попутно понимать суть игры. А ваша оказалась очень сложной, я вообще ни чего не понял, где еда, где враги. По моему там все враги и все меньше меня, и жрут меня моментально. Когда я нападаю на кого-то то жрут тоже меня. Как понять на кого стоит нападать я не понял. Ну и я не из тех кто готов давать второй шанс казуальным играм, т.е. либо любовь с первого взгляда, либо до свиданья.
Как мне кажется было бы прикольно сделать мануал — сплеш скрин, и более доходчиво на уровне графики объяснить какие игроки круче.
Но это лишь мнение полного новичка в ИО играх.
Игра работает хорошо, но вот геймплей какой-то скучный, если честно. Думаю, введение командной игры с дополнительными «фичами» (например, две дружественных стаи могут ускоренно размножаться) и целями (типа CTF), плюс запоминание логина/ника вместе с историей, могут поправить положение.
Проверил в Microsoft Edge на Windows 10 Mobile (да, читал, что мобильные версии на очереди): почти все работает, за исключением скроллинга страницы на начальном экране (но если перевернуть в portrait, то все OK, можно войти), и управления — срабатывает, но с огромной задержкой. А так живенько все плавает, молодцы!
На фоне затягивающего slither (с плагином, который умеет зум, разумеется), все остальные выглядят довольно блекло. slither с недавних пор — любимая игра, сравнивать ее можно только с теплыми-ламповыми играми времен zx-specrum.
Без аппаратного WebGL — 3 FPS, лаги, зато глюки тестировать можно.
В общем, Меня хватило на неделю. Последние 3 дня играть невозможно. Разница между 1 и последующими местами просто катострафическая. Играя минут 30, набираешь уже огромную стаю, но она по сравнению с 1-м местом «ничто», в несколько десятков раз меньше. Набегает его просто невероятных размеров краб и съедает за секунду-полторы.
Если с этим что-то не сделать, мало кто будет играть. К примеру в agar, если долго кататься по карте, шар автоматически уменьшается. Может и Вам как-то стаю ТОПа убивать. В общем, думайте.
Если с этим что-то не сделать, мало кто будет играть. К примеру в agar, если долго кататься по карте, шар автоматически уменьшается. Может и Вам как-то стаю ТОПа убивать. В общем, думайте.
Подтверждение слов
Sign up to leave a comment.
Делаем очередную .io-игру