На прошедшем IT-фестивале Tech Train мы встретились с легендарным Джоном Ромеро, который приложил руку к дизайну и разработке культовых Wolfenstein 3D, Doom и Quake. Мы поговорили о том, нужны ли игровым разработчикам софт-скиллы, на какие рабочие инструменты стоит обратить внимание, и какие у сооснователя Id Software любимые игрушки. Вопросы задавал Никита Цаплин — основатель RUVDS.
→ Англоязычная версия текста и видео здесь
Никита Цаплин — основатель RUVDS
В одном интервью ты сказал, что в 2001 году просматривал старый код, написанный в 1991, и не нашел ему практического применения. Но спустя какое-то время возвращаясь к коду, написанному в двухтысячных, ты назвал его «неплохим». Как ты отслеживаешь качество кода?
Джон Ромеро — программист, дизайнер и сооснователь ID Software
В 1991-м году код как минимум наполовину был написан на Ассемблере и я тогда только начинал программировать на Си и был совсем новичком. Так что возвращаться к нему спустя десять лет активного программирования на Си было ужасно.
Расскажи, как менялись критерии отбора со временем? Какие остались неизменными?
Полностью изменилась среда, в которой исполнялся код. Написанное в 1991 году запускалось в DOS, а код из 2001 года работал на Windows.
Значит это было связано с обновлением платформы?
Совершенно новая среда. Да.
Можешь ли ты рассказать об основных критериях, по которым ты оцениваешь свой код?
Основные критерии — это легко ли прочесть код? Это очень важно.
Написаны ли комментарии? Перебарщивать с этим не стоит — быстро становится скучно. Но важно, чтобы сложные части и секции кода были прокомментированы, и его структура в целом была понятна и легко дополняема.
Какими навыками должен обладать разработчик, чтобы влиться в игровую индустрию?
Ты должен сильно хотеть создавать игры. Потому что сложно просто закончить игру — это кропотливая работа. Не имеет значения над какой частью ты работаешь — она займет намного больше времени, чем ты когда-либо представлял. Нужно быть готовым к длительной концентрации внимания над определенной задачей.
Я слышал, что разработчикам сейчас как никогда требуется освоение «Soft Skills»? Это правда?
Да. Потому что сейчас все объединяются в команды, когда вы работаете вместе, нужно быть эмпатичными друг к другу.
Взаимодействовать?
Да.
У вас в этом большой опыт?
К этому приходится привыкать, а программисты не любят разговаривать. Они просто хотят кодить. Тут важно понимать как ограничить время, которое ты отнимаешь у людей от программирования, просто для короткого разговора. Но в наше время почему бы просто не использовать Slaсk и общаться через него. Это удобнее и быстрее, чем снять наушники, встать с места и пойти поговорить с кем-то на другой конец офиса. Так что мы предпочитаем Slaсk.
Да, люди хотят пространства и общаться через мессенджеры.
Особенно если надеты наушники, да.
Как ты думаешь, какие из «Soft Skills» наиболее важны?
Я считаю, что взаимодействие намного важнее остальных навыков. Так было всегда. Если люди вокруг не знают, что ты делаешь, или ты не в курсе происходящего, можно потерять целую кучу времени и денег, потому что ты был занят не тем.
Так что общение одна из самых значимых вещей, которую ты можешь сделать. Каждый должен знать, как и что именно он должен делать. Даже если ты взялся за работу над каким-то отдельным фрагментом, важнейшая часть — это то, как ты это преподносишь. Не просто «Окей, я это сделаю…». Правильнее будет сказать: «Я сделаю вот это и вот таким образом. Вы согласны?».
Итак — важнейшая часть на каждой стадии разработки это общение?
Да.
Несколько месяцев назад мы говорили с Ричардом Грэем в Москве. И он подсказал, что лучший способ для разработчиков зарекомендовать себя в игровой индустрии — сделать что-то своими руками. Но, с другой стороны, вы говорили, что создание игрового уровня подобного Doom в Сигиле крайне непростая задача. Современные инструменты слишком сложны и многослойны для создания наброска для портфолио. Как найти золотую середину?
Это правда. В современных движках потребуется уйма времени для создания уровня.
Все далеко не так просто, как было раньше. Сейчас это занимает действительно много времени. Сегодня столько людей вовлечено в разработку. Отдельный персонал отвечает за освещение на уровнях. А есть гейм-дизайнеры устанавливающие ограничения, художники с концепт-артами. Они же прорабатывают визуальный стиль игры. Ещё нужно проверить работу шейдеров.
Мне кажется, сейчас практически невозможно сделать уровень просто для портфолио, если в этом будет необходимость.
Вообще это возможно, но занимает очень много времени. Есть отличный пример на Ютубе. Если ты используешь Анриал, и ты хочешь понять из чего именно состоит последовательность создания уровня в одиночку — для этого есть инструкции. Один парень записал 30-ти минутное видео, где он показывает создание коридора в течение 10-ти часов. Оно длится всего тридцать минут, но воспроизводится на высокой скорости, достаточной, чтобы увидеть все шаги для работы над коридором. Десять часов! Сегодня игры отнимают много времени.
Как ты думаешь, какой стратегии стоит придерживаться разработчикам для начала карьеры?
Лучший вариант — выучить дома как можно больше материала. Знаешь, можно пойти в школу и выучиться в ней, что даст свои плюсы в виде диплома и прочего. Но ты узнаешь намного больше, занимаясь дома. Так работа пойдет быстрее и ты изучишь именно то, что захочешь.
Некоторые говорят, что программисты использующие готовые фреймворки не имеют ни малейшего представления о том, как он работает внутри. Имеет ли это какое-то значение? Осознавать, как работает используемый фреймворк?
Да, и большое. Это полезно. Предположим, джуниор-программист использует фреймворки. Опытные программисты знают, как они устроены. Это значит, что при необходимости они смогут построить его, ведь они знают детали работы от начала до конца, да? И это очень полезно, потому что фреймворки можно использовать очень неэффективно, не зная внутреннего устройства, вызывая значительные потери в производительности.
Вопрос гибкости. Ведь можно комбинировать фреймворки, если знать как.
Конечно всё нужно соединить воедино, чтобы всё заработало, но это не значит, что оптимизация будет на высоте. Это не гарантирует знание программного обеспечения. Особенно когда речь идёт о базах данных. Можно записать информацию или сам код для работы баз данных, который будет ужасно работать. И будет ощущение, что всё в порядке, потому что набор команд верный, но если ты не знаешь, как InnoDB использует их в работе, и как интерпретирует, тогда просто забудь об этом. Потребуется нанять консультанта, который придёт и исправит работу.
Очередная интересная тема — Agile. В книгах и статьях геймдев полон романтики и непредсказуемости. Именно в этом контексте Agile бы пригодился. Agile и возможно другие подходы?
Только Agile, но не в жесткой и неприкосновенной форме. У нас применяются «маркеры» для определенных периодов, к которым нужно сдать материал. Это большой и комфортный промежуток времени. Примерно в три раза больше, чем предполагается в Agile. Около шести недель вместо двух. Это очень удобный и комфортный промежуток, в который удаётся решить много проблем. Также есть заимствования из Kanban-стиля… Возможно, потому, что не все задачи необходимо выполнить в шесть недель, некоторые из задач остаются всё ещё в работе и их невозможно закончить к сроку. В итоге мы проверяем итоги работы, а не откладываем незаконченные процессы до следующего «маркера».
Здесь идёт речь скорее о верном составлении списка возможностей и задач, требуемых к выполнению, чем слепое следование принципу дед-лайна. Если ты выполняешь свою задачу — отлично, если нет — вопрос откладывается до следующего «маркера».
В последствии эта стратегия превращается в упражнение по переоценке приоритетов. Если что-то занимает много времени — сделай это по-другому. Упрости и вырежь необходимое, чтобы решить поставленную задачу. Либо ты просто переключаешься, если прошло много времени.
Подводя итоги — необходимо понимать, как работают процессы и комбинировать различные подходы?
Да.
Можешь ли ты сравнить как организовывались процессы разработки в игровых студиях сейчас, и, к примеру, девяностых или двухтысячных?
Это в большей степени зависело от количества людей в команде. В смысле, это всегда зависело от размера штата. Даже сейчас если у тебя всего лишь команда из четырёх человек, ты бы разрабатывал в том же стиле, что и мы в 1990-х с тем же составом. Потому что команда настолько мала, что люди знают свою роль в команде и тесно общаются друг с другом. Поскольку, вероятнее всего работают в одной комнате.
В моей компании RUVDS также работает небольшая команда, и нам не нужно постоянное формальное общение.
Именно. В этом нет необходимости. Тот же расклад был в 1990-х. Просто, всё, что ты пишешь, меняется из-за развития платформ, а общение и методы разработки остаются прежними. Дизайн, который вы разрабатываете, отличается, поскольку язык дизайна эволюционировал с 80-х. То, что вы проектируете — отличается, но то как вы разрабатываете продукт остаётся таким же.
Есть ли вещи, которые становятся проще или сложнее в разработке игр со временем? И почему?
Есть много полезных инструментов, которые позволяют упростить создание игр. Сложнее становится написать хороший дизайн. Сложно прийти к хорошей задумке для игры. У вас может быть лучший программист в игре, который напишет отвратительную игру и в нее никто не будет играть. Навык программиста на это не влияет.
Значит гейм-дизайн на первом месте?
Это важнейшая вещь. Если у вас в штате отличный гейм-дизайнер, который хоть немного разбирается в программировании, вы рискуете открыть новый жанр для игр. У вас выйдет отличная игра. Так что гейм-дизайн важнее всего остального.
Возвращаясь к TechTrain. Куда же этот поезд везёт игровую индустрию?
Я бы сказал, что игры с дополненной реальностью (AR) являются очень вдохновляющим сегментом. Это новый простор для размышлений и здесь много денег. Не так много, как было у VR, когда все вкладывали деньги в неё, но…
Но VR долго не продержалась.
Да, не продержалась. VR лучше в неигровых приложениях. У неё есть хорошие задумки, но главным препятствием для успеха VR стала утомляемость. Люди слишком быстро устают, играя в игры. Знаешь, люди больше не прыгают на своих Wee-пэдах. Они просто устали. И больше не хотят этого делать. А VR сложна в использовании.
У тебя был опыт разработки с дополненной реальностью или VR?
Я не делал ничего связанного с AR, но мне очень нравятся её возможности. Если присмотреться к Лего-играм, или Minecraft-Earth, то у AR большой потенциал, все начинают экспериментировать с ней, плюс она нравится покупателям. Pokemon Go доказал всем, что в потенциале AR целая куча денег. Она не заменяет консоли, смартфоны, это новый сегмент и технология.
Похоже, что все представляют насколько технология нова, но не совсем понимают, как её использовать.
Не совсем, для неё уже создана API. Apple разработала AR-кит, и это просто отлично. Они не сделали аналогичный пакет для VR — осознанно. Они разработали его для AR потому, что знают, что она заработает. С помощью AR в паре со Swift 5 можно сделать много классных вещей.
Что ты думаешь о мобильных играх?
Ну, Сигил выпущен на смартфонах.
Мне кажется, мы запустили Сигил на целой массе устройств. Безумное количество. Знаешь, в Инстаграме и Твиттере такое количество устройств с запущенным Сигилом. Люди продолжают грузить скриншоты.
Но… Они достраивали её самостоятельно? Сигил же выпускался для смартфонов?
Ну… Он был выпущен на платформе Android. Ты можешь скачать Doom поддерживающий моды. Также в Сигил можно играть на Xbox. Можно использовать Automechs — это Doom с открытым кодом и поддержкой модификаций, затем можно установить Сигил на Xbox и спокойно играть на нём.
Верно. Ты когда-нибудь думал о том, чтобы выпустить Battle-Royale игру во вселенной Doom? Что-то наподобии Fortnite?
Думаю, это было бы забавно. Я этого не сделаю. Но это было бы действительно забавно, если бы это сделал кто-то другой. Battle Royale это просто фреймворк со своим набором правил на базе любой игры. К примеру, та же Fortnite. Она не была Battle Royale игрой. Но стала таковой, когда увидела PUBG, и отхватила свой кусок.
Это можно провернуть с любой вселенной. Но видеоигры, разработанные специально для этого режима, всё равно справляются лучше. Впереди ещё много подобных игр, экспериментирующих с игровыми механиками. К примеру, пока ты играешь и делаешь всякое, майнишь ресурсы, например… Копаешь и круг сужается, понимаешь?
Ага.
И люди стреляют по тебе, пока ты копаешь! А тебе нужно майнить, чтобы собрать предметы!
Да! Хорошее сравнение! Как ты думаешь какие игровые жанры изживут себя в будущем?
На текущий момент ни один из них. В смысле, единственный ушедший жанр это текстовые квесты, но всё ещё есть приключенческие игры. Например, обычные квесты развились в мистические адвенчуры, и при этом игр-казуалок огромное количество. Везде, где продаются игры, особенно на мобильниках, можно заметить огромное разнообразие жанров. И люди, считающие что квесты, или что угодно другое, ушли навсегда, ещё с 90-х или 2000-х — им просто нужно подойти к «стеллажу с дисками» с другой стороны, чтобы увидеть все приключенческие игры. Такие игры прекрасно продаются женщинам в возрасте, и они им нравятся. Игровой рынок теперь не ограничен возрастом от 18-ти до 25-ти, или 35-ти. Он повсюду.
Однако, сейчас очень похоже, что стратегии далеко не так популярны, как раньше. Мне кажется, некоторые жанры всё равно пропадут.
Ох, они точно не пропадут. Сейчас выпускают много стратегий. В смысле, мы разрабатываем стратегии поскольку они интересны. Например, есть компании вроде Paradox Interactive, у которых есть собственная ниша среди фанатов состоящая из особенно хардкорных игроков, любящих их игры за то, как они сделаны. За наполнение игр, за то насколько они сложны. И они точно выживут. Людям нравится играть в Age of Empires Definitive Edition, что была выпущена всего недавно. И это игра из девятьсот девяносто… Восьмого? Кажется? Да. И ведь это стратегия.
Одна из моих любимым стратегий. Да.
Да. Они никуда не уйдут. РТСки, в смысле. Та же Цивилизация. Все эти игры вокруг, пока их продолжают разрабатывать.
В чём секрет создания успешной игры? Использование последних технологий имеет значение?
Ну, это помогает. Продвинутые технологии помогают. Но действительно хороший гейм-дизайн — причина, по которой люди играют. Они не играют в неё из-за движка. Хочется ли поиграть в игру, потому что она сделана на Unreal? Нет, вряд-ли. Ты играешь в неё из-за геймдизайна и задумки, того как она выглядит, и о чём рассказывает, что в ней можно делать. Это всё аспекты дизайна.
Какие у тебя любимые инструменты разработки или решения для игр? На текущий момент, и за всю карьеру?
Для рабочего процесса и общей продуктивности — Slack прекрасен. Для тикет-системы используем Assembla, но Jira также отличная. Мы используем Perforce для контроля лицензий из-за высокой скорости. Это наши основные программы что использует каждый в нашей студии. Для креатив-отдела это Photoshop, Maya, и, если знаете SyncScetch — ещё один отличный инструмент… Shotgun бесподобен для потока работ. Со стороны разработчиков мы используем Unity и VSCode, оба для Мака и ПК для внесения правок. Да и всё, в общем-то.
Для дизайна и расчетных таблиц мы часто используем Гугл Таблицы. Некоторые инструменты считывают информацию из Гугл-таблиц в сети и возвращают в игру.
В большей части это софт от Гугла. Мы используем презентации для дизайн-документов, и Гугл-таблицы для большей части информации. Для игр… В системе выброса лута, к примеру, но неважно.
Думаю, все бы хотели знать… Какую игру порекомендовал бы сам Джон Ромеро?
Hitman 2.
Hitman? Правда?
Hitman 2.
Одна из моих любимых игр!
Потрясающе.
И когда ты сказал о хардкорных игроках, желающих бросить вызов игре, я подумал о Хитмане!
Да!
Поскольку у него есть своя ниша из маньяков, что…
Ага. Эти челленджи.
… Выбивают максимальные очки на сложных уровнях.
Мастерство и безумные челленджи.
Я обожаю их.
Отлично.
Да-да. Я прошел все части.
Класс!
Да, я прошел все прошлые части, но они перевыпустили игру в 2016-м и создали абсолютно… Просто лучший дизайн в мире.
Ага.
Я ожидаю выхода Ghost Recon: Breakpoint. Сильно. И прямо… Дождаться не могу. Это будет потрясающе. Я люблю Ghost Recon. Люблю оригинальную игру, не фанат GRAW, но я знаю, что… Мне удалось поиграть в новую часть, и теперь не могу дождаться релиза.
Знаешь, сейчас выходят отличные игры, но в некоторые нужно слишком долго вникать после работы.
Да.
Ты слишком устал, чтобы разбираться.
Да, хочется поиграть…
Все эти механики…
Да-да. Типа «Мне нужно опять всё вспоминать?». Но… Тот же World of Warcraft был таким же. Там куча снаряжения, много квестов, играет личная мотивация, например, что именно ты хочешь делать в игре, и, если что-то происходит — игра требует высокой концентрации. И если тебе не нужна такая вовлечённость — ты играешь в другие игры не требующих внимания. Инди игры отличны для таких случаев, поскольку сейчас они проходятся за несколько часов. Например, Firewatch и другие эмоциональные проекты.
Да-да…
Знаешь, это игры для небольшого отвлечения. И…
И Hitman также можно отнести к ним.
О, да! Хитман прямо…
Особенно если ты знаком с серией, и говоришь себе — «Я просто хочу попробовать этот челлендж». Разве нет?
Да…
Тебе не нужно проходить миссию целиком.
Обычно привыкаешь за пару часов. Значит твой топ-лист это Hitman, Ghost Recon и… Может третья?
Инди-игры. Их очень и очень много.
А сейчас мы обратимся к группе профессиональных разработчиков в лице нашей аудитории.
Хорошо.
Пожалуйста, взгляни в камеру и расскажи, что тебя вдохновляет.
О, Господи… Что меня вдохновило?.. Pacman был причиной, по которой я занялся разработкой видеоигр. Его дизайн, напомню, что он вышел в 1980-м году, сильно отличался от остальных игр того времени.
1980-й это «Убей пришельца», черно-белые цвета, плохое звуковое сопровождение.
С выходом Pacman изменилось всё. Это была безобидная бродилка, абсолютно полный и совершенный дизайн, в который было сложно поверить, и он показал мне что геймдизайн не имеет границ. Там столько всего, что именно это вдохновило меня на создание игр.
Хороший совет также не будет лишним для желающих присоединиться к игровой индустрии.
Начинайте с простых игр, без разброса. Не пытайтесь сделать что-то большое в начале. Напишите простую концепцию, попробуйте реализовать её и закончить до конца. Вы узнаете насколько трудно завершить проект, и будете следить за амбициями.
В русской Википедии ты записан как Джон Ромеро. Но я читал что твоё настоящее имя — Альфонсо.
Да, Альфонсо.
Так почему тебя называют Джон?
Потому что имя моего отца также Альфонсо, и, если бы ты сказал «Ал!» — мы бы оба откликнулись. Моя мама решила называть меня Джон, поскольку мой отец уже был Алом. Теперь меня все знают, как Джона.
Хорошо, так это из детства.
Да, это из детства. Моя мама звала меня Джонни.
Спасибо за интервью! Я буду рад снова встретиться с тобой в России.
Класс! Обязательно встретимся на TechTrain.
На TechTrain и также в офисе нашей команды RUVDS!
Отлично!
Большое спасибо!
Да, спасибо!
P.S. И последний совет от Джона Ромеро:
Способ как удержать уровень ошибок на низком уровне — нужно записать несколько строк рабочего кода и затем протестировать их. Проверь их до самых мелочей. Убедись, что всё работает. Затем запиши ещё несколько строчек, делающих что-то. Повторяй проверку каждый раз, выстраивая код по ступеням. Не стоит работать пол часа, а затем тестировать код. Он будет полон багов. Просто пиши по несколько строк и проверяй, будут ли они работать. Так ты сделаешь очень устойчивый код.
Автор: ru_vds
