4. Специальные алгоритмы.

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

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

a) По координате "героя" из упакованной карты игрового поля извлекаются координаты комнаты и дверей.

б) На экране строится соответствующая комната из символов, которые выдает специальный знакогенератор.

в) По номеру комнаты из специальной таблицы сценария извлекаются данные о наличии в ней объектов и предметов.

г) По их номерам и координатам они изображаются на экране.

д) Если в таблице программных переменных есть "монстры", находящиеся в данный момент в этой комнате, то изображаются и они.

Для создания трехмерного эффекта теневой графики я разработал специальный алгоритм, который назвал "шэдоу процессором". После того, как комната и весь ее внутренний антураж построены, на изображение накладываются полутоновые горизонтальные и вертикальные тени. На рис. 3 доказано, как все тени изображаются с помощью всего лишь двух элементов.

"Шэдоу процессор" позволил сэкономить еще изрядное количество памяти.

5. Проверка концепции.

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

Пришлось воплотить идеи в машинный код и проверить, как обстоит дело с быстродействием. Не сразу, но дело пошло. Работа оказалась неожиданно сложной. Только примерно через месяц я убедился в том, что экранное представление моих идей совпадает с тем, что я хотел получить. Теперь, закончив предварительные исследования и убедившись, что задача в принципе выполнима, я мог приступать к основному объему работ разработке программы в целом. Надо сказать, что в этот момент мне пришлось преодолеть массу искушений добавить в программу что то еще. Это было, конечно, возможно, но при таком подходе можно никогда не выйти из стадии предварительных исследований.

Дизайн программы.

Закончив с предварительными исследованиями, я перешел к проработке структурной диаграммы. В статьях "Профессиональный подход" (см. "ZX РЕВЮ" 91) мы уделили серьезное внимание тому, как создаются структурные диаграммы, зачем они нужны и чем они отличаются от алгоритмических блок схем. Там же мы упомянули и о том, что при всем многообразии игровых программ, структура их может оказываться удивительно похожей. Так случилось и в этот раз. Практически эта важная и ответственная работа превратилась в пустую формальность. Почти на 100 % подошла структура, ранее разработанная для

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

Машинный код.

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

Сейчас у меня уходит на создание такой программы примерно восемь месяцев. Это много, но я абсолютно все делаю сам. Тем более для меня очень важна экономия времени за счет использования большого количества проверенных процедур. И, надо сказать, многое мне удалось использовать. Процедуры верхнего уровня структурной диаграммы были вообще перенесены с минимальными доработками.

Основную трудоемкость, как ни странно, составило не программирование машинного кода, а борьба с разного рода мелкими неприятностями. Примерно месяц ушел на то, чтобы выловить все "жучки" в ассемблирующей программе. Я пользовался ассемблером "ОСР", а он регулярно разрушал мои таблицы меток. Еще столько же времени ушло на борьбу с механическими помехами (дребезг контактов на разъеме, через который подключались дисковод и принтер).

Но так или иначе, рано или поздно, наступает такой момент, когда перед Вами еще гора работы, а сделано уже так иного, что отступать нельзя. Вот на этой стадии мне и пришлось столкнуться с концептуальной проблемой, связанной с моим героем. Как оказалось, у меня на него осталось так мало места в оперативной памяти, что сделать приличного чародея я уже не мог. Как я ни экспериментировал, он меня не устраивал. Спас положение Эндрю Брейбрук, который предложил сделать героя лягушкой и тогда спрайт 16x16 получается намного лучше. В поисках приемлемой картинки для своей лягушки я перелистал несколько томов по биологии, неплохо ознакомился с жизнью земноводных и, самое главное, узнал, что лягушка по латыни звучит, как RANA. Так и родилось название игры RANARAMA.

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

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

Однажды рано утром я сидел и экспериментировал с клочками бумаги на столе, пытаясь придумать оригинальное изображение титульного экрана с названием игры, выполненным крупными буквами. В этот момент меня осенило. Я понял, что аркадной вставкой может стать перестановка букв в слове RANARAMA. Как оказалось, название программы очень соответствует этой задаче. Поскольку в слове есть 4 буквы "А", то аркадная вставка получилась скорее динамичной, чем головоломной. Первые же эксперименты убедили меня в том, что это решение удачно. Труды предыдущего месяца были сняты с полки и полетели в мусорную корзину, а через пару дней проблема перестала существовать.