Я сам играю в MMO по выходным и часто задаюсь вопросом, как эти огромные миры позволяют стольким игрокам делиться опытом, который выглядит почти так, как будто мы играем рядом друг с другом.

Конечно, всегда были примеры того, как все могло легко пойти не так, как печально известная ошибка «Сервер недоступен» в SWTOR сразу после того, как вы попали в бой с боссом, но чаще всего все идет гладко.

Недавно я участвовал в обсуждении того, как будущий игровой сервер может работать для нас в Greentube, и это снова заставило меня задуматься о том, как эти MMO делают это. Я предпочитаю C# в повседневной жизни, поэтому я начал искать фреймворки, которые позволили бы нам построить масштабируемую систему, а также упростить ее.

Я знаю, это выглядит слишком много, чтобы просить. И это привело меня к акторным системам.

Акторные системы не новы — в Erlang они есть всегда, и это проверенный подход к телекоммуникационным системам. Чего я не знал в то время, так это того, что это также очень хорошо подходило для создания (заметьте) сервисов с отслеживанием состояния, которые могли бы обслуживать миллионы пользователей.
Сохранение состояния, говорите? В наши дни это большое «нет-нет», поскольку все пытаются создавать микросервисы без сохранения состояния, верно? Без сохранения состояния это хорошо, так как позволяет нам намного проще рассуждать о параллелизме, но парадигма доставки данных сбивает вас с толку, когда вы пытаетесь масштабироваться.

Актеры построены как объекты состояния и поведения, что способствует неизменности, что также помогает при рассуждениях о параллелизме. Кроме того, их способ общения основан на передаче сообщений, что хорошо масштабируется. Все это заставило меня задуматься о модели программирования актеров. Однако, если вы не являетесь экспертом по распределенным системам (а я им не являюсь), масштабируемость будет только в теории, и все это плохо кончится.

Есть хороший .NET-фреймворк, поддерживающий акторную модель, под названием Akka.net, но он кажется слишком низкоуровневым. У него отличная документация, фантастическая производительность, но я чувствую, что концепции иерархии ядра ошибок, контроля и управления блокировкой могут сбить с толку некоторых новичков на вечеринке.

Поскольку поисковые системы — наши друзья, и они действительно умны в наши дни (смотря на вас, Google), я наткнулся на структуру прямо из исследования Microsoft, которая уже использовалась в одной из известных игр для XBox для поддержки точного масштаба MMO I. был очарован и, конечно же, написан на .NET.

Он называется Орлеан, и в нем есть так называемые виртуальные актеры.

Откуда у нас теперь эти виртуальные, и какая разница, спросите вы? Есть хорошая статья здесь, которая дает более подробную информацию об этом.

Достаточно сказать, что ключевое слово действительно виртуальные — эти акторы не обрабатываются разработчиками напрямую, потому что они всегда существуют и обрабатываются самой структурой акторов. Это поднимает абстракцию актора до уровня ресурса, уже имеющегося в распоряжении разработчика, избавляя его от необходимости должным образом завершить, перезапустить или создать его экземпляр.

Итак, я приступил к изучению Орлеана и применению его к варианту использования, который мне понадобится в будущем — игровому серверу для массовых игр онлайн-казино.

Звучит захватывающе, верно?

Быть в курсе…