Devlog #1 — Мы почти потеряли игру

На старте у нас была простая идея: игра про оператора лифта в большой корпорации.

Мы придумали:

• мегакорпорацию;
• пассажиров с разными требованиями;
• KPI;
• случайные события;
• проблемы с лифтом.

Но в процессе разработки стало понятно, что мы больше думали о мире игры, чем о самом игровом процессе.

Нам задали простой вопрос: «Что игрок делает первые 10 секунд?»

И на него не было чёткого ответа.

Сначала мы думали, что игра будет про поиск оптимального маршрута. Потом — про обслуживание пассажиров. Потом — про ремонт и управление состоянием лифта.

Но всё это были отдельные механики. Они не объясняли, почему игроку должно быть интересно играть.

Мы начали разбирать основу и поняли:

Shaft 9 должна быть игрой про один рабочий день, где игрок пытается выполнить смену, постоянно реагируя на новые проблемы.

Не построить идеальный маршрут. Не настроить систему один раз. А пройти весь забег, когда ситуация постоянно меняется.

Мы вернули структуру, похожую на рейд:

Начало смены → планирование → выполнение → новые проблемы → адаптация → результат.

Игрок получает новые вызовы лифта, выбирает приоритеты, управляет маршрутом и решает, какие проблемы исправлять сейчас, а какие оставить на потом.

Например:

• отвезти больше пассажиров или сохранить лифт в рабочем состоянии;
• остановиться на ремонт или продолжить смену с риском;
• выбрать быстрый путь или безопасный маршрут.

Если решение имеет очевидный ответ — значит, оно пока недостаточно интересно.

Теперь понятно, почему нам близок FTL.

Не из-за корабля и не из-за случайных событий. А из-за структуры: ты начинаешь забег с планом, но уже через несколько минут ситуация меняется, и приходится принимать решения с неполной информацией.

Именно это ощущение мы хотим перенести в Shaft 9.

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

Игрок управляет одним лифтом мышью:

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

То есть игрок управляет не кнопками лифта, а всей рабочей сменой.

Параллельно начали собирать визуальное направление.

Сейчас рассматриваем:

• 2D интерфейс;
• изометрический вид здания;
• отображение сети маршрутов как основной игровой карты.

Главное — игрок должен видеть не просто кабину лифта, а всю ситуацию вокруг неё: где ждут пассажиры, где возникли проблемы и какие решения доступны.

Что делаем дальше:

1. Собираем первый игровой экран.
2. Проверяем базовый цикл:

получить вызовы → выбрать маршрут → управлять лифтом → реагировать на проблемы → закончить смену

1. Делаем первый прототип одной смены без дополнительных систем.

Сначала хотим проверить главное:

интересно ли управлять одной сменой оператора лифта.