Комментарии 75
Что-то не так у вас с физикой — инерции не хватает.
Не надо путать казуалов и даунов.
Скорее поленились разбираться или ресурсов нет.
Отскоки с одной скоростью и отсутствием контроля — ну сразу обламывает кайф игры.
starblast.io вполе себе с физикой.
А за статью спасибо.
Ну как в середине марта, версия под мак "Version 56.0.2924.87" уже не открывает.
Я что-то пропустил, но с каких пор хром не разрешает зайти на сайт даже если мне очень хочется, забив на сертификат? Раньше было под «advanced»
Можете подсказать, что не так случится с letsencrypt? Использую его везде, первый раз слышу, что что-то с марта поменяется.
Используем законы физики: тело, на которое не действует никакая сила, продолжает движение прямолинейно. F = ma, масса корабля либо фиксированная, либо уменьшается (если кто-то в игре реализует топливо, либо меняется, если кто-то в игре реализует релятивистскую физику), в простейшем случае — не меняется. В силу того, что даже ускорение нельзя менять мгновенно, мы просто передаём с клиента его текущее значение ускорения, задержки между передачами ускорения соответствуют «инерции педали».
Раз в N времени пользователь может поменять значение вектора ускорения (или значение скаляров ускорения и угла поворота рулей). Дальше чистая физика.
Ошибки будут накапливаться. (Я пробовал так — правда будут)
Да, я забыл сказать, что в ответ сервер присылает не «реакцию» на нажатие педали, а timestamps (в общем frame of reference) моментов изменения ускорения всех объектов. Имея трансляцию из frame of reference в локальное время, клиент может полностью воспроизвести изменение скоростей и просчитать траекторию. Т.к. ошибки округления накапливаются, иногда сервер присылает уточнённые абсолютные координаты объектов.
Если какой-то клиент получает информацию с задержкой, то он просто пересчитывает полёт объектов. Для эргономики внешнего вида я бы просто использовал в клиенте две координаты: синхронную с сервером и получившуюся из-за «продолжения движения» из-за лага. Дальше у нас простая задача: есть плавная идеальная тракетория и плавная ошибочная траектория, не меняя гладкости функции обеспечить переход ошибочной тракетории в идеальную. Вероятнее всего, для наблюдателя это будет выглядеть как «подруливание» чужих кораблей, тем более частое, чем хуже канал связи.
Задача перевода одной гладкой функции в другую реализуется очень просто — используем экстраполяцию идеальной тракетории на следующую точку, а потом интерполируем точки ошибочной тракетории плюс одна (две?) точки, экстраполированные из идеальной траектории. Дальше по заданной тракетории мы можем посчитать производную третьего порядка в нужных нам точках для определения изменения ускорения (что соответствует визуальному «подруливанию») корабля.
Ключевым моментом является сохранение плавности — то есть отсутствие разрывов в третьей производной. По бедности — во второй, хотя будет ощущение неестественных рывков.
Да, есть 2 проблемы на первый взгляд:
1) рассинхронизация таки будет иногда, но можно, скажем, делать легкую синхронизацию постоянно (к примеру, хешировать состояние, и сравнивать хеши), и если есть рассинхрон, тогда заказывать полный снепшот с сервера
2) читеры. Но, я думаю, и так будущее положение корабля может дать преимущество
Есть еще тема. Каждое действие игрока сразу отправляется на сервер, где попадает в общий лог действий игроков с временными метками. Каждый клиент получает такой же лог, как и все остальные. Имея ТТХ кораблей и лог, все клиенты будут отрисовывать игровое поле абсолютно идентично и без рассинхронизаций в принципе. Даже события типа «ранил», «убил» будут генерироваться самостоятельно и идентично на всех клиентах. Минус — если игрок двинул мышью, то его локальная копия игры отреагирует только, когда получит ответ от сервера с временной меткой
Если у клиента будет пропадание связи, то до появления связи события будут разворачиваться, как будто никто из игроков не двигает мышью и не жмет кнопок, а после появления связи вновь не совпадут хеши, и клиент просто запросит полный снепшот
Насчет физики, мой вариант сильно приятнее: space.playcode.io
Кстати я тоже на Go пишу и интересна тема agar.io like игр.
Напишите мне (в профиле есть контакты).
Да, приятнее управление, чем у ТС, но что будет при взаимодействии с массой других игроков.
И использованный на бекенде язык тоже )
Интересно было бы реализовать p2p коммуникацию. Допустим каждый посылает каждому свои координаты на следующую долю секунды. Каждый узел рассчитывает всю физику и рассылает результат пирам. Если показания расходятся (читер подделывает показания), то сеть автоматически распадается на непротиворечивые подсети. Таким образом читер будет играть сам с собой, а нормальные игроки друг с другом. Соответственно кластеров может быть сколько угодно, совершенно не нагружая сервер.
Можно даже не результат рассылать, а просто хеш от всех рассчитанных координат, векторов и.т.д.
Этакий блокчейн для игры.
Вот это реально красивая идея. Надеюсь уже кто-то что-то сделал подобное.
An error occurred running the Unity content on this page. See your browser's JavaScript console for more info. The error was:
NS_ERROR_NOT_CONNECTED:
В консоли:
An abnormal situation has occurred: the PlayerLoop internal function has been called recursively. Please contact Customer Support with a sample project so that we can reproduce the problem and troubleshoot it.
(Filename: Line: 56)
Попробую собрать клиент последней версией юнити. Возможно, поможет.
WebGL штука прожорливая
Можно физически уменьшить окно браузера — это помогает видеокарте.
Можно зайти в настройки и повыключать все что можно (фон, вращение, качество моделей)
Но играть на таких настройках грустно.
Devil May Cry 4, Need for Speed: Most Wanted… работает без тормозов, а простенькую леталку на минимальных параметрах не тянет GeForce 630 и Athlon 64 3200+ 2.1Гц… вот он прогресс 2004 — 2017 и хвалебные песни «быстрой разработке».
P.S. при уменьшении окна браузера действительно +5 fps
Кстати, если у вас комп с двумя видеокартами, то браузер всегда использует ту, что послабее.
Сам js на котором написана логика клиента — медленный и к тому ж однопоточный. Первый шаг в сторону его ускорения — asm.js Именно его использует Unity и, соответственно, эта игра.
Дальше ждем webassembly а также поддержку многопоточности.
Ну и работает пока нормально только webgl 1.0 (который обертка над opengl 2).
Кроме того, реализация поддержки его браузерами пока не идеальна и улучшается почти с каждой версией.
У Вас закончились все жизни!
Одна жизнь восстановится через 28м.26c.
Либо, Вы можете купить жизни или дроида: (далее контент донат-магазина)
Вы, что, серьезно???
Я смотрю, у вас маркетологи ушли не на много дальше программистов ))
Ограничение игры по времени, продлеваемое за валюту — суть подписка.
Вы, естественно, считаете, что на вашу игру люди будут с удовольствием подписываться плюс арендовать (вы что, серьезно???) явно выраженные игровые преимущества, но меня не покидает чувство, что ваша бизнес-модель потерпит фиаско.
Почти все статьи на хабре про "как мы писали сетевую игру" проходит через одни и те же стадии :)
Почему вы не увидели в моей статье описание протокола, мне непонятно. Вот же оно:
- клиент отсылает на сервер положение мыши раз в 120мс
- получив эту управляющую команду, сервер пересчитывает координаты корабля
- асинхронно, на сервере работает нитка, которая ровно один раз в те же 120мс отправляет на клиенты координаты, в которых корабль должен быть к концу следующих 120мс
- получив координаты, клиенты делают простой расчет: если сейчас кораблик находится в точке А, то с какой скоростью надо передвигать его в течение следующих 120мс, чтобы он оказался в пришедшей с сервера точке B
На сегодня 111 человек сохранили статью в избранное, что говорит о некоторой её полезности.
Насчет ссылки — тут дилемма. Поставь — вы упрекнете в рекламе. Не поставь — спросите: «Где пруфы, Билли?»
Особенности протокола в IO-играх