Каждый, кто работал с Asm/Editor, скорее всего, несёт такие же глубокие эмоциональные шрамы на себе как и я! Редактор был невероятно медленным, отладчик работал на ладан, а мне приходилось удалять комментарии и использовать оверлеи в пару килобайт (RAM'ы было не много и все переменные не вмещались, поэтому использовалась техника оверлеев — разные группы переменных размещались по одинаковым адресам. Понятно, что одновременно переменные с разных секций использовать было нельзя, причём не только переменные с одним адресом, но и вообще переменные из разных оверлейных секций.) для того чтобы уместить весь код. Создание игры, которую я назвал Myriapede, заняло три месяца. У меня до сих пор хранятся эскизы и наброски: миллиметровка, исчерченная разноцветными ручками и с шестнадцатеричными значениями цветов, тщательно выписанных на поля. Цвета я подбирал наобум: у меня был только дешевый черно-белый экран, и я заходил к другу на пару часов в гости, чтобы проверить и подстроить значения цветов на его телевизоре.
Atari Program Exchange (карманное издательство) объявило конкурс с главным призом в $25000. Весь семестр я прогуливал университетские занятия и занимался только Myriapede. Я закончил игру с запасом в неделю или две и отправил на конкурс.
Через несколько недель пришло письмо из Atari, в котором они сообщали: во-первых, их очень впечатлила моя работа, но, во-вторых, она была очень похожа на Centipede (ну да, так и было) и поэтому они вынуждены забраковать её. Подтекстом шло, что они вероятно засудят меня в случае попытки продажи игры. Я был раздавлен. Закрывая для себя эту тему, отнёс пару копий в местный кружок по интересам. Думаю, что игра получила распространение оттуда, и я слышал, что она нравилась людям («лучшая программа 1982 года» или что-то типа этого).
Еще спустя какое-то время, я получил звонок из Atari: они приглашали меня на собеседование. Меня потряхивало от возбуждения. Я вылетел к ним, и каждому интервьюверу показывал Myriapede. И всегда на этом месте беседа замирала. Перед началом игры они вроде как просто оказывали мне внимание — «окей, парень, ты написал игру» — но после старта они втягивались в процесс и я напоминал им, что мы вообще-то на собеседовании! Одним из собеседующих был автор оригинальной Centipede и он сразу на месте сказал, что моя версия лучше.
Предложение о работе поступило через пару недель. Atari обязалось перевезти всё моё барахло, которое занимало комнату целиком, в Калифорнию. А я полетел сразу и провёл две недели в отеле, пока ждал прибытия своих вещей. Компания действительно сильно хотела меня заполучить!
В то время существовало две популярных игры на аркадных автоматах, которые я просто-напросто не мог выносить — Zaxxon, тупой и скучный скролл-шутер, и Donkey Kong — громкий, бессмысленный и раздражающий. И, конечно же, причина почему я им был нужен в Калифорнии — портирование Donkey Kong'а! Пройдя через приступы безысходности (и притворного энтузиазма перед боссами), я стиснул зубы до скрипа, взял тюбик четвертаков и провёл кучу времени перед небольшим аркадным автоматом в отеле, играя в DK, чтобы узнать эту игру очень и очень хорошо.
Здесь необходимо объяснить как же работало в Atari отделение по портированию игр с аркадных автоматов. По существу, парни из отдела маркетинга договаривались о лицензии на распространение «Имярек» от ИгроДела на картриджах для компьютеров Atari. Всё. В этом и состояла вся сделка.У нас не было никакой помощи от разработчиков оригинала. Ни листингов, ни бесед с инженерами, ни проектной документации — ничего. Фактически, нас вынуждали покупать собственный аркадный автомат и научиться играть в эту игру (кстати, поэтому я и играл в отеле — нашу копию игры еще даже не привезли!).
Так что я играл в Donkey Kong столько, сколько мог и начал обыгрывать идеи. Написал 25-30 страничный дизайн-документ, в котором игра разбивалась на модули и срок разработки оценивался в 5 месяцев (это было в ноябре 1982), и, волнуясь, принёс его моему боссу, Кену, Был ли документ достаточно хорош? Или же они отправят меня паковать свои вещи как непрофессионального проектировщика и программиста-любителя?
«Мы в полном восхищении от твоего ТЗ», сказал Кен. А я просто перечислил объекты в игре, написал немного псевдо-кода для некоторых ключевых игровых модулей и предполагал, что это лишь задел для настоящего ТЗ! Но все вокруг воспринимали этот документ как вполне законченный. И вроде как мне нужно только написать код, согласно ему. Было жутковато.
«Отдел маркетинга ждёт игру к Рождеству», выдал Кен. А я, сделав аккуратные подсчеты, подошёл к отметке в 150 рабочих дней. Не было ни единого шанса портировать игру за пару недель, но я отчетливо чувствовал прессинг. От безделья (из всех забот у меня был только поиск квартиры и размещение своих вещей по прибытии), я проводил почти всё своё время на работе. Я первый раз провёл всю ночь без сна, подымая планку всё выше и выше, дабы идти в темпе с парнем в офисе напротив меня, который также работал всю ночь напролёт. Столовая обеспечивала трехразовое питание.
Замечательно то, что если ты втягиваешься в проект так сильно, то с какого-то момента он начинает писаться самостоятельно, а ты вроде как просто плывешь рядом с ним. Твоя жизнь разделена на работу и всякую скучную чепуху — сон и приём пищи. Да, я знаю, звучит адом, но на самом деле это потрясающе весело. Мне было что-то около 21, и даже если бы мне не платили, то я бы всё равно занимался чем-нибудь подобным бесплатно.
Для кросс-разработки мы использовали миникомпьютеры MV/8000 от Data General. О точно такой же машине Tracy Kidder написал книгу Soul of a New Machine. Несмотря на то что это был не VAX с Unix'ом на борту (что было бы предпочтительнее для меня), всё равно окружение было достаточно удобным и содержало несколько хороших утилит (хотя и не было Emacs'a!). Мы использовали портированную для MV/8000 версию Atari Macro Assembler'a, и она была куда лучше невыразимо медленного Assembler/Editor, в котором я писал Myriapede. Но нам приходилось заливать весь код на системы разработки со скоростью в 9600бод, поэтому, ближе к завершению проекта, время обработки моих запросов к системе становилось серьезной проблемой, особенно с учетом 40 или 50 моих коллег, с которыми я делил MV/8000 в течение дня. Вспоминался нагруженный мейнфрейм у меня в университете. Я часто оставался допоздна, и где-то часов с шести вечера машины начинали работать довольно шустро (5 минут на ожидание вместо примерно часа).
В первый же мой день по прибытии в офис, после введения в курс дел, я нашёл запакованный Atari 800. Я быстро его собрал, проверил что он заработал и отправился за кофе.
Когда я вернулся, девушка из отдела снабжения стояла в дверях. «Ого», она ахнула, «ты знаешь как собрать компьютер! А я как раз должна была это сделать.»
Ага, спасибо, но разве не должен ли здесь каждый иметь такой навык? Подключить и настроить Atari не самая простая и очевидная задача, но и совсем не сложная.
Тревожный звоночек… Первый сосед по офису не знал как настроить свой компьютер. Вообще-то, он не знал ничего, как выяснилось позже. Его наняли для работы над Dig Dug и он был в полной растерянности. Мне приходилось обучать его всему, включая программированию на ассемблере, работе железа Atari, как скачивать разную информацию, как отлаживать. Было невесело.
Такая ситуация проходила красной ниткой через мою работу в Atari. Новичкам не обязательно было знать как выполнять их работу, а я тратил время на то, чтобы помочь разобраться в вещах, которые они должны были уже знать прежде чем приступить к работе. Тактика найма сотрудников была неидеальной.
Я писал на Си уже несколько лет, и поэтому разработал что-то вроде диалекта Си для описания работы модулей. Сначала я набрасывал несколько страниц не этом высокоуровневым псевдо-Си, затем тратил полдня на «компилирование» его в ассемблер 6502. Иногда получалось так, что довольно большой участок кода работал с первого раза! Но в общем, это был довольно пугающий опыт.
Другой приобретенный опыт заключался в понимании того, что комменатрии почему-то важны. Я видел куски кода операционных систем Atari (включая исходники ОС для 400/800) и они были вполне понятны и красивы. Но большинство игровых исходников, исходящих из отдела потребительского софта, были ужасны, кучи мусора: почти без комментариев, без какого-либо понимания того, что происходит. Просто листинги, состоящие из LDA/STA/ADD, набора букв, и, возможно, случайная метка, которая имела осмысленное имя. Другими словами, полностью неподдерживаемый код! В большинстве ситуаций для игровой индустрии это вполне норма: почти никакой код ни разу не переиспользовался или выносился в библиотеки (за исключением хорошо-отлаженных процедур от подразделения Atari Coin-Op, выполняющих математические операции и работу с монетными механизмами в аркадных автоматах).
Думаю, что DK лучше всего откомментирован среди всех потребительских продуктов, выпущенных Atari (Super Pacman еще круче, но он не поступил в продажу). Пользователи не видят комменты, в отличие от других инженеров, которым полезно изучить что же ты написал. К примеру, прыжки Марио рассчитываются согласно простым физическим законам движения, а уравнения записаны в исходниках, хорошо отформатированы и ты всегда можешь проследить откуда берутся эти магические выражения в коде. После выпуска DK, мой коллега заполучил копию кода, провёл неделю в чтении и заявил что он просто шокирован («Я не знаю как ты смог всё это напечатать. Точно не за пять месяцев! Когда я увидел код, связанный с движением, моя челюсть упала на пол.»). Это вогнало меня в краску! Исходный код должен одновременно служить развлечению и образованию.
Donkey Kong поступил в продажу в середине марта 1983. Я смутно припоминаю небольшую вечеринку на работе по этому поводу, но в тот момент я больше всего радовался тому, что всё это кончилось.
Технические детали. Kong использует графический режим $E (192 строк изображение на 160 столбцов). Когда загружался уровень, задний фон прорисовывался единожды. Бочки и остальные существа выводились на экран через xor (у меня был код, отвечающий за построение масок и перерисовку, но он оказался слишком медленным). Марио состоял из нескольких игровых объектов (я думаю, их было три). Призовые вещи (зонтики, ...) тоже относились к игровым объектам. Вывод графики с помощью xor'a меня раздражал, но большинство не парилось, а некоторые считали, что так делать даже круто! (при отрисовке цвет пикселя фона xor'ился с цветом пикселя объекта, когда нужно было объект убрать с этой позиции, просто xor'или обратно, и цвет фона восстанавливался).
Brad Fuller создал все звуки. Mona Lundstrom работала над значительным куском графического дизайна (но я перерисовал большую часть). За «кат-сцены» отвечал другой инженер, чей код мне пришлось полностью переписать (он изначально хотел использовать Форт и не понимал, что игра не может позволить отдать половину пространства на картридже под интерпретатор форта только ради того, чтоб облегчить ему жизнь).
В пике DK занимал 20 килобайт, но нужно было посадить его на диету, ибо картридж вмещал 16Кб. Многие изображения были сжаты (заметьте, к примеру, что Kong симметричен). В конце концов, я выгрызал всего лишь несколько байт в день, а игра вышла с запасом всего, может быть, в десяток свободных байт.
Я оставил паскалху, но она не стоит усилий, чтобы её находить. К тому же, я не помню как до неё в точности добраться (что-то типа умереть на уровне «куча песка» с тремя жизнями и заработанными очками более 7000).
Настраивая сложность, я замедлял игру и просто убеждался, что она проходима. Некоторые траектории движения объектов случайны, но ограничены в таких пределах, что всё равно можно их пройти, если ты достаточно быстр.
На первое собрание в отделе я шел с уверенностью в будущем Atari. Хотя я многого не понимал, но основная мысль менеджмента заключалась в том, что продажи замедляются, прибыль резко сокращается, и компания должна пройти через реструктуризацию чтобы остаться прибыльной.
Здание напротив было первой ласточкой: Atari использовала его для производства игровых консолей 2600. Они перенесли производство зарубеж и уволили большинство людей с местной фабрики.
Небольшие сокращения в отделе маркетинга. Маленькую группу портирования из 8 программистов со мной в их числе перевели в небольшое строение, отстающее довольно далеко от всех главных зданий Atari, и мы были фактически изолированы от того, что происходило. Но даже с такого расстояния, мы видели что дела идут не очень хорошо. Игровая индустрия сильно пошатнулась, и Atari сгружала миллионы непроданных картриджей на свалки. Все те ошибки, которые до поры до времени покрывались бешеным успехом, внезапно вспыли и сильно ударили по компании.
Моя коллега наконец-то закончила Robotron. По просьбе, она сделала три версии ROM-образа, различающихся адресацией в ROM. К сожалению, Q/A отдел смог проверить только 2 из них. Угадаете какую же версию Atari отправила в производство и какая же из версией имела критический баг? Я видел как страдали инженеры-железячники, когда понимали что дешевый логичский вентиль может починить игру. В этом случае только несколько байт были некорректны. К итоге, Atari выбросило картриджей на $200000 в мусорку.
У меня было чувство, что похожие ошибки возникали постоянно. Кроме того, всё это дополнялось тем, что игры просто-напросто не продавались. Ориентируясь на time-to-market метрику, маркетинг Atari вынуждал инженеров писать неотшлифованные скучные игры. И эта практика обернулась против них же! Людям надоело играть в одни и те же игры по старым мотивам.
Массовые увольнения и реорганизации проходили раз в несколько месяцев. Нашу группу перевели в угол здания для подразделения Coin-Op: консолидация ради экономии средств. Я в то время работал над Super Pacman'ом, но никого это не заботило, поэтому я ушёл с головой в процесс, и проделал хорошую работу над игрой.
В конечном счете, Jack Tramiel выкупил части Atari, которые ему были нужны, а я оказался втянут в работу над Atari ST, но это уже другая история.
Комментарии (13)
SenGaJi
29.09.2016 15:42+1мне понравилось.
интересно будет почитать и другую историюя оказался втянут в работу над Atari ST, но это уже другая история.
biaks
30.09.2016 04:20Хорошо читается. На одном дыхании, спасибо.
Еще не покидала мысль при чтении: как бы выглядела эта история, если бы это происходило в то же время, с таким же умным парнем, но в советском союзе)VMesser
01.10.2016 01:42В Советском Союзе это было бы так.
Парню 21 год, его распределили на ящик считать адские уравнения для якобы проектирования РЛС (хотя скорее всего он делает пустышку для выработки объёма, прикрывая чей-то начальственный зад), дали секретность, и теперь ему уже никогда не судьба сгонять дикарём за шпротами в прибалтику. Под написание «кода» выдали скудную методичку и младшего научного сотрудника в помощь, а также новейший секретный перфоратор для секретного перфорирования секретных перфокарт. Ну и халат, конечно же, потому что он работает в ВЦ с ЭВМ. Хотя работает с ЭВМ не он, а специальные операторы ЭВМ в таких же белых халатах, которым он протягивает через окошко перфокарты и через какое-то время, по записи, в порядке расписания, получает результат вычислений. После чего повторяет эти операции до бесконечности. Основным содержанием его рассказа являются курьёзы на предприятии и истории про обмен спирта на новейшие винилы Бони-м и Спейс.
По сути всё то же самое, что и в сттье, за исключением отсутствия какого-либо общественно-полезного творчества, потому как вся страна который год занята очередными похоронами генсека, перераспределением кабинетов и проектированием надвигающейся перестройки.
Сам я в это время даже ещё не родился, но по совокупности рассказов от технической интеллигенции той эпохи, могу судить, что было как-то так.Crevice
02.10.2016 17:59Очень интересно было бы послушать про разработку ПО для игровых автоматов времен СССР.
В детстве меня очень впечатлил автомат «Городки». Это была настоящая копьютерная игра в отличии от большинства других механических игровых автоматов.
tormozedison
01.10.2016 11:43Маленькая хитрость: если бы он купил TRS-80, ему бы не пришлось ходить в гости к владельцу цветного телевизора и что-то там проверять.
gsaw
Ничего не поменялось за тридцать с лишним лет. Ну только названия. А так все тоже самое — коллеги не знаюшие как сохранить файл, программа с интерпретатором занимающая все 64 гигабайта оперативки, Перевод разработки в куда нибудь с глаз долой. Баги потому, что релиз менеджмент это запустить ant скрипт и бинарник отослать заказчику, а потом удивляться, что тот опять зол, «я же все 25 багов починил с последнего релиза в прошлую пятницу!?»
frog
Кое-что всё же изменилось. Раньше код который невозможно было поддерживать был вынужденной мерой, так как он таким становился после оптимизаций необходимых ввиду постоянной нехватки памяти. Причём он был на ассемблере, что само по себе читаемость не улучшает. Это были объективные проблемы (см. например рассказ человека, который уже в наше время писал Frogger для Vectrex: http://enlight.ru/post/9436 ).
Сейчас объективных препятствий писать адекватный читаемый код уже нет — т.е. зависит уже от человека.
kgbplus
Зато сейчас читаемость кода компенсировалась общей сложностью. Нет?
frog
Я думаю что нет. Во-первых, большая игра, написанная на ассемблере — не менее сложна, чем какое-нибудь большое веб приложение, скажем (крайние случаи типа фейсбука наверное брать не будем).
Достаточно посмотреть на исходники того же Frogger'a (при том, что это маленькая и простая игра).
Во-вторых, что значит компенсировалась сложностью?
kgbplus
Ну я имел в виду, что даже если например современный Asassin's Creed и написан гораздо адекватнее, но в виду общей сложности игры (по сравнению с Donkey Kong например) в коде разобраться не проще.
gsaw
Да, но никто не будет в одиночку разбирать весь код ассасина. Специально обученные люди занимаются звуком, графикой, ресурсами, сетью. Красиво, стандартно и понятно написать свой кусок кода вполне реально.
В принципе и раньше красиво оформленный код можно было написать. Хоть возьми Си, хоть ассемблер. Я часто встречал куски кода на ассемблере корошо прокомментированные, разбитые на логические блоки, на которые было любо-дорого посмотреть и легко использовать. Были и обратные примеры. Сильная оптимизация не оправдание плохо оформленному коду. Чаще всего это просто лень. Процессор и вообще компьютер не какой-то там магический ящик. Это инженерное устройство. Почему бы не написать нормальный инженерный код к нему.