Гейм-дизайнеры, учитесь программировать

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

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

Kill the Innocent

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: PatientZero

Источник ^[9]