Автор вспоминает детство с первым ПК и QBasic: он делал простые шутеры и платформеры, но по сути не учился программировать — всё было жёстко захардкожено, без модульности и понимания современных инструментов.
Много лет он пытался перейти на современные языки по учебникам, но бросал после первых глав. Ошибки компиляции и сложность казались подтверждением, что он «творческий, а не технарь». Позже он осознал, что программирование требует особой настойчивости и веры, что решение найдётся, и это не связано с тем, «арт-человек» ты или нет.
Непрограммирующий геймдизайнер
В индустрии автор занимался почти всем, кроме кода: артом, музыкой, звуком, графдизайном, вебом, текстами, геймдизайном, маркетингом. Логика казалась простой: если он закрывает десяток ролей, программиста можно найти отдельно. Так он и выпускал игры, оставаясь «дизайнером без кода».
Однако для «настоящего» геймдизайна — экспериментов с новыми системами и правилами — это плохо работает. Если вы делаете клон Flappy Bird, можно передать реализацию программисту. Но если вы создаёте новые системы, вам нужно:
- иметь возможность внедрить идею сразу, а не ждать, пока кто-то прочитает письмо или задачу;
- быстро и многократно проходить цикл «прототип → плейтест → правки»;
- не зависеть от чужого времени и мотивации.
Работа через программиста превращается в «play by email»: даже мелкие изменения растягиваются. Кроме того, дизайнеру психологически сложно регулярно «выбрасывать» труд программиста, что может мешать принимать правильные продуктовые решения.
Почему одних настолок мало
Автор признаёт настольные игры хорошей школой геймдизайна, но указывает ограничения медиума:
- физические компоненты усложняют управление информацией и точную настройку «информационного горизонта»;
- низкая практическая информационная плотность: игроки не могут обслуживать сложные системы вручную;
- медленная и неудобная обратная связь: нужны встречи, расписания, живые тесты;
- коммерческая нишевость по сравнению с цифровыми продуктами.
По его мнению, сделать великую настолку ещё сложнее, чем великую видеоигру, а последняя и так почти невыполнимая задача.
Как он стал программистом
При разработке Auro: A Monster-Bumping Adventure (оригинальная стратегия) команда потратила около пяти лет на итерации. Смена нескольких программистов привела к тому, что проект оказался под угрозой. Автор понял: либо он сам войдёт в код, либо работа пропадёт.
Под давлением обстоятельств он начал разбираться в кодовой базе и в итоге написал значительную часть финального кода Auro. Позже он прошёл онлайн-курс по Unity на Udemy, изучал паттерны и дошёл до уровня, когда может самостоятельно прототипировать и быстро итератировать дизайн.
Он по-прежнему считает полезным иметь сильного ведущего программиста на сложных проектах для архитектуры и порядка в коде. Но для дизайнеров, которые стремятся к новым глубоким системам взаимодействия, умение программировать — необходимость.
Рекомендации дизайнеру
Автор призывает геймдизайнеров «творческого склада» не бояться кода. Не нужно становиться Джоном Кармаком и писать движки на ассемблере. Достаточно освоить инструменты уровня Game Maker или Unity, чтобы доводить идею до рабочего прототипа самостоятельно.
Он советует сделать всё необходимое: нанять репетитора, пройти курс, закрыться с книгой — главное, научиться лично проводить полный цикл от идеи до играбельного билда.
Выводы
- Непрограммирующий геймдизайнер сильно ограничен в скорости и глубине итераций.
- Для экспериментального системного дизайна критично самому уметь прототипировать и менять игру.
- Настольные игры полезны как школа, но сильно ограничены по информации, скорости фидбэка и коммерции.
- Даже «творческий» дизайнер может освоить код, если примет это как необходимый навык профессии.
- Достаточно уровня Unity/Game Maker: цель — рабочий прототип, а не идеальный движок.
