Как мы превратили файловую систему в игру: опыт разработки игры на недельном джеме [ЛОНГ]
Предыстория
Иногда попадаешь в непривычное положение, но успеваешь сориентироваться и извлечь из него выгоду.
Так поступил и я: после закрытия проекта, над которым я работал долгое время, я ушел в долгий и незапланированный отпуск. Поскольку отдыхать я не привык, почти сразу предложил двум своим друзьям объединиться и попробовать силы в недельном GameJam от Brackeys (2026.1) на itch.io.
К слову, последний раз я участвовал в джеме в далеком, кажется, 2019 году. Это был двухдневный Ludum Dare, хостом которого выступали Wargaming в питерском офисе, но история не об этом.
Также считаю важным отметить, что здесь и далее будут транслироваться персональные впечатления и эмоции.
Первичная подготовка
Мы спланировали участие в джеме чуть больше чем за неделю до его начала. Времени было много, можно было, наверное, даже подготовить какие-то материалы заранее, ибо правила джема такое не запрещали.
Правила в целом были достаточно мягкие:
- Любые технологии (движки, инструменты, etc)
- Переиспользование ассетов (главное с указанием лицензий и авторства)
- Помощь AI агентов в написании кода (здесь правда сложно придумать как это запретить и регулировать)
Главный запрет был на GenAI, но его мы даже не планировали использовать.
Изначально договорились работать на Godot'е, чтобы можно было быстро итерироваться и больше времени посвящать самому процессу геймдизайна чем разработке технологий, но, буквально за день до старта, сидя в китайской лапшичной мы решили следующее:
Будем делать игру с нуля на C++ и только для графического API возьмем SDL, чтобы сразу на 3 платформы легко собрать билд
Отчасти это решение очень сильно повлияло на итоговую игру и сам процесс, в котором мы погрязли.
Long story short — в недельные рамки мы не уместились — на Jam мы выложили игру без концовки, а затем доделывали её еще почти целую неделю, но об этом будет далее.
Планирование и выбор идеи. Рождение AAAB FileSystem
До начала джема единственное, что мы подготовили заранее, — это несколько идей, которые подходили под большинство возможных тем.
Для планирования мы использовали доску Miro — бесплатный тариф позволяет вполне удобно пользоваться командой доской, строить Kanban таблицы, делать мудборды и набрасывать рефернсы всё это обильно покрывая комментария и стикерами.
В день старта GameJam'а (15.02.26 12:00) мы узнали тему — Strange Places («Странные места») — и с горечью осознали, что наши заготовки идей под эту тему совершенно не подходят.
После достаточно быстрого мозгового штурма в Discord родилась концепция странной деревни, которая на самом деле является файловой системой, а все объекты и сущности в ней — файлами и папками.
Забегая сильно вперед: для недельного джема идея оказалась довольно масштабной, но выбор был сделан, и мы приступили к работе.
Техническое обоснование идеи
Выбор своего движка отчасти помог нам прийти к такой концепции игры.
Работать с файловой системой OS было бы проще + свою технологию ты можешь упаковать в один единственный executable файл — у игрока не будет искушения случайно удалить какую-нибудь библиотеку (.dll файл в случае Windows) или еще что-нибудь жизненно важное для игры.
Деревья растущие в реальном времени и мир реагирующий на действия игрока
Нет, таких идей у нас не было (почти). Все участники джема работают в индустрии, но даже это не помешало нам ошибиться с расчетами и масштабами задуманного.
Я персонально раньше вообще не делал сюжетных игр — больше что-то похожее на Roguelite и карточные прототипы, поэтому для меня этот опыт был совершенно иным, но желанным.
По задумке игрок попадал в «день сурка» внутри деревни. Если точнее — он не мог из неё выбраться, пока не найдет решение проблемы. На локациях есть NPC, и продвижение по сюжету зависит от выполнения их простых поручений, а также от того, на месте ли тот или иной персонаж или нет.
Главные фишки, которые мы запланировали сделать:
- Локации, npc и некоторые предметы появляются в файловой системе при первом взаимодействии с ними.
- Поговорили со стражником — он появился в папке локации Backroad/guard.vil (vil в этом случае villager). Подвигали коробку — получили Backroad/box.box. Игра реагирует на все эти изменения следя за фокусом игрока и проверяя статус директории Village
- Всё можно удалять и создавать везде где хочется. Не можете пройти по дороге, которую перегородил стражник? Удалите его
- Диалоги с NPC и их разновидности в зависимости от условий. Говорим со стражником если в доме есть кот — один исход, если кота нет — другой исход.
Чтобы сразу внести ясность о том как работает идея с файловой системой — покажу гифку.
Непосредственно разработка
Здесь и далее я расскажу про основные этапы разработки — через что прошли, как было и как можно было бы сделать лучше
Какие у нас были роли в команде?
Два программиста для C++ и 3D художник по окружению (окружение было сделано в Blender, а затем запечено тайлами — привет технологии нулевых годов). Все мы также отвечали за нарративную и геймдизайнерскую сторону вопроса.
Начальные этапы
Первые несколько дней мы прорабатывали базу игру — рендеринг, вывод, инпуты от игрока (управление) и базовые компоненты. Мы не стали применять ECS (Entity Component System подход), который я честно изначально очень хотел применить. Вместо этого мы пришли к Inheritance Hierarchy — все игровые классы наследуются, а основной всему является условный BaseEntity класс.
Исходя из того, что пользователю придется часто открывать системный Finder или Проводник, мы пришли к фиксированному размеру окна — 800x600 без возможности развернуть его на полный экран. Это также облегчило нам жизнь, избавив от необходимости адаптировать интерфейс под разные соотношения сторон. Главный drawback же такого решения — на мониторах с разрешением выше 2K всё выглядит очень и очень маленьким.
Также мы прикрутили CI систему на GitHub Actions, чтобы контролировать, что наши коммиты не сломают сборки на Windows / Linux. — мы работали сразу в master ветке, ибо подход с feature ветками для джема для меня звучит овер компликейтед.
Это уже игра? Или нет?
Мы уделили много времени проработке специфических систем — толканию ящиков и взаимодействию с ними.
Согласно изначальной задумке, в игре должны были быть головоломки в духе Sokoban. Как минимум так представлял себе я. Ради этого я несколько вечеров подряд играл в Heroes of Sokoban. (Спасибо Джонатану Блоу за то, что рассказывал об этом шедевре на своих стримах!)
Из интересного на этом этапе: мы не использовали физический движок. Коллизии просчитывались очень специфическим образом, что ближе к концу разработки создало нам немало проблем.
Диалоговая система и упор на неё
Большой упор мы собирались делать на диалоговую систему, поэтому начали собирать и тестировать её довольно рано.
Понятно, что за неделю не сделаешь мощные диалоги с выборами, проверками и бросками кубиков — такой цели даже не стояло. Разговаривать умеют только NPC, а главный герой молча им внемлет. Периодически появляются эфемерные сущности вроде Narrator и Consciousness (вдохновленные даже не столько Disco Elysium, сколько манерой подачи рассказчика в Divinity: Original Sin 1/2).
Power seeps into your limbs like heat through stone. Your breath deepens. Your thoughts race. For an instant, the world feels wider, softer at the edges, as though it might finally bend if you only reached out
Wait a minute... This is not the Divinity Original Sin game or Baldurs Gate game or any other RPG game. This is a simple game about deleting files.
Yes, it is
Поиски визуального стиля и вайба
Мы вдохновлялись старыми играми нулевых годов. Наш чудесный артист по окружениям привел как референс XenoGears, и это показалось нам точным попаданием в то, что мы хотим.
У нас не было особо времени на нормальную работу с графикой и, тем более, работу с 3D объектами, поэтому tile\ы по большей части это отдельные спрайты в ассетах.
Карты локаций это, буквально, целиком запеченные объекты. Никаких атласов, сжатий и пакований — всё серьезно и кондово во имя скорости.
Редактор карт в Blender
Мы писали свой «движок» прямо во время конкурса. Разработать полноценный визуальный редактор мы бы никак не успели, поэтому пришлось импровизировать.
Работать с координатами в блокноте — плохо и страшно, а делать in-game редактор хоть и круто, но слишком трудозатратно. Мы посматривали в сторону Godot как редактора уровней, но из-за нехватки опыта остановились на Blender.
В Blender на 2D-плейне происходило формирование локации: пропсы со строго фиксированными названиями,текстуры из материалов, а параметры — через Custom Properties объектов. Я написал плагин на Python для Blender, который по нажатию кнопки экспортировал сцену в
У такого решения, конечно же, много минусов. Главный из них — над картой не могут одновременно работать два и более человека, так как .blend-файл бинарный и просто так «слить» (merge) изменения не получится.
Осознание масштаба проблемы
Где-то к вечеру пятницы (5-й день джема из 7-ми) у нас была красивая картинка и механики, но все еще не было игры. Даже толком не было продуманных взаимодействий и плана, что будет происходить в деревне.
Здесь я сразу забегу вперед и вынесу главный урок из этого момента
Программирование это весело, но геймдизайн зачастую важнее и нужнее.
Круто, когда в команде есть человек, который занимается исключительно геймдизайном и держит в голове целостное видение игры, не позволяя программистам тратить время на ненужные вещи. У нас эту роль занимали...мы сами.
Именно поэтому собирать игру мы начали ночью, за 10 часов до дедлайна. В тот момент мы не спали почти двое суток, а после завершения джема умудрились ещё и пойти в антикафе «отдохнуть».
Когда окончательно стало ясно, что Sokoban головоломок у нас не будет пришлось придумать сюжетно ориентированный путь для игрока с использованием возможностей файловой системы на полную.
Сборка игры, фейл и переработка
Кое-как собрав что-то играбельное мы побежали создавать submission на конкурсной странице itch.io. По ходу создания мы плейтестили игру и пришли к нескольким печальным моментам:
- Нам не хватило реализовать упаковку ассетов в исполняемый файл игры — рядом с game.exe гордо лежала папка assets
- На Windows игра крашилась буквально после прохождения обучения
- Билд для MacOS нужно подписать и настроить сборку по нормальному (я просто собирал Mach-O бинарник)
- Финальная локация не имела концовки. Игрок доходил до неё и... всё. Конец.
- А еще маленькие баги! Куда без них
Всё это привело нас к великому кранчу, благо правила конкурса позволяли вносить правки еще 48 часов после окончания приема заявок.
Великий кранч
Long story short — мы до сих пор немного дорабатываем игру: обновляем графику, готовим билды для macOS и Linux (которые хотели выпустить ещё на релизе). С этим связана отдельная боль и свои сложности, особенно с Mac. Но Apple Developer Program куплена, поэтому пути назад нет.
По подсчетам, объем диалогов, которые мы написали после первоначального выхода игры, составляет 11 069 символов — это немало. А еще были бесчисленные правки кода, систем и логики. Буквально мы отработали 7 дней джема плюс еще 7 дней, которые ушли на исправления и доработки.
Первые результаты и мотивация доделать
Для нас конкурс не был главной целью участия. Сама возможность собраться вместе и в сжатые сроки создать что-то с нуля — вот что действительно интересно.
Люди сейчас постоянно испытывают усталость, – говорит режиссер. – Если вы работаете только ради денег и не чувствуете радости, жизнь просто проходит мимо. Только когда вы наслаждаетесь тем, что делаете, ваша жизнь становится наполненной смыслом.
Когда мы получили первые отзывы, то поняли: концепция очень «зашла» игрокам и всё не зря. Лично для меня это самое крутое. Неважно, сколько у тебя загрузок или какой рейтинг, — важно, смог ли ты подарить игроку новый опыт, посеять в нём эмоции или свежие идеи. Думаю, у нас это получилось.
Выводы и уроки на будущее
Перед выводами я еще раз подчеркну: весь этот текст — только моя рефлексия. Над игрой работали три человека плюс прекрасная художница, которая помогла нам с артом для Itch. У каждого из нас свои взгляды и впечатления.
Но для себя будущего и, возможно, для других я бы выделил следующие уроки на основе этого опыта:
- Если вы собираетесь участвовать в большом джеме со своим движком — стоит очень хорошо подумать. И если всё же да, то очень советую начать делать сам движок заранее. Тратить время, отведенное на разработку игры, на создание технологий не самая приятная затея
- Здраво оценивайте свои силы. Даже если вы работаете над играми на работе, вы все равно можете наступить на грабли своих амбиций. Деревья растущие в реальном времени крутая штука, но нужно ли это делать? В нашем случае мы могли бы оставить не 6 игровых персонажей, а 5 — тем самым сильно уменьшив количество взаимодействий между ними. Это бы позволило нам лучше сконцентрироваться на проработке того, что есть
- Больше плейтестите и не забывайте про геймдизайн. Понимаю, что плейтест не всегда возможен, но если есть варианты — пользуйтесь ими
- 7 дневные джемы это очень большое давление и напряжение. Для себя я решил, что в следующие разы буду участвовать в более компактных форматах — 2-3 дня, но не больше. С учетом того, что я не работал на основной работе я проводил сидя (или стоя) за ноутбуком от 12 и более часов в день.
- Участвуйте в джемах. Серьезно! Это прекрасная возможность выйти из зоны комфорта и попробовать что-то новое. Паттерны, подходы, технологии открыты для эксперементов.
Послесловие
Спасибо, что дочитали до конца! Я давно не писал статей о процессе разработки, а уж тем более — давно не разрабатывал чего-то своего.
Надеюсь, эта статья дала вам инсайты и идеи, а может, и вовсе замотивировала поучаствовать в Game Jam, чтобы прочувствовать весь этот опыт самостоятельно!
В финальную версию игры (на текущий момент) можно поиграть здесь: AAAB Filesystem.