Введение

Если у спросить у разработчиков игр об их первом опыте создания игр, многие скажут о редакторе игры, в которую они играли. Чаще всего они находили его по привлекающему к себе внимание имени наподобие «editor».

Задолго до появления Unity 3D такие компании, как id Software, Epic, 3D Realms, Blizzard и BioWare выпускали вместе со своими играми инструменты, надеясь на то, что это позволит людям создавать контент, увеличивая размер сообщества и срок жизни игры. Многим людям не просто нравилось пользоваться этими инструментами — они стали для них дверьми в индустрию игр. Созданный ими контент позже стал частью их резюме.


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

В этой статье мне выпала честь поговорить с Джоном Ромеро Romero о TEd, тайловом редакторе, созданном id Software, с помощью которого удалось выпустить 33 игры.

Первая встреча с редактором уровней

Дэвид Лайтбоун: Здравствуйте, Джон. Спасибо, что нашли время пообщаться со мной!

Джон Ромеро: Да никаких проблем!

ДЛ: Прежде чем мы обсудим TEd, я хочу сделать шаг назад: в начале 80-х было очень мало редакторов уровней, поставлявшихся вместе с игрой. В вашем интервью из книги Honoring the Code, вы говорили, что генератор рельефа из игры Pegasus ][ был одним из первых редакторов уровней, с которыми вам удалось поэкспериментировать. Можете рассказать об этом опыте?
ДжР: Впервые я увидел Pegasus ][ в Sierra College, в кабинете с Apple. Это была одна из первых программ, которые я увидел на Apple. Когда я играл в неё, то заметил, что там есть опция генерации рельефа. Я подумал: здорово, что разработчики встроили такой инструмент для генерирования геймплея.

Забавно думать сейчас, что это была одна из самых первых игр, позволявших создавать моды. Я
в первый раз видел что-то подобное, и подумал, что это замечательно. Смешно, но я никогда не задумывался: «Эй, а почему в других играх такого нет?», я просто не ожидал этого от игр!

TEd, Tile Editor

ДЛ: Ну ладно, давайте перейдём к разговору о TEd.

[Пока мы говорили, я запустил два DOSBox, чтобы можно было смотреть на TEd и Deluxe Paint]



Первое, о чём я хочу поговорить — это заставка TEd. На ней написано Deluxe Paint for Tile Maps. Любой, кто немного знает об истории id Software, в курсе, что Адриан Кармак пользовался Deluxe Paint…

ДжР: Им пользовалась вся игровая отрасль.

ДЛ: Точно! Так вот, первое, что мне бросилось в глаза — верхние меню Deluxe Paint и TEd очень похожи, и внешне, и по ощущениям. Пытались ли вы сделать нечто знакомое для пользователей Deluxe Paint, или использовали какие-то части, взятые из Deluxe Paint?

ДжР: До id Software я написал в SoftDisk несколько инструментов для PC. Я написал программу Pixel Puzzle Maker, инструмент создания паззлов для игры Softdisk под названием Pixel Puzzler. Я написал раскрывающееся меню для Pixel Puzzle maker, а затем внёс в него некоторые изменения. Кажется, в Softdisk я писал и другие инструменты для PC, а когда я занимался работой для id, то, кажется создал ещё один, потому что было очень просто сделать эту систему с раскрывающимся меню.

Она не была основана на Deluxe Paint, потому что я никогда не пользовался Deluxe Paint, но я считал, что гораздо проще работать с раскрывающимся меню, чем с целой кучей горячих клавиш… хотя у нас тоже было много горячих клавиш!



ДЛ: Кстати, о горячих клавишах: я заметил и другие сходства. Сегодня мы привыкли, что Control-Z — это отмена действия, но в те времена, по крайней мере, в случае с Deluxe Paint и TEd, отмена выполнялась нажатием клавиши «U».

ДжР: [смеётся] Ого. Это я придумал?

ДЛ: Да! Вот, смотрите, я заполнил квадраты, нажимаю «U» и выполняется отмена…

[Я рисую несколько тайлов, а затем нажимаю «U» для отмены предыдущего действия]

ДжР: [смеётся] Мило.

О, и кстати, вы запустили его в DOSBox, и если поскроллите экран, то это будет очень медленно по сравнению стем, как всё работало на 386 в те времена. Программа просто летала.

ДЛ: Правда? Не шутите?

ДжР: По какой-то причине DOSBox сильно замедляет её. EGA-скроллинг использует режим Latch mode, который в те времена был очень быстр, приходилось едва касаться клавиш, иначе проскроллишь всё. Поэтому сейчас вы видите странную очень замедленную версию.

[Примечание автора: Джон рассказал про EGA-скроллинг с использованием Latch mode на StackExchange: http://gamedev.stackexchange.com/questions/6488/how-did-they-make-the-screen-move-in-dangerous-dave]

ДЛ: Ну ладно, итак, вы сказали, что в TEd было множество горячих клавиш. Во времена использования TEd часто приходилось читать файл справки, чтобы понять, как пользоваться такими инструментами.

ДжР: Да, разумеется. Думаю, некоторые ещё помнят WordStar, который был просто кошмарным сборищем горячих клавиш.

ДЛ: [смеётся]

ДжР: В те времена мы играли в Ultima, а в Ultima использовалась каждая буква клавиатуры, то есть было несложно запоминать подобные вещи.




[Примечание автора: я раскопал руководство к Ultima 1, и Джон оказался совершенно прав… почти к каждой клавише клавиатуры было привязано действие!]

ДЛ: Это точно! Итак, на том этапе развития игровой индустрии, когда дело доходило до дизайна уровней, вам приходилось брать лист миллиметровки и размещать тайлы, а затем вводить их в компьютер.

ДжР: Ага.



[Примечание автора: После этого интервью Джон прислал мне рисунок на миллиметровке для созданной им игры Mach Six. Кроме того, здесь можно прочитать статью с Gamasutra о том, как Nintendo использовала миллиметровку для разработки уровней первой Zelda на NES]

ДЛ: Так на каком же этапе id Software решила, что необходимо создать TEd?

ДжР: Когда я работал в 1988 году над Dangerous Dave, мне нужно было создавать для него уровни, и я подумал: «Почему бы не использовать саму игру и не позволить ей самой создавать уровни, которые можно будет сохранять». Именно так я и поступил с Dangerous Dave.

Когда Джон Кармак увидел это — а он работал на Apple II — то был очень впечатлён, потому что он привык использовать текст для обозначения графики. Когда мы впервые решили создавать что-то вместе, я написал TEd 1.0, и через несколько месяцев он эволюционировал в TEd 5.0, который использовался в разработке 33 выпущенных игр.



ДЛ: Ого… Когда вы говорите о 33 выпущенных играх, то имеете в виду не только созданные id проекты, например, серии Commander Keen и Wolfenstein, но и внешние, к примеру, Rise of the Triad?

ДжР: Конечно! Ещё и Corridor 7, и игры для Gamer's Edge: Shadow Knights, Slordax, Dangerous Dave and the Haunted Mansion, Rescue Rover 1 и 2, BioMenace… целую кучу игр!

ДЛ: То есть правда, что TEd не только использовался с видом сбоку для создания двухмерных сайдскроллеров, но и с видом сверху для создания трёхмерных шутеров от первого лица?

ДжР: Точно. Именно в TEd 5.0 создавались все эти игры.



ДЛ: Хорошо. Мне интересно следующее: в какой-то момент вы с ребятами из id Software решили перейти от двухмерных к трёхмерным играм. Вы вообще обсуждали мысль о создании нового редактора вместо TEd?

ДжР: Да, мы довольно быстро решили этот вопрос. Мы подумали: «Для представления уровня будет использоваться 2D-матрица. Отлично, мы просто применим для этого TEd». Да, вот и всё! [смеётся] Это было очень просто.

ДЛ: Я хотел бы задать ещё один вопрос: Том Холл в файле справки к Rise of the Triad цитирует вас: «Рано или поздно программисту удаётся написать то, чем он может гордиться — остроумную, элегантную, быструю как молния процедуру, которая становится эталоном для кода других программистов. Однако это не относится к процедуре заливки TEd. Этот медленный и глупый алгоритм заполняет одну плоскость данных мучительно медленным способом. Нажмите ESC, когда он зависнет».

ДжР: [смеётся]



ДЛ: [смеётся] Так почему вы так написали? Есть ли у этой процедуры заливки какая-нибудь история?

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

[Пока мы говорили, я запустил процедуру заливки Flood Fill, и TEd вылетел в DOSBox с ошибкой «Divide by zero»]

ДжР: [смеётся]

ДЛ: [смеётся] Совершенно верно! Это забавно, потому что я немного поиграл с редактором перед интервью и подумал: «Не понимаю, почему он так сказал, у меня всё работает отлично!»

JR: [смеётся] Ну, у нас он тоже никогда не выдавал ошибку деления на ноль… Думаю, проблема в том, что вы не выбрали тайл. Программа вываливается, когда вы пытаетесь выполнить заливку без тайла.

[Я перезапустил TEd, который отобразил диалоговое окно установки графики]



Видите это окно установки графики? TEd позволяет редактировать карты в CGA, EGA и VGA. Он перемещает все графические данные в память XMS, чтобы можно было извлекать их из XMS при переключении графических режимов. То есть если ваша игра поддерживает все три графических режима, она позволит загружать эти тайлы. Вы можете загрузить VGA-тайлы, чтобы когда переключитесь в режим VGA, все они загружались и находились в памяти.

ДЛ: Да, я читал, что это была достаточно революционная для того времени функция.

ДжР: Да. Ещё я реализовал такую возможность: если где-то на уровне находится курсор, то можно нажать Alt-L, после чего загрузится игра и вы окажетесь прямо в том месте уровня. Давайте проверим, работает ли это.

[Я перемещаю курсор на уровень и нажимаю Alt-L. Появляется сообщение об ошибке]

ДЛ: [смеётся] И об этом тоже я хотел с вами поговорить…

ДжР: [смеётся]


ДЛ: Когда я экспериментировал с TEd, я сделал скриншот этой ошибки, потому что хотел спросить вас про неё. Сегодня таких сообщений не увидишь в Photoshop или Maya… [смеётся]

ДжР: Конечно, конечно! Этот инструмент был написан только для меня и Тома [Холла].

ДЛ: Разумеется! Об этом я и хотел спросить вас: вы написали это сообщение об ошибке специально для Тома?

ДжР: Конечно! Оно было только для Тома. Я бы ни за что не совершил такую ошибку. [смеётся]

ДЛ: [смеётся] Представляю его первую реакцию.

ДжР: О да, он расхохотался.

[Потом Джон показал мне, что нужно добавить имя исполняемого файла игры после исполняемого файла TEd, чтобы редактор знал, что запускать при нажатии Alt-L]

ДЛ: Ого, заработало!

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

ДЛ: Да, это вполне логично. Но мне кажется, что читерство — один из аспектов, которые привлекают людей в разработку игр. Знаете, хочется иметь возможность менять уровни, чтобы подшутить над друзьями…

ДжР: Да, конечно! [смеётся]

Будущее инструментов разработки

ДЛ: Я хотел бы закончить разговор обсуждением будущего инструментов разработки игр.

В начале 90-х, когда я только начал создавать игры с помощью инструментов, написанных вами и другими разработчиками, это было не всегда просто: приходилось читать файл справки (если он вообще существовал). Требовалась определённая доля технических знаний, и часто нужно было изучать простейший скриптинг или программирование. Однако в то же время можно было нарисовать какой-нибудь 8-битный пиксель-арт, и он выглядел бы почти достойно. Также мы могли гибко настраивать внешний вид уровней, как нам угодно.

Сегодня есть такие инструменты, как SnapMap (редактор уровней нового Doom), которые гораздо более доступны всем, но в них гораздо меньше гибкости. Там есть визуальный скриптинг, то есть пользователям не приходится изучать написание скриптов или программирование. В то же время создание достойно выглядящих в игре ресурсов для большинства людей — недостижимая задача.

Мой вопрос к вам заключается в следующем: вы считаете, что некоторые из этих современных инструментов не дают приходящим в индустрию людям достаточной гибкости, или же думаете, что это просто эволюция разработки игр — точно такая же, как переход от кодирования на ассемблере к компиляторам — и это просто движение нашей индустрии вперёд?



ДжР: Это естественное развитие. Группа разработчиков SnapMap — это люди, чья карьера началась с игры в Doom и с использования TEd. Компания, которая встроилась внутрь id Software, называлась Escalation Studios. Она делала Doom Resurrection. Я знаю этих людей больше двадцати лет. Они очень хардкорные геймеры, прошедшие Doom World, а потом и Quake World. Они были с компанией со времён, когда мы делали Doom. Это люди, чья жизнь долгие годы была посвящена созданию уровней.

То есть SnapMap — это естественная эволюция инструментов, какими они нужны людям, а не консоли. Очевидно, что они делали Doom не с помощью SnapMap, но SnapMap — это отличный способ для людей, никогда не занимавшихся дизайном уровней, хотя бы понять, нравится ли им это занятие, и если да, то они смогут найти себе более мощные инструменты. Возможно, не в этой версии Doom, а, например, в движке Source или в любом другом движке, которых сейчас много, типа Unreal. Так что SnapMap даст им представление о том, каково это.

ДЛ: Да, это кажется логичным. То есть это не замена, это первый шаг на пути развития.

ДжР: Точно, потому что самое сложное — создание фрагментов SnapMap. Поэтому если люди могут заниматься этим в PC-версии Doom, то они будут представлять, каков настоящий дизайн уровней, хотя бы на примере этих модульных фрагментов.

Совет Джона программистам инструментов

ДЛ: В последнем своём вопросе я хочу вернуться к тому, с чего мы начали: ретроспективы классических игр.

Иногда в играх есть хитрости и трюки, которые со временем оказываются утерянными. Думаю, что самое интересное в ретроспективах классических игр на GDC в том, что люди восстанавливают утерянные знания. Люди вроде вас, давно находящиеся в индустрии, могут передать эту информацию людям, которые только приходят в индустрию.

Итак, какой бы совет вы могли дать современным разработчикам инструментов?

ДжР: Во-первых, вам нужно писать инструмент для пользователя этого инструмента. Например, если вашим инструментом будет пользоваться дизайнер уровней, то именно для него вы делаете этот инструмент. Сделайте его как можно более простым и добавьте туда как можно больше нужных ему возможностей. Также важно уделить время на то, чтобы самому попробовать пользоваться инструментом и понять, что вас самого в нём раздражает.

ДЛ: Совершенно точно.

ДжР: Кроме того, очень часто, когда дизайнеры просят добавить какие-то возможности, программисты инструментов не делают им шагов навстречу и не спрашивают их: «Зачем вам эта возможность? Чего вы хотите с её помощью добиться?» Мы можем обернуть функционал в удобную обёртку, чтобы с ним было просто работать. Иногда разработчики просто накидывают компоненты… и всё, до свидания, дизайнеры уровней, разбирайтесь сами!

ДЛ: Верно! [смеётся]

ДжР: Также здорово, когда программисты инструментов и пользователи находятся в одном помещении и инструмент создаётся при как можно более интенсивном общении между этими двумя командами.

ДЛ: Согласен.

ДжР: Наконец, не нужно писать ничего на ассемблере. [смеётся] Я имею в виду, что очень сложно обеспечивать поддержку инструмента, написанного десяток лет назад с использованием языков или функций жёстко привязанных к платформе. Стремитесь абстрагировать функционал, чтобы можно было заменять его в дальнейшем. У меня самого возникала эта проблема с TEd, когда в 2001 году мне потребовался редактор тайлов для создания уровней новой игры. Я взглянул на код TEd 5.0, написанный в 1991 году, и подумал «Да уж, никак и ни за что не буду использовать этот код...» [смеётся]

ДЛ: [смеётся]

ДжР: Не забывайте, что инструменты живут дольше, чем игры.

ДЛ: Это замечательный совет. Огромное вам спасибо, я очень ценю то, что вы уделили время на общение со мной.

ДжР: Спасибо!