Ранее я уже описывал, как я дошёл до того, чтобы заняться геймдевом, как я готовился к этому и как выбирал инструменты. Здесь же я хочу сосредоточиться именно на самой игре, а также Bevy и Rust, как основных инструментах разработки.
Итак, игра с незамысловатым названием HackeRPG (Hacker + RPG), экшн, где управление основано на кодинге. Проект, в силу своей специфики, рассчитан на узкую аудиторию или, другими словами, «на своих». Из этого следует, что было бы хорошим тоном добавить пасхалки и привычные разработчикам фичи.
Дабы упростить дальнейшее понимание решений, которые я реализовывал, будет правильно хотя бы немного описать движок Bevy. Главная его особенность - ECS (Entity component system), где
- Component - любая сущность игре(будь то спрайт, свет или текст);
- Entity - грубо говоря, контейнер, куда мы складываем все компоненты;
- System - действия с компонентами, которые выполняются в бесконечном цикле.
Помимо прочего в движке реализованы состояния (для ограничения работы систем), события (для разового вызова систем) и ресурсы (для хранения данных, которые не связаны с какими-либо сущностями в игре и не могут иметь несколько экземпляров, формально этого же можно достичь с помощью компонентов, но этот вариант в некоторых ситуациях удобнее).
За конкретными гайдам по самому движку - на официальный сайт или искать мануалы на YouTube.
UI
В начале работы мне предстояло определиться с визуальным стилем и его реализацией. Для пользовательского ввода я выбрал mouseless подход: каждое меню в игре - симуляция терминала, а основной геймлуп - ввод текста в консоль. Ну и, разумеется весь текст обязательно должен быть зелёным: куда без заезженной хакерской эстетики?
Задача достаточно тривиальная, но с учётом ECS - не самая удобная. Однако после некоторых оптимизации и разбиения функционала и модулей можно добиться вполне сносной архитектуры.
Изначально я создал системы, которые вызываются только один раз и создают нужные нам компоненты, такого вида (здесь и далее код будет упрощён до минимума, чтобы не перегружать лишней информацией):
---
fn setup_menu_system(
mut commands: Commands,
game_assets: Res<GameAssets>
) {
commands.spawn(
NodeBundle {
style: Style {
width: Val::Percent(100.),
height: Val::Percent(100.),
flex_direction: FlexDirection::Column,
justify_content: JustifyContent::Center,
align_items: AlignItems::Center,
..default()
},
..default()
}
).with_children(|parent| {
spawn_console(
&game_assets,
parent,
);
});
}
---
Где структура commands добавляет на экран элемент NodeBundle с дочерними элементами, которые создаёт моя собственная функция spawn_console.
Хотелось бы отметить удобство работы с HUD слоем: в Bevy она реализована на основе концепции FlexBox, которая будет привычна любому, кто более или менее знаком с веб фронтенд разработкой.
Важный нюанс используемой мной концепции UI - input и output зачастую отображаются одним и тем же компонентом. Т.е. при наличии такого меню:
---
Say hello
>hello█
---
Где первая строка - output, а вторая (кроме первого символа и символа каретки) - input.
Таким образом для удобства пользовательский ввод хранится в отдельном компоненте, а система, которая выводит текст на экран, уже на лету «приклеивает» его. Такой подход так же позволил довольно удобно реализовать логику каретки и истории ввода, но их я разбирать сегодня не буду. Так, для вывода текста в нашем «терминале», я использую системы вида:
---
fn menu_output_system(
mut console_query: Query<(&mut Text, &TextInput)>
) {
if let Ok((mut output, input)) = console_query.get_single_mut() {
let output_text = get_menu_output();
output.sections[0].value = output_text + text_input.text.as_str();
}
}
---
Где Query используется для того, чтобы получить сущности, у которых присутствуют указанные компоненты, TextInput - мой кастомный компонент, который хранит данные о вводе и автодополнении, а функция get_menu_output - генерит строку для вывода. Довольно минималистично и аккуратно.
Осталось добавить обработку ввода и MVP терминала готово! Для этого я решил использовать две вот такие системы:
---
fn menu_char_input_system(
mut ev_char: EventReader<ReceivedChar>,
mut console_query: Query<(&mut TextInput, &mut TextCaret)>
) {
for ev in ev_char.read() {
if ev.char.is_control() {
return;
}
if let Ok((mut input, mut caret)) = console_query.get_single_mut() {
insert_char_at_caret_position(
&mut input,
ev.char.to_string(),
&caret
);
update_caret_on_input(&mut caret);
}
}
}
fn menu_control_input_system(
keyboard: Res<Input<KeyCode>>,
mut console_query: Query<(&mut TextInput, &mut TextCaret)>
mut ev_exit: EventWriter<AppExit>
) {
if let Ok((mut input, mut caret)) = console_query.get_single_mut() {
if keyboard.just_pressed(KeyCode::Return) {
match input.text.as_str() {
"0" => ev_exit.send(AppExit),
_ => {}
}
input.text = "".to_string();
reset_caret(&mut caret);
}
}
}
---
Первая функция обрабатывает события типа ReceivedChar, отправляя полученный символ в TextInput по позиции каретки, после чего обновляет положение каретки. Вторая - обрабатывает нажатия клавиши Enter и выходит из приложения, если был введён 0(ноль). Добавляя дополнительные состояния, которые будут характеризовать текущий экран, можно реализовать любую навигацию, обработку ввода и отображение информации, используя вышеописанные конструкции.
На данный момент в Bevy состояния не могут хранить какую-либо информацию, а представляют собой примитивное перечисление. Это вынуждает связывать их с ресурсами или компонентами, которые хранят информацию о них. Насколько мне известно, в ближайшее время не планируется это менять, поэтому приходится с этим жить.
В остальном UI довольно тривиален: отображение текста, анимация спрайтов, движение - типичный контент самых простых туториалов. Поэтому продолжу описывать именно «прогерские» фичи.
Gameloop
Следующий шаг: реализация главной фичи игры - управления персонажем с помощью команд. Для ввода текста можно без проблем использовать ранее описанную menu_char_input_system, но теперь её можно сделать несколько более глобальной. Уберём из названия слово menu и заставим её работать не только на экране меню, но и в самой игре. Удалось переиспользовать ранее написанный код, значит что-то правильное есть в архитектуре, а это хорошо! А вот control_input_system потребуется реализовать другую. Опустим boilerplate code и сразу к сути:
---
...
if let Some(command) = command_from_string(input.text.to_string()) {
player_commands.queue.push(command);
}
...
---
Теперь, когда мы нажимаем Enter, мы пытаемся спарсить команду на основе нашего инпута. В случае успеха - добавляем команду в очередь.
Парсинг осуществляется в функции command_from_string, которая в рамках этой статьи останется чёрным ящиком, который делает какую-то магию с регулярками.
После этого в ход вступает система, которая по одной исполняет команды из очереди, если нет текущей активной команды:
---
fn handle_command_queue_system(
mut commands_query: Query<&mut PlayerCommands>
) {
for (mut commands) in commands_query.iter_mut() {
if check_in_progress(&commands) {
continue;
}
set_current_command(&mut commands_query);
}
}
---
Можно заметить, что здесь используется for и iter_mut() вместо if let Ok и get_single_mut(). Таким образом мы обрабатываем компоненты, которых в игре может быть несколько. Этот сниппет - программное олицетворение моего оптимизма, который внушает мне, что проект найдёт интерес и признание и запрос на мультиплеер появится. В остальном - происходит проверка есть ли текущая активная команда с помощью check_in_progress, если её нет, то команда переносится из вектора query в переменную current.
Далее управление принимает довольно большое количество систем, каждая из которых обрабатывает одну конкретную команду. Изначально вся эта конструкция представляла собой один большой match, который со временем стал воистину монструозный, из-за чего был беспощадно разрезан на множество систем катаной рефакторинга. Вот одна из таких систем:
---
fn handle_current_move_command_system(
mut commands_query: Query<(&mut PlayerCommands, &mut Movable)>
) {
for (mut commands, mut movable) in command_query.iter_mut() {
match &commands.current {
Move(x,y) => handle_move_command(x,y,&mut movable),
_ => {}
}
}
}
---
В вышеописанной функции мы проверяем, является ли текущая команда командой move. Если да, то обрабатываем её. Такое разбиение создаёт некоторый boilerplate, однако убирает ад с огромным количеством Query, практика показала, что это решение достаточно удобное.
Таким образом удалось реализовать управление посредством команд. В конечном итоге можно добавлять новые команды посредством добавления ключевых слов и элементов в enum при парсинге, а так же одной системы, которая будет эту команду обрабатывать. Довольно неплохо и почти чисто.
IDE
А теперь настало время прыгнуть в кроличью нору: время добавить внутриигровую IDE. Описание основных фичей связанных с реализацией терминала уже было ранее. Разве что перемещение каретки не было описано, но это я оставлю, как домашнее задание. Далее же задача весьма тривиальна - рекурсивный парсинг. Но вот проблема: Rust не дружит с использованием рекурсии в регулярных выражениях, а значит решение одно:
Пришлось комбинировать парсинг с использованием регулярных выражений с рекурсией на основе функций. Таким образом появилась возможность создавать ифы в ифах и форы в форах. В результате из строки получается структура типа CodeBlock:
---
#[derive(PartialEq, Debug, Clone)]
pub struct CodeBlock {
pub name: String,
pub block_type: CodeBlockType,
pub content: Vec<CodeBlockContent>,
}
#[derive(PartialEq, Debug, Clone)]
pub enum CodeBlockType {
Function(Vec<String>),
Daemon,
Virus,
}
#[derive(PartialEq, Debug, Clone)]
pub enum CodeBlockContent {
Block(InnerCodeBlock),
Lines(Vec<String>),
}
#[derive(PartialEq, Debug, Clone)]
pub struct InnerCodeBlock {
pub block_type: InnerCodeBlockType,
pub content: Vec<CodeBlockContent>,
}
#[derive(PartialEq, Debug, Clone)]
pub enum InnerCodeBlockType {
If(String),
For(ForLoopInnerCodeBlock),
While(String),
}
#[derive(PartialEq, Debug, Clone)]
pub struct ForLoopInnerCodeBlock {
pub variable_name: String,
pub from: PlayerCommandInput,
pub to: PlayerCommandInput,
}
---
Каждый блок кода имеет тип (Function, Daemon или Virus) с нужными для его работы параметрами (только у функций есть вектор имён аргументов), а также хранит содержимое его тело в векторе типов CodeBlockContent. Внутренний контент, в свою очередь, может быть либо строками, которые будут парсится ранее упомянутой command_from_string, либо структурами InnerCodeBlock, которые аналогичны CodeBlock, но могут иметь типы If, For или While.
Аналогично случаю с командами, в случае добавления новых сущностей достаточно добавить элементы в перечисления и в ключевых слов в логику парсинга.
Итоги
Выше я описал лишь небольшой срез проделанной мной работы, помимо этого есть ещё некоторые интересные решения, которые я реализовал в рамках этого проекта (нюансы парсинга, демоны, вирусы, использование ресурсов для запуска кода, древо прокачки в стиле гит, логика обучения и документация), о которых могу рассказать в следующий раз, если будет интерес к этой теме.
Одной из целей игры является поднять навыки программирования у людей и привить любовь к нему. В какой-то степени она уже сейчас достигнута, ведь в процессе разработки я неплохо прокачал свои навыки и по-настоящему полюбил Rust, и теперь стараюсь отдавать ему предпочтение всегда, когда это возможно и имеет смысл. Движок Bevy себя показал крайне хорошо. Да, были ситуации неприятных багов (которые, кстати были пофикшены в следующей же сборке), не совсем удобных решений и неудобной миграции при переходе на новую версию, но!
- удобство разработки;
- качество итогового продукта;
- маленький размер сборки;
Всё это однозначно того стоит.
Другие статьи про проект HackeRPG:
