Когда мне было 11 лет, наша семья купила первый компьютер: AST «Advantage!» с процессором 486 (66 МГц), 4 МБ ОЗУ и жёстким диском на 32 МБ. Это не был самый мощный компьютер, даже в те времена, но на нём был QBasic. Я всегда хотел делать игры, поэтому немедленно погрузился в программирование.

Я застрял на QBasic на следующие десять лет или около того, просто потому, что мне с ним было удобно. Я написал кучу шутеров, платформеров и множество странных игр. Одна называлась «Убей невиновного» («Kill the Innocent») (можно скачать её здесь, но потребуется DosBox, чтобы она заработала). По мосту на экране ходят нарисованные из линий люди, игрок целится в них из дробовика и убивает. Помню, как кодировал подробную систему плавного опускания шляпы-цилиндра с головы человека на землю, и очень простую физическую систему, позволявшую жонглировать головой человека в воздухе, стреляя по ней из дробовика. (Думаю, это была моя неосознанная реакция на жестокость тогдашних видеоигр. Я совершенно точно не осознавал этого, просто на моём AST Advantage очень часто запускался Doom).


Kill the Innocent

Суть в том, что тогда я на самом деле не учился программированию. Я просто использовал снова и снова те же десять ключевых слов. Всё кодировалось жёстко, никакой модульности даже не задумывалось. Другими словами, я не учился программировать. Я понятия не имел, как «импортировать атлас спрайтов» или создать приложение для Windows, не говоря уже об iPhone. Я просто не был программистом.

Мои сложности в изучении написания кода

В юном возрасте и до тридцати лет я пытался снова, и снова, и снова расти и учиться писать на чём-то более современном. Я покупал книги "Научись [здесь название языка]", прочитывал в них первые три главы и сдавался.

Почему же я сдавался? В целом это казалось мне слишком сложным. Если конкретнее, то особенно тяжело мне было прикладывать усилия. Теперь я понимаю, что программирование требует особого типа настойчивости, и почти религиозной веры в то, что «я могу найти и я найду ответ».

Возможно, частично причиной было то, что я «гуманитарий». Я не очень понимал в школе математику и естественные науки, зато у меня были успехи в музыке, изобразительных искусствах и написании текстов. Думаю, я считал себя «творческой личностью», поэтому когда появлялась ошибка компиляции и я не мог устранить её один, два, три, четыре, пять раз, мне легко было подумать «ну, в конце концов, я не программист, и мне нужен программист, чтобы решить проблему».

В конце концов, как во всём остальном, нужно сначала поверить, что вы можете это сделать, и вы сделаете это. Но поверить не так просто.

Дизайнер, но не программист

В первые десять лет моей карьеры профессионального разработчика игр я занимал значимые или ведущие должности в работе над графикой, написанием музыки, созданием звуков, графическим дизайном, веб-дизайном, написанием сценариев, гейм-дизайном и в других специальностях. В буквальном смысле я занимался практически всеми задачами, необходимыми для создания качественной игры, *КРОМЕ* программирования.

Я считал, что если занимаюсь всем остальным, то логично, если кто-то другой займётся программированием. Таким было моё мнение. Меня иногда даже возмущала мысль о том, что я не только должен заниматься дюжиной других работ для создания игры, но ещё и программировать. Мне нужно найти кого-нибудь, кто заполнит этот пробел.

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

Я думаю, что если вы можете всё это делать, но считаете себя гейм-дизайнером, то нельзя на этом останавливаться.

Гейм-дизайнеры — настоящие гейм-дизайнеры — это люди, экспериментирующие с системами и пытающиеся сделать что-то в рамках набора правил. Технически, тот, кто создаёт обычный платформер с головоломками или tower defense конечно же является гейм-дизайнером, но я говорю не о таких людях. Если вы занимаетесь «дизайном» клона Flappy Bird, то, скорее всего, хорошо, что вы его не программируете.

Для таких людей, как я, которые экспериментируют с новыми системами взаимодействий, план «найти программиста» просто непрактичен, потому что в отличие от клона Flappy Bird, дизайн серьёзной игры сложно создать с первого раза. Или с десятого. Или с сотого. Нужна гибкость в реализации идеи, которая поражает вас, как молния, в два часа ночи. Писать письмо или задачу для того, кто не получит сообщение день или два — это слишком долго.

Вам нужно лично находиться в цикле игрового тестирования, постоянно усовершенствуя систему. Настраивая переменные, меняя компоновку — вам нужно участвовать в этом. Иначе у вас появится проблема «игры по электронной почте», когда даже мелкие изменения занимают долгое время.

Не забывайте, что у вас есть конечное количество времени, которое вы потратите на игру, поэтому нужно использовать его по максимуму. Как дизайнер, участвующий в программировании проекта, можно значительно увеличить количество «циклов итерации», укладывающихся в сроки разработки (вне зависимости от времени этих сроков!).

И, наконец, я понял, что при работе с программистом нужно находить баланс между «принимать правильные дизайнерские решения» и «заставлять человека думать, что я не уважаю его время». Чаще всего, когда я прошу программиста что-нибудь написать, позже оказывается, что его работа будет выброшена в мусор. Одно дело — предупреждать людей, что такое может произойти, и совсем другое — говорить им «кстати, о той части, которую я попросил тебя написать на прошлой неделе — пришлось от неё отказаться». Я не хочу находиться в таком положении, что у меня могут быть даже малейшие колебания в принятии правильного дизайнерского решения, потому что оно может кого-то расстроить.

А как насчёт настольных игр?

Настольные игры — хорошая площадка для обучения гейм-дизайну, и некоторые дизайнеры, если таковы их философия и цели, могут всю свою жизнь заниматься созданием настольных игр. Однако тут есть интересный момент: несмотря на то, что существует гораздо больше настольных игр с хорошим дизайном, чем видеоигр с хорошим дизайном, у настольных игр, как у среды, есть определённые проблемы. Многие считают, что настолки плохи по очевидным причинам, например, кому-то не нравится пошаговость, другим не хочется учить правила, или может им не хватает DLC с крутой компьютерной графикой. Но это всё не настоящие причины. Вот в чём на самом деле заключаются проблемы настольных игр:

• Работа с физическими компонентами вызывает определённые проблемы. Сложно точно настроить горизонт информации.
• Меньшая «плотность практической информации» — из-за того, что игроки могут запутаться в правилах, плотность информации — количество информации на один игровой элемент — должна быть ужасно малой. Подробнее об этом и предыдущем пунктах можно послушать в этом эпизоде моего подкаста Clockwork Game Design.
• Быстрая обратная связь. Создайте видеоигру, выложите её в сети, и за несколько часов получите обратную связь от множества людей, даже незнакомых вам. В то время как получение обратной связи о настольной игре требует времени и страдает от других ограничений реальной жизни.
• Не очень жизнеспособны с точки зрения заработка — думаю, что многие дизайнеры хотели бы сделать карьеру на своём ремесле, и, за несколькими исключениями, её проще сделать на компьютерных приложениях, а не с картоном и бумагой.

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

Стать программистом

Разработка Auro: A Monster-Bumping Adventure заняла у нас шесть лет. Основной причиной было то, что это оригинальная стратегическая игра, и я хотел сделать её правильно. Мы могли выпустить обычную и скучную Rogue-like ещё в 2011 году, если бы я не хотел создать что-то особенное. Поэтому мы пробовали, и пробовали, и пробовали.

Но в какой-то момент нашему программисту пришлось заняться другой работой, поэтому мы взяли нового. А потом ещё, и ещё. В результате к концу 2013 года у нас почти «закончились программисты», и иногда казалось, что Auro находится в тупике. Попав в такую ситуацию, я не видел никаких других вариантов — мне пришлось учиться программировать, или вся наша работа пошла бы прахом.

Эта ситуация, а также то, что я стал старше и терпеливее, позволило мне освоиться и изучить базу кода. В результате я самостоятельно написал огромную часть финального кода Auro!

Позже я прошёл онлайн-курс по Unity на Udemy, а также прочитал несколько книг о шаблонах программирования и подобных темах. Очевидно, что впереди у меня ещё долгий путь, но я уже добрался до уровня, на котором я хотя бы могу создавать прототипы и перерабатывать их самостоятельно, и это даёт мне невероятную свободу как гейм-дизайнеру.

Я по-прежнему считаю, что в идеальном мире у дизайнера должен быть «ведущий программист», действительно профессионально занимающийся написанием кода, создающий хорошую структуру и поддерживающий видимость порядка в базе кода, особенно для большой и сложной игры.

Но теперь я знаю, что такие дизайнеры, как я, стремящиеся к созданию новых, интересных, глубоких систем взаимодействия, просто обязаны учиться кодировать. Нельзя полагаться на других, и нельзя полагаться на бумагу и картон. Делайте то, что для этого нужно — заплатите преподавателю, запишитесь на курсы или просто запритесь в комнате с книгой. Разумеется, я не утверждаю, что вам нужно стать Джоном Кармаком и учиться создавать новые движки на ассемблере или что-то подобное. Вам достаточно научиться использовать такие инструменты как Game Maker или Unity, чтобы воплощать идеи игр в прототипы.

Если вы «творческая личность», видеоигры ждут вас!