Тем не менее это было все, что я мог выжать из Apple II, а Роберте нужно было продолжать работу.
Мне пришлось столкнуться с серьезными ограничениями. По-прежнему нужно было уложиться в крошечные размеры дискеты, а Роберта хотела добавить в Wizard and the Princess еще больше локаций (фонов или комнат). Чтобы обойти эту проблему, я попросил Роберту создавать векторные картинки так же, как и при работе над Mystery House, но затем щелкать мышью в любом месте любой обведенной контуром части картинки и задавать цвет заливки. По сути, это был тот же самый процесс, что в детских книжках-раскрасках, но с гораздо большими ограничениями. Была и хорошая новость: раскрашивание картинок с помощью этого приема практически не увеличивало их размеры, зато значительно улучшало их внешний вид. Все, что мне нужно было сохранить на дискете, – три байта (числа): расположение строки и столбца, где Роберта оставляла указание «нужен цвет», а затем еще одно число – код цвета, который она хотела получить. Если у меня была точка внутри замкнутого контура, я мог распространять цвет от нее во все стороны, пока не натыкался на какой-нибудь другой элемент. Например, Роберта с помощью VersaWriter рисовала ствол дерева, затем щелкала мышью в этом месте и выбирала коричневый цвет. Пока нарисованный ствол дерева представлял собой замкнутый контур, я мог алгоритмическим способом залить его нужным цветом.
К сожалению, мы наткнулись и на другие проблемы, уже непреодолимые. Я пытался победить ограничения того, какие цвета могут находиться рядом друг с другом. В пределах одного байта компьютерной памяти я мог закодировать только фиолетовый или зеленый, или же оранжевый и синий. Когда Роберте понадобилось показать на экране зеленое дерево на фоне голубого неба, случилась беда.
Вторая проблема заключалась в том, что Apple II мог создавать только шесть цветов. Что бы я ни делал, он выдавал лишь черный, белый, оранжевый, синий, зеленый и фиолетовый.
Чтобы обойти эту проблему, я смешивал разные цвета – так создавалось впечатление, что их на экране больше. Это была бы отличная идея, будь разрешение экрана повыше. Но на мониторе Apple II было только 280 горизонтальных точек (мы, компьютерщики, называем их пикселями, знаете ли) и 192 вертикальные точки. И это еще хуже. Чтобы получить цвет, я мог использовать только половину пикселей. Для сравнения, на всем экране Apple II было всего 53 760 пикселей, тогда как на моем мобильном телефоне (iPhone) – 2 740 500 пикселей, каждый из которых может принимать любой из миллионов цветов.
Wizard and the Princess, первая «цветная» приключенческая игра Sierra
На лицевой стороне вкладыша к Wizard and the Princess гордо заявлено: «В НАСТОЯЩИЙ МОМЕНТ ЭТО САМАЯ СОВЕРШЕННАЯ ГРАФИЧЕСКАЯ ИГРА, КОГДА-ЛИБО НАПИСАННАЯ ДЛЯ КОМПЬЮТЕРОВ APPLE».
Мы не лгали, но… ничего не поделаешь. Не могу сказать, что я горжусь результатом.
Покупатели были в восторге от цветной картинки! Я быстро понял, что Роберта наткнулась на золотую жилу – надо было ее разрабатывать по-крупному.
Мы немедленно запустили в разработку еще несколько приключенческих игр.
Роберта была в лучшем случае начинающей разработчицей. Тем не менее она практически в одиночку создала хит номер один среди тогдашних компьютерных игр. Она закончила разработку Wizard and the Princess и сразу же после нее выпустила следующую игру – Mission Asteroid. Роберта пахала изо всех сил, но часов в сутках у нее от этого больше не становилось.
Hi-Res Adventure #4. Ulysses and the Golden Fleece
Может быть, разработкой приключенческих игр мог бы заниматься кто-то еще?
У нас уже было несколько наемных работников, которые сидели за компьютерами и копировали диски. И один из них, Боб Дэвис, подошел ко мне и сказал, что у него есть идея для игры под названием Ulysses and the Golden Fleece.
Я дал ему полную свободу, и вскоре у меня появилась еще одна игра на продажу. Отлично!
– ИНТЕРЛЮДИЯ –
(Небольшое отступление, чтобы я мог вклинить что-нибудь другое)
Глава 13. Советы программистам
Умный человек разрешает проблему. Мудрый избегает ее.
Альберт Эйштейн
ПРИМЕЧАНИЕ. Эта глава адресована программистам и тимлидам. Остальные читатели, возможно, предпочтут (а может, и не предпочтут) перейти сразу к следующей главе.
Есть на свете одна книга, которую я бы порекомендовал всем, кто хочет построить карьеру программиста, или тем, кто хочет заниматься яхтингом, да и всем остальным тоже: «Дзэн и искусство ухода за мотоциклом»[17]. Эта книга оказала огромное влияние на мою карьеру разработчика программного обеспечения, а спустя десятилетия – еще и капитана яхты.
Тем не менее я не могу утверждать, что по-настоящему прочитал эту книгу. Я пытался сделать это несколько раз и действительно прочел ее от корки до корки, но так и не смог до конца понять все, что прочел. Автор этого творения, Роберт Пёрсиг, был профессором в университете и писал так, как можно ожидать от профессора. Его роман автобиографичен – читается он как блог о путешествии по стране на мотоцикле, которое Пёрсиг совершил со своим сыном Крисом. Как пишет сам автор, эта книга имеет очень мало отношения к дзэн-буддизму или уходу за мотоциклами. Вместо этого книга посвящена скорее его личным размышлениям на тему отношения к окружающему миру.
Я мыслю в категориях «вынесенных уроков», и для меня было не так важно, о чем на самом деле книга. Главное – что удалось вынести из ее прочтения.
Что именно я оттуда вынес:
• Как анализировать проблему.
• Как разбить большую проблему на мелкие части.
• Как определить, что по-настоящему важно.
Моя философия разработки программного обеспечения выросла из чтения книг Пёрсига (он написал и еще одну книгу, «Лайла»[18] – своего рода продолжение первой книги; в «Лайле» он рассказывает о яхтах и путешествиях). В частности, эта книга помогла мне начать думать о двигателе или даже о программе как о комплексе подсистем, у каждой из которых есть какая-то определенная функция или цель.
Например, когда я думаю о дизельном двигателе, я думаю о нем не просто как о цельной «силовой установке». Я пытаюсь думать о нем как о комплексе систем: топливная система, система впуска воздуха, система охлаждения, система смазки, выхлопная система и т. д. Если вы можете смотреть на что-то и воспринимать это как комплекс подсистем, становится легче диагностировать проблемы и понимать, как работают отдельные компоненты.
Это привело меня к правилу номер один в разработке программного обеспечения:
Чем меньше, тем проще.
Кен Уильямс
Первый шаг в анализе любой проблемы – разбить ее на ряд более мелких частей.
Мало у кого столько опыта работы с самыми разными программами, сколько есть у меня. Я работал над сотнями программных продуктов и уже больше сорока лет непрерывно разрабатываю программное обеспечение.
Чем меньше и проще будет ваша программа, тем больше вероятность того, что она заработает как надо с первой попытки. Многие программисты гордятся тем, что находят сложные решения проблем. Я видел, как они часами мучаются над куском кода, пытаясь заставить его работать быстрее или потреблять чуть меньше байтов. Им, похоже, нравится писать код, где можно выпендриться мастерством программирования.
К сожалению, есть на свете и организации, в которых подобные подвиги ценят и вознаграждают. Но я смотрю на это по-другому.
Прежде чем я расскажу об этом, давайте на секунду отвлечемся вот на что.
Любую работу следует начинать с определения ее цели. Если вы пишете новый код, подумайте о том, как часто он будет выполняться. Подумайте о том, предназначена ли программа для использования внутри компании, или ей будут пользоваться клиенты. Подумайте о том, часто ли этой программе нужна будет поддержка. Подумайте об объеме обрабатываемых данных и т. д. Попытайтесь представить себе, какую роль будет играть этот код в продукте в целом.
Пример: я видел, как программисты целыми днями корпят над оптимизацией какого-то кода,
