В данной статье мы кратко рассмотрим, зачем создавать прототипы игр. Да, всё довольно просто, но не так очевидно, как кажется на первый взгляд. Теорию подкрепим кейсом прототипирования экономики 4х стратегии.

upd. 27.09.25 буду рассказывать об игровых движках и прототипировании игр на фестивале "Хочу в геймдев". Если вы в Москве, буду рад встретиться. Для тех, кто не из Москвы предусмотрена трансляция. Если вы не успели присоединиться ко мне или другим спикерам, будет запись выступления.

Теория (не сухая!)

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

Начинающим разработчикам часто рассказывают про методологии разработки, про то, какие этапы должен пройти игровой продукт, чтобы выйти в релиз. Этому учат в ВУЗах (в том числе я), про это пишут статьи. Но редко поясняют зачем оно нужно.

На самом деле всё очень просто. В основе всего лежит понимание, что игры - это венчурный, т.е. высокорискованный бизнес. Если не брать в расчёт гипер-казуал и продукты для Roblox, то разработка обычно занимает существенное время. В ней участвует целая команда. А результат не гарантирован. Невозможно предсказать заранее, понравится ли продукт игрокам, какие будут продажи и даже точно рассчитать сколько времени займёт разработка. Поэтому ошибки, допущенные в самом начале, могут стоять очень дорого. Вплоть до провала всего проекта. Вы можете несколько лет упорно идти к цели, не осознавая, что вы на всех порах гоните локомотив в ад. Да, очень быстро, эффективно, весело и с прекрасной продуктивностью. Но в ад.

Именно поэтому игры постоянно прогоняются через множество инструментов снижения рисков от демонстрации фекшотов на reddit до публикации демки в Steam. Прототипирование - один из таких инструментов.

Цель прототипирования - проверка гипотез.

Да именно проверка гипотез, а не абстрактное "создание классного прототипа". Ну все же делают прототип, значит и у нас будет!

Соответственно, прежде, чем делать прототип, нужно:

1. Сформулировать гипотезы, которые мы хотим проверить.

2. Сформулировать критерии оценки, прошла ли гипотеза проверку.

3. Определить технические средства, с помощью которых будет проведена проверка.

Прототип не только игра, но и инструмент.

Как бы да, но как бы и нет. Компании, обладающие некоторым ресурсом, должны понимать, что прототип - это инструмент проверки гипотез, а не игра, которую мы будет разрабатывать дальше.

Не нужно:

1. Закладывать правильную и масштабируемую архитектуру.

2. Выбирать сложные движки и системы разработки.

3. Развивать прототип и превращать его в игру.

Это логично, но не все так делают. Есть случаи, когда мы нарушаем эти правила, а именно:

• Делаем гипер-казуал (здесь грань между игрой и прототипом чрезвычайно тонка).

• Бедные инди без ресурсов (инди разработка многогранна и часто превращает прототипы в полноценные игры).

Что касается инструментов, то это должны быть сааааамые быстрые средства, чтобы проверить гипотезу и выкинуть прототип, не сожаления о затраченном времени. Что обычно используют:

1. Настолки (прототип из бумажек, кубиков и подручных средств). Очевидно, подходит не каждой игре.

2. Простые движки и фреймворки (я люблю питон и Ren'Py, многие мои студенты прототипируют на нём сценарии своих игр). Для этой задачи подходят GameMaker, Defold, BuildBox или просто конструкторы web приложений. А в последнее время добавились ещё и ИИ генераторы приложений типа base44, но про них пока не могу ничего сказать, т.к. мои прототипы в AI системах получились не сильно рабочими.

3. Специальные программы для прототипирования (типа Machinations). Удобные штуки, но в основном платные.

4. Полноценные игровые движки (обычно выбирают Unity). EU и Godot тоже не забыты. (Кто-то пробовал Unigine или NAU? я как-то прошёл мимо них)

Теперь к примерам.

Кейс: экономика 4х стратегии

Ситуация

Мы безумцы и делаем игру типа Age of Wonders, Endless Space II и Цивилизации небольшой командой в сжатые сроки. Это космическая 4х стратегия, где можно колонизировать звёздные системы и отдельные планеты. Одна из самых базовых вещей в игровом цикле такой игры - экономика планеты.

Задача

Придумать такие особенности строительства для нашей игры, чтобы удовлетворяла следующим критериям:

• Понятная (в духе классических 4х)

• Оригинальная (несёт в себе хоть немного нового опыта для игрока)

• Не скучная (через час не хочется забросить, посчитав застройку планет рутиной)

Решение

1. Спроектировать вариант экономики.

2. Создать прототип.

3. Поиграть, почувствовать геймплей.

4. Вернуться к пункту 1, если нет ощущения кайфа от геймплея.

Гипотеза

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

• Для уникальности планет достаточно рандома и комбинаторики.

Мы решили, что:

1. Доступные ресурсы: население, еда, производство, наука.

2. Планета разделена на зоны. Каждая зона имеет свой биом. Разные биомы вмешают разное кол-во единиц населения. Каждая единица населения что-то производит в зависимости от биома и её собственных особенностей.

3. В каждой зоне можно возвести одну доминанту - постройку. Постройки могут давать фиксированный прирост ресурса, прирост на 1 населения или прирост за каждую открытую зону на планете.

4. Помимо построек есть проекты. Проекты не занимают слот зоны, но дают тоже самое. Пример постройки: Храм изобилия (+10 еды), пример проекта: Подземные плавильни (+1 производства в каждой зоне).

5. Очередь производства у проектов, построек, юнитов и т.д. общая.

Прототип 1

• Движок: Ren'Py (python 3)

• Время разработки: 5 часов

• Ассеты: chatgpt + photoshop

Примерно за половину рабочего дня появился технический прототип. А мы помним, что скорость - важная часть прототипирования. Ещё столько же времени заняла полировка и создание контента.

После нескольких часов игры с разными настройками, я понял, что заявленную изначально цель этот прототип не выполняет. И это прекрасно. Я понял, насколько важными для геймплея 4х являются нюансы: ручное перемещение населения между зонами, выбор исследований, случайные событие, аномалии, источники редких ресурсов и т.д.

Результат

Создание прототипа привело к тому, что я:

1. получил много информации для размышления;

2. переформулировал выдвинутую изначально гипотезу;

3. взял в команду программиста Unity под задачу прототипирования;

4. поставил задачу себе и команде ГД сформулировать больше вариантов.

В итоге свою задачу этот прототип всё же выполнил. Не так, как я видел это изначально. И, как и положено в ситуации с прототипами, мы приступили к созданию следующего, более комплексного протоипа.

Геймдизайнеры сформулировали последовательность механик для прототипирования: от простейшего Прототипа-1 до мини-версии игры. Скриншот из Miro представлен не для чтения, а для иллюстрации объёма механик к версиях прототипа (пытаться прочесть, что там написано, не обязательно).

Следующая версия прототипа уже собиралась в Unity и шагнула чуть дальше первого варианта.

Подробнее о прототипировании игр, игровой логике и нарративном дизайне я рассказываю на программе Менеджмент игровых проектов в Высшей Школе Бизнеса НИУ ВШЭ.

А в субботу 27 сентября там же пройдёт фестиваль "Хочу в геймдев", где я буду рассказывать про игровые движки, а наша команда продемонстрирует нашу инди-игру Азраил, вестник смерти.