GAMEDEV
Где-то месяц назад вышла SpacetimeDB 1.0 и они ярко презентовали свою технологию как универсальный сервер и база данных, предназначенные для создания и запуска многопользовательских игр и приложений с невероятной скоростью. Давайте же посмотрим на эту технологию.
Какая концепция лежит в основе SpacetimeDB? Я недавно публиковал краткий обзор про ECS в основе которой лежит дизайн ориентированный на данных. И по своей сути ECS является некой реляционной моделью. Для примера можем посмотреть на следующий код:
struct Entity(u32);
struct Position {
x: f32,
y: f32,
z: f32,
}
struct Velocity {
x: f32,
y: f32,
z: f32,
}
struct Player {
username: String,
}
struct Enemy {
target: Entity,
}CREATE TABLE Entity (
id SERIAL PRIMARY KEY
);
CREATE TABLE Position (
entity_id INT PRIMARY KEY,
x FLOAT,
y FLOAT,
z FLOAT,
FOREIGN KEY (entity_id) REFERENCES Entity(id)
);
CREATE TABLE Velocity (
entity_id INT PRIMARY KEY,
x FLOAT,
y FLOAT,
z FLOAT,
FOREIGN KEY (entity_id) REFERENCES Entity(id)
);
CREATE TABLE Player (
entity_id INT PRIMARY KEY,
username TEXT,
FOREIGN KEY (entity_id) REFERENCES Entity(id)
);
CREATE TABLE Enemy (
entity_id INT PRIMARY KEY,
target_entity_id INT,
FOREIGN KEY (entity_id) REFERENCES Entity(id),
FOREIGN KEY (target_entity_id) REFERENCES Entity(id)
);Если разложить всё по полочкам, то становится ясно, что модель ECS — это просто реляционная модель со следующими ограничениями:
- Существует таблица сущностей с единственным уникальным id столбцом.
- Все остальные таблицы должны иметь уникальную ссылку на внешний ключ сущности id.
- Системы (они же запросы) должны выполняться для каждого объекта, которому они соответствуют, для каждого «кадра».
- Системы могут выполнять только INNER JOIN запросы к объекту id и оперировать ими.
Но когда мы используем Базы Данных, то наша архитектура обычно выглядит следующим образом: клиент отправляет запрос на сервер, сервер выполняет какую-то логику и отправляет запросы в базу данных. А в более крупных онлайн проектах архитектура может быть настолько сложной, что приходится нанимать кучу специалистов для поддержания и реализации таких систем. Какая проблема возникает тут, которая плохо сказывается на производительности и ведёт к ошибкам, как например, появление дубликатов предметов?
Это сетевое взаимодействие и постоянное преобразование данных из одного типа в другой. Мы конечно можем обеспечить атомарность, согласованность, изолированность и долговечность при работе с БД, выбрав такой продукт, но зачастую в игровых мирах мы не хотим ждать долгих транзакционных операций и в этом случае разработчики могут пожертвовать чем-то, чтобы ускорить процесс.
Мы стараемся подбирать типы данных в коде максимально близкие к типам в базе данных, но всё равно это не избавит нас от постоянных преобразований. Ваш код всегда будет далёк от ваших данных. Да в таких случаях можно воспользоваться хранимыми процедурами на стороне БД, но для поддержки таких скриптов требуется нанять опытных специалистов. Или же можно воспользоваться кэш системами, но это потребует дополнительных расходов на оперативную память и согласованности ваших данных, когда один игрок изменил информацию, а у других игроков она появилась с задержкой.
И что же SpacetimeDB решает все эти проблемы? Переходим к тому что они предоставляют. Ваш так называемый серверный код и взаимодействие с данными схлопываются в один сервер, где код на прямую работает с данными, а сами данные соответственно загружаются и хранятся в оперативной памяти. Это подразумевает что они сделали быструю работу с данными и предоставили весь тот функционал, который мы используем при работе с базами данных.
Они предоставляют три базовые концепции.
- Таблицы - для транзакционного хранения ваших данных
- Редукторы - сервисный код, который выполняется атомарно под транзакцией.
- Подписочные запросы - для отслеживания в реальном времени изменений в ваших данных.
Посмотрим на шаги написания серверного кода
Ваш код (пока доступны два языка Rust и C#), где вы определяете структуру таблицы, как в каких-нибудь ORM фреймворках используя язык программирования. И редуктор - функция где находится ваша серверная логика. Весь ваш написанный код компилируется в WebAssembly и загружается в SpacetimeDB. В будущем они добавят ещё больше поддержки для других языков программирования, которые так же смогут компилироваться в WebAssembly по их API и выполняться на сервере. Так как это open-source проект, то некоторые люди написали какую-то поддержку для языка Zig.
Далее на стороне клиента вы получаете API и подключаетесь по websocket к серверу.
Так же вы можете сделать SQL запрос и подписаться на отслеживания этих данных в реальном времени.
Например, один из игроков изменил свою позицию и остальные игроки получили эту информацию, по их оценкам на обработку миллиона сущностей уйдёт всего лишь 200 миллисекунд, тогда как для sqlite понадобится 2 секунды. Это порядка 5 млн записей за секунду.
Пример проектов
Как рассказывает главный разработчик этой системы, поводом для создания SpacetimeDB послужили трудности, которые они испытали при написании их ММО игры BitCraft, где каждый игрок может взаимодействовать в реальном времени с миром и все игроки находятся на одном сервере. Уже сейчас есть мобильный проект DeliveryZ написанный с помощью этой технологии всего за 3 месяца. И не только в сфере игр можно использовать эту технологию, так для создания pogly тоже использовался SpacetimeDB, это приложения для стримеров, чтобы в реальном времени накладывать какие-либо изображения на стрим с помощью ваших модераторов. Даже проводились эксперименты по голосовой связи через SpacetimeDB в их дискорд канале.
Недостатки
Кроме множества плюсов, есть и недостатки, так на одном из интервью главный разработчик рассказал, что при большом количестве мелких запросов может быть предпочтительнее использовать PostgreSQL, в Big Data для анализа петабайт данных и для создания шутера, где нужно проводить много физических вычислений и контролировать сетевой протокол, потому что вы делаете сложные мгновенные действия. Они стремятся покрыть больше возможностей, но пока сосредотачиваются на ММО составляющей.
Опрос: Как вам SpacetimeDB?
1.
Непонятно
2.
Интересно
3.
Хочу попробовать
4.
Уже использую
Ред. bifurcated
Ред. ScorpioT1000
Я пока подожду их игру BitCraft, всё же это их основной продукт на этой бд, а там посмотрим чего они добились и как это играется.