Comments 11
Интересно конечно.
Но доклад выглядит как-то странно.
На все вопросы ответ «Мы просто взяли Orleans и он все делает сам».
Но доклад выглядит как-то странно.
На все вопросы ответ «Мы просто взяли Orleans и он все делает сам».
Немного не понятно всё это.
Если хочется распределенную in-memory базу данных с персистентным бэкендом, можно взять что-то типа Apache Ignite.
Если нужны распределенные вычисления с использованием модели Акторов, есть Akka.
Зачем эти два продукта смешивать — я так, к сожалению, и не понял.
Если хочется распределенную in-memory базу данных с персистентным бэкендом, можно взять что-то типа Apache Ignite.
Если нужны распределенные вычисления с использованием модели Акторов, есть Akka.
Зачем эти два продукта смешивать — я так, к сожалению, и не понял.
Прекрасный пример победы архитектуры над разумом. Говорю исключительно с субъективной точки зрения игрока, гонявшего ещё в Quake 1. Так вот, ни в нём, ни в Quake 3 в 2000-м году не было таких рассинхронизаций, как в QC. Сетевой стек просто отвратителен (я уже не говорю о проблемах на клиенте), а игра в открытом доступе уже почти два года.
Чтобы не быть голословным, вот пример с прошедшего неделю назад чемпионата. Для тех, кто ничего не понял, поясню: игроки сидели друг напротив друга (т.е. «пинг» как бы не при чём) и игрок rapha прятался за колонной от игрока coolerz, и был убеждён, что он спрятался за колонной и не находится на линии прямой видимости для автоматного огня, однако урон по нему проходил, в результате чего rapha отдал очко и отреагировал вот так (вид того же момента из глаз cooler).
Как разработчик, я с большим удовольствием читаю о современных технологиях в геймдеве. Как игрок, я совершенно не понимаю, почему игра в 2018 объективно и субъективно намного хуже по качеству игры из той же серии от 2000-го года. Лучше стали две вещи: графика и маркетинг. [sarcasm]Так что я с удовольствием бы послушал доклад о том, как поддерживать репутацию «esports ready» бэкенда при наличии ракет, наносящих 0 урона при прямом попадании[/sarcasm]
Чтобы не быть голословным, вот пример с прошедшего неделю назад чемпионата. Для тех, кто ничего не понял, поясню: игроки сидели друг напротив друга (т.е. «пинг» как бы не при чём) и игрок rapha прятался за колонной от игрока coolerz, и был убеждён, что он спрятался за колонной и не находится на линии прямой видимости для автоматного огня, однако урон по нему проходил, в результате чего rapha отдал очко и отреагировал вот так (вид того же момента из глаз cooler).
Как разработчик, я с большим удовольствием читаю о современных технологиях в геймдеве. Как игрок, я совершенно не понимаю, почему игра в 2018 объективно и субъективно намного хуже по качеству игры из той же серии от 2000-го года. Лучше стали две вещи: графика и маркетинг. [sarcasm]Так что я с удовольствием бы послушал доклад о том, как поддерживать репутацию «esports ready» бэкенда при наличии ракет, наносящих 0 урона при прямом попадании[/sarcasm]
Есть нюанс — игра делается не совсем на классических движках id Tech и может статься вся сетевая часть тоже от движка сейберов. У дума и прочих игр на 5 и 6 айдитехе вроде бы проблем с сетью нет?
Да, там лютый кадавр id Tech 5 + Saber 3D (proof). В итоге, в угоду красивой на бумаге архитектуре бэкенда, имеем игру, которая ощущается и играется хуже своей предшественницы из 2000-го года. Зато стек технологий современный.
Но погодите, ведь речь в докладе идёт именно о backend инфраструктуре (в значении сервисов — matchmaking, «валюта» игрока, рейтинг игрока, что угодно ещё), а не самой игры (если я ошибаюсь — поправьте меня, времени сейчас посмотреть доклад нет, но прочитал статью довольно внимательно). Да и сложно представить, чтобы на акторах кто-то разрабатывал шутер — это не имеет никакого смысла (load balancing в рамках игрового сервера не нужен, отказоустойчивость тоже; это игровой сессионный сервер и все к нему коннектятся и спокойно играют). Традиционные технологии прекрасно справляются — ещё со времён сетевой модели Quake 3 описанной Кармаком ничего нового не изобрели (всё те же механизмы client lag prediction, lag reconciliation, server state rewind, etc). К тому же, при разработке реальных игровых серверов для такого рода игр (fast-paced FPS/TPS), очень остро стоит вопрос о производительности (==цене) серверов. А оверхэд с акторами будет и ещё какой — нарушается cache locality, невозможно производить многие оптимизации, добавляются всевозможные абстракции…
А вот почему всё не хорошо ощущается в самой игре — хороший вопрос. Неужели действительно не используют сетевую часть idTech, или используют, но породили какие-то баги в ней?
Кстати, с удовольствием иногда смотрю этот канал www.youtube.com/user/xFPxAUTh0r1ty/videos автор только и занимается, что анализирует network performance ПК-игр, в том числе есть пара видео по Quake Champions.
А вот почему всё не хорошо ощущается в самой игре — хороший вопрос. Неужели действительно не используют сетевую часть idTech, или используют, но породили какие-то баги в ней?
Кстати, с удовольствием иногда смотрю этот канал www.youtube.com/user/xFPxAUTh0r1ty/videos автор только и занимается, что анализирует network performance ПК-игр, в том числе есть пара видео по Quake Champions.
Из того, что я видел в анализаторе трафика, игровой клиент коннектится в Азуровские облака. Сетевая модель отличается кардинально от «кармаковской» и причина была озвучена: «Никаких dedicated серверов в QC из соображений безопасности».
Забота о безопасности вылилась в наличие читеров уже на стадии закрытого бетатеста (можно найти пруфы в ютубе — народ не стесняясь играет с aimbot'ами). А субъективно архитектура ощущается очень микросервисно, т.к. упасть может что-то одно, оставив всех игроков в игре, пока они не отвалятся по таймауту или другим исключениям.
Забота о безопасности вылилась в наличие читеров уже на стадии закрытого бетатеста (можно найти пруфы в ютубе — народ не стесняясь играет с aimbot'ами). А субъективно архитектура ощущается очень микросервисно, т.к. упасть может что-то одно, оставив всех игроков в игре, пока они не отвалятся по таймауту или другим исключениям.
Я не разработчик QC, но можно сказать эксперт в этой области, и то что выпишите у меня не вяжется в голове. Исходя из того что вы написали, я вижу это так:
1. «Никаких dedicated серверов» означает не то, что теперь всё крутится в мифическом облаке на акторах, а то, что dedicated сервера не раздаются всем кому попало в виде exe-файла (что само по себе действительно представляет серьёзную уязвимость — их можно реверс инженерить). Т.е. это совершенно другая модель дистрибьюции игры (когда разработчики сами деплоят сервера, продают доступ к игре по подписке или free-to-play), но это не значит, что как-то изменился сам dedicated сервер игры — это тот же executable файл, который деплоится на виртуальную машину (в Azure) и запускается, и к нему игроков пропускает matchmaking сервис.
Сейчас таким образом организовано очень много игр (тот же Fortnite например или Overwatch) — matchmaking собирает игроков и ищет для них рабочий сервер, если такового нет деплоится инстанс на уже доступном железе или арендуется виртуальная машина.
К слову, «Никаких dedicated серверов» всё-таки скорее бизнес-решение (иначе нужно менять модель дистрибьюции игры на классическую — когда игроки покупают клиент и могут сами деплоить сервер где хотят, но сейчас мало кто так делает — увы, рынок изменился). Может быть и разрешат запускать dedicated сервера — но за денежку и в рамках их облачной инфраструктуры.
2. Ещё раз повторюсь, что нет смысла делать игровые сервера на акторах для такой игры. Это подход построения именно backend архитектур, когда производительностью можно (и нужно) пожертвовать в обмен на fail tolerance, load balancing и т.д… Т.е. ожидать, что dedicated сервер игры написан на Orleans это примерно как ожидать, что в игре для всего используется SQL и хранимые процедуры, или какая-нибудь причудливая технология из сферы энтерпрайз. Akka/Orleans традиционно используются в энтерпрайз бэкенде где нужны вышеозвученные фишки. А в рамках fast-paced игры это просто… как бы сказать, «так игры не пишутся». Там и GC pressure будет космический, т.к. всё это на .NET крутится, что в принципе неприемлимо.
А главное, это не имеет смысла, ведь уже есть idTech (огромная выполненная работа), и клиент игры должен прекрасно дружить с сервером за счёт общего стека idTech (общего кода перемещения персонажа и основных игровых систем которые должны симулироваться на клиенте для lag prediction). Всё это реально выбросить и переписывать на чём угодно заново — очень-очень плохое бизнес-решение.
А вот использовать для бэкенда Akka/Orleans + Azure это прекрасное бизнес-решение (как и понятно из этой презентации «мы взяли Orleans и он всё делает за нас»).
3. Aimbot'ы это чисто клиентская вещь и никоим образом не касается серверной архитектуры. Да, это можно пытаться детектить на сервере разными алгоритмами, но всё равно в индустрии это чаще решается средствами по типу V.A.C. и его аналогами (мониторинг на стороне клиента).
4. Падения микросервисов ведущие к крашу сервера — маловероятно (игроки уже подключились и спокойно играют на сервере, пока не закончат играть сервер в принципе может не общаться ни с какими микросервисами), а вот падение самого сервера (и отваливание игроков по таймауту) вполне ожидаемая ситуация для онлайн-шутеров в раннем доступе. Но это должно исправляться в рамках патчей.
Опять же, я не разработчик этой игры, но это просто common sense для любого эксперта в индустрии. В эту же пользу говорит и видео-обзор от ютубера о канале которого я писал выше youtu.be/WITA9DpejSg?t=902 игра подключается к конкретному dedicated серверу и обменивается данными именно с ним напрямую в течение всей игровой сессии по протоколу UDP (анализ по Wireshark). Никаких проблем (кроме производительности) автор не заметил, все алгоритмы предикшена и компенсации лага присутствуют как и в остальных шутерах (что не исключает наличия багов о которых вы писали выше). А значит я возвращаюсь к тому же выводу — используется idTech или что-то явно аналогичное, а вот почему всё не хорошо ощущается в самой игре — хороший вопрос. Скорее всего — виноваты баги. Код современных игр очень наворочен в сравнении с тем же оригинальным Q3A, и иногда программисты могут допустить незначительную ошибку в коде приводящую к серьёзным проблемам.
1. «Никаких dedicated серверов» означает не то, что теперь всё крутится в мифическом облаке на акторах, а то, что dedicated сервера не раздаются всем кому попало в виде exe-файла (что само по себе действительно представляет серьёзную уязвимость — их можно реверс инженерить). Т.е. это совершенно другая модель дистрибьюции игры (когда разработчики сами деплоят сервера, продают доступ к игре по подписке или free-to-play), но это не значит, что как-то изменился сам dedicated сервер игры — это тот же executable файл, который деплоится на виртуальную машину (в Azure) и запускается, и к нему игроков пропускает matchmaking сервис.
Сейчас таким образом организовано очень много игр (тот же Fortnite например или Overwatch) — matchmaking собирает игроков и ищет для них рабочий сервер, если такового нет деплоится инстанс на уже доступном железе или арендуется виртуальная машина.
К слову, «Никаких dedicated серверов» всё-таки скорее бизнес-решение (иначе нужно менять модель дистрибьюции игры на классическую — когда игроки покупают клиент и могут сами деплоить сервер где хотят, но сейчас мало кто так делает — увы, рынок изменился). Может быть и разрешат запускать dedicated сервера — но за денежку и в рамках их облачной инфраструктуры.
2. Ещё раз повторюсь, что нет смысла делать игровые сервера на акторах для такой игры. Это подход построения именно backend архитектур, когда производительностью можно (и нужно) пожертвовать в обмен на fail tolerance, load balancing и т.д… Т.е. ожидать, что dedicated сервер игры написан на Orleans это примерно как ожидать, что в игре для всего используется SQL и хранимые процедуры, или какая-нибудь причудливая технология из сферы энтерпрайз. Akka/Orleans традиционно используются в энтерпрайз бэкенде где нужны вышеозвученные фишки. А в рамках fast-paced игры это просто… как бы сказать, «так игры не пишутся». Там и GC pressure будет космический, т.к. всё это на .NET крутится, что в принципе неприемлимо.
А главное, это не имеет смысла, ведь уже есть idTech (огромная выполненная работа), и клиент игры должен прекрасно дружить с сервером за счёт общего стека idTech (общего кода перемещения персонажа и основных игровых систем которые должны симулироваться на клиенте для lag prediction). Всё это реально выбросить и переписывать на чём угодно заново — очень-очень плохое бизнес-решение.
А вот использовать для бэкенда Akka/Orleans + Azure это прекрасное бизнес-решение (как и понятно из этой презентации «мы взяли Orleans и он всё делает за нас»).
3. Aimbot'ы это чисто клиентская вещь и никоим образом не касается серверной архитектуры. Да, это можно пытаться детектить на сервере разными алгоритмами, но всё равно в индустрии это чаще решается средствами по типу V.A.C. и его аналогами (мониторинг на стороне клиента).
4. Падения микросервисов ведущие к крашу сервера — маловероятно (игроки уже подключились и спокойно играют на сервере, пока не закончат играть сервер в принципе может не общаться ни с какими микросервисами), а вот падение самого сервера (и отваливание игроков по таймауту) вполне ожидаемая ситуация для онлайн-шутеров в раннем доступе. Но это должно исправляться в рамках патчей.
Опять же, я не разработчик этой игры, но это просто common sense для любого эксперта в индустрии. В эту же пользу говорит и видео-обзор от ютубера о канале которого я писал выше youtu.be/WITA9DpejSg?t=902 игра подключается к конкретному dedicated серверу и обменивается данными именно с ним напрямую в течение всей игровой сессии по протоколу UDP (анализ по Wireshark). Никаких проблем (кроме производительности) автор не заметил, все алгоритмы предикшена и компенсации лага присутствуют как и в остальных шутерах (что не исключает наличия багов о которых вы писали выше). А значит я возвращаюсь к тому же выводу — используется idTech или что-то явно аналогичное, а вот почему всё не хорошо ощущается в самой игре — хороший вопрос. Скорее всего — виноваты баги. Код современных игр очень наворочен в сравнении с тем же оригинальным Q3A, и иногда программисты могут допустить незначительную ошибку в коде приводящую к серьёзным проблемам.
Сам движок — кадавр из idTech 5 + Saber 3D [link]. Причём последнего в итоговом результате гораздо больше. idTech очень узнаваемый, если его открывать PE Explorer'ом — я ковырялся в исполняемых файлах и библиотеках, пока их не обфусцировали просто в надежде найти привычные аргументы командной строки, чтобы хоть немного оптимизировать этого монстра. А про «dedicated сервера» я имел в виду именно невозможность хостить их игрокам самостоятельно, как это делается в Quake Live, серверный код вынесен в ту же степь, куда и QuakeC с возможностью писать свои моды.
1. Немного изучил вопрос об акторах, спасибо за эту наводку. Теперь понятно, что бэкенд из доклада не является серверной частью самой игры. Но тем удивительнее, зачем нужен такой предмет для гордости. Микротранзакций в игре немного, сохраняемых данных тоже, аналитика по ним если и ведётся, то на игроков это никак не распространяется — как ММ был отвратителен, так и остался. В том же Quake Live, пока его не прибрала к рукам Bethesda, генерируемые игроками данные использовались и были в открытую доступны по API.
2. В сервере Aegis (для игры Ragnarok Online) использовались хранимые процедуры :) а сам сервер крайне упорото взаимодействовал с MS SQL. Один из его билдов спёрли и сообщество написало эмулятор eAthena, который в глобальной ретроспективе работал и кастомизировался лучше и быстрее официальных серверов (привет, Gravity).
3. Да, aimbot работает на клиенте. И тем смешнее выглядят официальные заверения, что peer-to-peer, lan и оффлайн вариантов поиграть не будет «из соображений безопасности, чтобы не было aimbot'ов» (пруф на форуме беседки, но ссылку, увы, не сохранил). Боты есть на любой вкус — отрисовка, обрисовка, стрельба, целеуказание на карте. При примерно 1000 живых игроков довольно сложно найти «чистый» паблик.
Всё, я завязываю возмущаться о качестве игры на хабре, хорошо, хоть статья уже старая и не нахватаю лещей за оффтопик. Ужасно удручает факт, что игра ±2017 года ощущается намного хуже, чем её предшественница родом из 2000-го. Но, увы, это глобальная тенденция — новый Fallout от той же Bethesda и череда откровенной лажи и вымогательства от Activision и Ко (blizzard, bungie) тому наглядное подтверждение.
1. Немного изучил вопрос об акторах, спасибо за эту наводку. Теперь понятно, что бэкенд из доклада не является серверной частью самой игры. Но тем удивительнее, зачем нужен такой предмет для гордости. Микротранзакций в игре немного, сохраняемых данных тоже, аналитика по ним если и ведётся, то на игроков это никак не распространяется — как ММ был отвратителен, так и остался. В том же Quake Live, пока его не прибрала к рукам Bethesda, генерируемые игроками данные использовались и были в открытую доступны по API.
2. В сервере Aegis (для игры Ragnarok Online) использовались хранимые процедуры :) а сам сервер крайне упорото взаимодействовал с MS SQL. Один из его билдов спёрли и сообщество написало эмулятор eAthena, который в глобальной ретроспективе работал и кастомизировался лучше и быстрее официальных серверов (привет, Gravity).
3. Да, aimbot работает на клиенте. И тем смешнее выглядят официальные заверения, что peer-to-peer, lan и оффлайн вариантов поиграть не будет «из соображений безопасности, чтобы не было aimbot'ов» (пруф на форуме беседки, но ссылку, увы, не сохранил). Боты есть на любой вкус — отрисовка, обрисовка, стрельба, целеуказание на карте. При примерно 1000 живых игроков довольно сложно найти «чистый» паблик.
Всё, я завязываю возмущаться о качестве игры на хабре, хорошо, хоть статья уже старая и не нахватаю лещей за оффтопик. Ужасно удручает факт, что игра ±2017 года ощущается намного хуже, чем её предшественница родом из 2000-го. Но, увы, это глобальная тенденция — новый Fallout от той же Bethesda и череда откровенной лажи и вымогательства от Activision и Ко (blizzard, bungie) тому наглядное подтверждение.
Шёл N-й год разработки, любители крутых бэкендов из Saber так и не смогли научиться сохранять клиентские настройки игры так, чтобы каждый выход/вход не обнулял их.
Sign up to leave a comment.
Практика использования модели акторов в бэкэнд-платформе игры Quake Champions