[Перевод] Почему я отказался от разработки игр на Rust, часть 4

info@vsetut.pro

Стать автором

Вернуться

30.05.2024 06:50:02 | Хабр

Хабы: Rust, Разработка игр, Программирование

Часть 1
Часть 2
Часть 3

Dynamic borrow checking вызывает неожиданные вылеты после рефакторинга

В процессе написания статьи я обнаружил ещё один случай вылета нашей игры из-за пересекающегося World::query_mut. Я работаю с hecs уже около двух лет, такие проблемы — это не тривиальные «ой, я случайно сделал вложенными два запроса», с которыми сталкиваешься, только начав работать с библиотекой. Скорее, это ситуация, когда одна часть кода, находящаяся на верхнем уровне, запускает выполняющую что-то систему, а затем независимая часть кода делает что-то простое с ECS где-то глубоко внизу; после крупномасштабного рефакторинга они неожиданно оказываются пересекающимися.

Такое у меня случается не впервые; обычно советуют такое решение: «твой код просто плохо структурирован, поэтому ты сталкиваешься с такими проблемами; необходимо его отрефакторить и спроектировать правильно». Спорить с такими аргументами довольно сложно, потому что по сути своей они правдивы — это происходит, потому что какие-то части кодовой базы спроектированы неоптимально. Проблема в том. что это ещё один случай, когда Rust вынуждает делать рефакторинг там, где бы этого не требовал никакой другой язык. Пересекающиеся архетипы — не всегда преступление, и ECS-решения не на основе Rust (например, flecs) вполне их допускают.

Но эта проблема возникает не только в ECS. У нас она много раз возникала при использовании RefCell<T>, когда два .borrow_mut() создают пересечение и вызывают неожиданный вылет.

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

Подробнее