Можно ли создать Игру Мечты, используя SpatialOS?

— Dwarf Fortress .28~.34

Прочитав комментарий о сомнениях в возможностях SpatialOS, у меня внезапно заболело. Нет, не пониже спины, а в желудке, горле и сердце: за горло ухватилась Жаба, желудок свели давние мысли о прибыли, а сердцу просто стало больно за проекты, лежащие в столе, которые, слава богу, реализовывают другие люди.

Данная заметка — взгляд криворукого практика с ожиданием от существующих технологий. Которые дают надежду на что-то эпичное.

Чтобы описать потенциал SpatialOS и иже с ним, каким его вижу я, опишу свою давнюю разработку, начавшуюся ещё в 2002-м, но до сих пор не воплощённую ни в чём, кроме одного движка сайта, полурабочего прототипа, набора бумажных набросков и прототипа обучающей настольной игры.

Мечта

— «Машина видящая грёзы», Сатоши Кон, Хирасава Сусуму(?).

Сама по себе разработка довольно прозаична — ИИ, как это модно сейчас называть, нейросеть, с некоторыми… особенностями реализации. Его задача — работать, балансируя между проблемами. Вернее, наоборот: балансируя между проблемами, он будет функционировать.

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

Но для простого обучения ИИ нужно окружение, а для социального обучения — взаимодействие. С этой целью было задумано создать «игровую площадку» — небольшой мирок, где я буду лишь участником, а не единственным работником (и так сил мало).

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

В целом, конструкция выглядела так:

Сервер:
DOS Box0.71, Qb 4.5

Соответственно, ограничения: крайне низкая (как для цели) производительность, 10000 элементов/массив, 32кб/строка + асоциальность.

ИИ:
алгоритм сравнения строк и «удовольствия/боли» от оных.
+ мягкая защита от ловушки Грагарциана (бесконечное повторение «лучшего» действия).
Всё.

Игра:
DIM MAP() — Map — состояние карты
DIM MQ() — MapQuerry — запросы к элементам карты и сигналы обратно.
DIM BOT() — Bots — состояние ботов
DIM BQ() — Bot Querry — запросы к ботам извне и сигналы обратно.

Массивы MQ и BQ являлись необходимым злом, поскольку было ясно, что на одну точку могло быть сразу несколько действий, а значит, и конфликт интересов, который было бы проще решить между ходами, чем разбираться на лету.

Тело:
Тело задумано как некая сущность, которая позволяет боту чувствовать и анализировать. По факту — это просто набор строк, каждая из которых получает свои данные, а затем скармливает их в сторону ИИ (по правилам установленным для тела).

Алгоритмы:
Для упрощения жизни себе все алгоритмы были скинуты в два блока: базовые (для обмена данными и типовых работ) и сложные (могут вызывать базовые, но не равных). Эта сложность была нужна, чтобы не давать себе соблазна сделать циклы, которые будут долго работать «вешая» систему в целом.

В итоге пришлось разрабатывать систему, которая смогла бы обеспечить эту «SMMO» (сингл-ММО) на том, что было:

1. Каждый ход выполняется только один-несколько проходов по состоянию бота. Если бот не успел принять решение — тупит дальше.
2. Оптимизация: все службы сервера (кроме Главного Цикла) становятся такими же ботами. То есть вывод изображения на экран — тоже работа отдельного бота.
3. Клиент — это мини-сервер, который доверяет серверу в плане информации о себе и мире.
4. Любой клиент может принять на себя часть работы сервера и, в целом, наоборот.


— SAO — игра, где всё управляется искусственным интеллектом «Кардинал».

В этот момент уже можно понять, почему SAO для меня не просто ещё одна анимешка про виртуальный мир. Я думаю, что знаю, как это должно быть собрано, чтобы воспроизвести все баги той игры, хе-хе.

Как сделать большой мир

— Stronghold — мир, в котором хочется побыть...

А теперь — к современным проблемам: как же сделать так, чтобы мир смог держать миллионы игроков и не подавиться? А если НПЦ по нагрузке ничуть не ниже?

Когда в 2000-м у меня появился 80486-й мне наконец-то удалось поиграть в WarCraft II. До того я рубился лишь в Civilization, SimСity и жалел, что нет возможности совместить те две игры. Теперь же появился другой вопрос: а почему нельзя поиграть в него как в РПГ?

Затем появился Stronghold и мода на альтернативные рабочие столы. Мысль была проста: а можно ли прогуляться по папкам компьютера, если в каждую положить маленькую сохранёнку? Ведь это же столько новых, разнообразных карт, если создавать их на основе содержимого папки!

Но если можно прогуляться по своим — почему бы не заглянуть по локалке на соседний комп? Эдакое «посольство», где каждый может проявить себя, рассказать о себе — и довольно быстро настраиваемое. Хотя, а можно ли (почему нет? Скорости-то хватает!) заглянуть по диалапу к другу за 10 км?

И тут повис неловкий вопрос: а почему бы тогда не путешествовать по миру, переходя с одного сервера на другой? Каждая точка трассировки — такой маленький сервер, перекрёсток миров.

Но что делать с читерами, разными наборами экипировки (азиатский сервер не захочет иметь европейских вещей, например)? Только разбивать объекты на локальные сеты, миры на доверенные/недоверенные, сравнивать время последнего логина, вводить сервера-таможни (думается, что такие возникнут сами).

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

Решение

— Просто красивая серверная.

Так как же сделать так, чтобы один игровой мир прожевал миллион игроков и не подавился?

Итак, напомню: есть сервер, в котором каждое действие выполняется один раз за такт. Нет, можно выделить больше процессорного времени/тактов (привет, Трон) но сути это сильно не меняет. Есть клиенты (которые те же сервера, только без мира) и боты, которые — суть те же клиенты, но могут жить сразу на сервере.

Самым простым вариантом (на мой взгляд) связать их воедино — это дать возможность серверу на самостоятельность:

• Если он нагружен — он инициирует запуск ещё одного сервера (при этом, бот ответственный за анализ состояния может заметить, что 95% игроков — в Китае, потому запускать надо именно китайский сервер).


• При этом сервер не просто «запускает», а назначает иерархию и делегирует полномочия (кто отвечает за апдейт куска карты, игроков на нём и т.д.).


• Клиенты, которые попадают на этот новый сервер, сначала получают пакет от текущего: «ребята, переходите-ка туда (ip, порт)».


• Клиенты тоже ребята ушлые: вместо того, чтобы дропать соединение (идёт смена сервера, пожалуйста подождите....) — открывают ещё одно. Для рекомендованного.


• Старый сервер ждёт от нового сигнала, что клиенты вошли и каждого вошедшего переводит в режим «трансляции» — он перегоняет данные с нового сервера конкретному игроку.


• Клиенты проверяют соответствие данных со старого и нового серверов. Если данные сходятся — новый становится доверенным и если по какой-то причине прицепиться к нему выгодно (пинг ниже, приказ от сервера) — бодро прощаются со старым сервером, который отправляет пакет новому. Также они оповещают новый о том, что произошло.


• Также возможна ситуация «сплитера» — когда, например, група игроков идёт через один поток (или нет возможности увеличить мощность сервера) некоторые клиенты могут взять на себя функцию передатчика: они собирают сигнал от игроков, запаковывают к себе в пакет и отправляют одной кучей на сервер. Это, конечно, съест производительность (и не забываем про необходимость шифрования), но если слотов не хватает — это способ.


• В случае, если игроку нужны данные одновременно с разных серверов — он свободно цепляется к нескольким серверам сразу, или же к «дежурным», которые получают данные с нескольких серверов сразу и перегоняют дальше.


• «На всякий случай» можно открыть бэкап-соединение через другой сервер или другого игрока.

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

Любопытно, что эта война с руками и железом породила две, как мне кажется, уникальные механики: борьба за память дала мне идею «хранителей карты» (чьё убийство может привести к локальному концу света), а борьба с ДДОСом при перенаселении — механику усталости от крупных скоплений. Но в тему текущей заметки это как-то не влезает, потому если не будет протестов — опубликую в следующий раз.

Злоключение

На данный момент я не могу заниматься дальнейшей разработкой ввиду отсутствия места дома (да и своего живого железа тоже) и наличия совести на работе.
Если кто хочет свою псевдографическую мультисерверную ММО — то немного времени по вечерам и по выходным у меня есть, но нет ни места, ни железа.

Заключение

— EVE Online, битва при B-R5RB «Титаномахия». Стоило около $315,000 USD.

Так что причин, по которым у группы с финансированием и всем необходимым не может получиться что-то подобное — я не вижу абсолютно. Моя система была рассчитана для работы в условиях разве что не 80286 и в теории давала достаточный уровень производительности на 50-100 игроков в условиях 80486-го + внутрисерверные боты, так что от современных технологий и железа я бы ожидал не менее 2000 клиентов на сервер в самом худшем случае.