Когда я подготовил такой набор технических требований к программе, я почувствовал реальность выполнения этой задачи как с точки зрения объема занимаемой оперативной памяти, так и с точки зрения быстродействия процессора.

Предварительные исследования.

1. Дизайн экрана.

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

художественное впечатление;

объём расходуемой памяти:

быстродействие.

Всеми результатами я остался доволен. Особенно привлекательными мне показались добротные, прочные стены, разделяющие комнаты.

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

2. Раскладка оперативной памяти.

Закончив с первым этапом, я перешел ко второму. Поскольку у меня уже был определенный опыт, я поначалу воспользовался той картой оперативной памяти, которая сложилась после завершения программы "Quazatron", благо структура у этих двух программ была похожа. Я выделил участки памяти для хранения карты игрового поля, для хранения нужной мне графики, для всевозможных таблиц, массивов, для области рабочих процедур и программных переменных.

Как обычно, вскоре я обнаружил, что мои амбиции заходят слишком далеко и не все, что я запланировал, можно "втиснуть" в спектрумовское ОЗУ. Так, например, я хотел иметь 24 типа различных движущихся "монстров", но пришлось урезать их количество до 14.

3. Упаковка данных.

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

Я подготовил несколько различных методов, поэкспериментировал с ними и, наконец, остановился на наиболее оптимальном.

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

Единицей измерения на карте я выбрал блок из четырех знакомест (размер 16x16 пикселов).

Для комнат в первом байте я решил хранить координату левого верхнего угла комнаты, я во втором байте размер этой комнаты. Вы знаете, что поскольку байт не может принимать значение больше 255, то мне нелегко было бы сделать достаточно большое игровое поле. Максимум 16x16 блоков по 16x16 пикселов, то есть, чуть больше одного экрана. Это, конечно, недостаточно, поэтому координата левого верхнего угла задается не как абсолютная, а как относительная, то есть это "смещение" начала N ой комнаты относительно N 1 ой комнаты. Тогда все стало на свое место (пример см. на рис. 1)

Пришлось "помудрить" и со вторым байтом, задающим размер комнаты. В итоге я остановился на том, что у меня в программе будет ограниченное количество разных типоразмеров комнат и второй байт будет задавать собственно не размер комнаты, а номер ее типоразмера. Соответствующая рабочая процедура потом по этому номеру найдет в таблице данных истинный размер комнаты (пример см. на рис. 1).