01.07. ЧЕМОДАН ЭЛЕКТРОННЫХ СОЛДАТИКОВ

ГЛАВА СЕДЬМАЯ. ЧЕМОДАН ЭЛЕКТРОННЫХ СОЛДАТИКОВ

Собрав такую коллекцию отдельных миниигр, можно поставить, наконец, вопрос о упомянутом во второй главе (ТЕМА #61, АБЗАЦ #665) "скелете" игры. Конечно, сейчас каноническим является игровой мир в виде совокупности большого количества простых элементов, но раньше все было не так. От концепции "компьютерного противника" в виде некого "сверхобъекта" отказаться было трудно. Ведь должна же компьютерная игра быть компьютерной, а не просто переносом на экран обычного гексово-жетонного объекта.
Т.е. берем HAMMURABI и учим его командовать армией...

STAR TREK

Листинг - JPG/RAR, 1.58Мб.

Как и положено родоначальнику, игра очень проста. И очень похожа на "B-1 NUCLEAR BOMBER".
Тот же цикл вокруг ВЫБОРА команд, тот же тригонометрический калькулятор, тот же разруливающий финальный блок.
Главное отличие - предельно формализованная вселенная, позволяющая любые расширения (ТЕМА #28, АБЗАЦ #167). Это сделало STAR TREK тем же, чем TALISMAN является для игр настольных - универсальной базой игр-конструкторов.

10 КОММЕНТАРИИ
220 ЗАГОЛОВОК
260 МАССИВЫ ДАННЫХ И ПАРА ФУНКЦИЙ
1230 ПРИГЛАШЕНИЕ
1320 ВХОД В НОВЫЙ КВАДРАНТ
1980 ^^6420
1990 ЭНЕРГИИ ДОСТАТОЧНО^2060
2020 "НЕХВАТКА ЭНЕРГИИ", ^6220
2060 ВЫБОР КОМАНДЫ: 2290,1980,3990,4250,4690,5520,5680,7290,6270
ВСЕ ИСКЛЮЧЕНИЯ ИЗ КОМАНД - ^1990
2290 ПЕРЕМЕЩЕНИЕ КОРАБЛЯ, ТЕЧЕНИЕ ВРЕМЕНИ, РЕМОНТ, ^1980
В Т.Ч. ВЫХОД В СЛЕДУЮЩИЙ КВАДРАНТ, ^1320
2590 ПЕРЕМЕЩЕНИЕ КЛИНГОНОВ
2700 ^^5990
3900 ПОДПРОГРАММА ИЗМЕНЕНИЯ E И S^
3990 ДАЛЬНИЙ РАДАР, ^1990
4250 ФАЗЕР, ПО ВСЕМ КЛИНГОНАМ РАЗОМ, ^1990
4650 КЛИНГОНЫ КОНЧИЛИСЬ^6370
4670 ^^5990
4690 ТОРПЕДЫ, НАДО УКАЗЫВАТЬ КУРС, ^1990
5110 КЛИНГОНЫ КОНЧИЛИСЬ^6370
5210 ПОПАДАНИЕ В ЗВЕЗДУ
5280 ПОПАДАНИЕ В БАЗУ (ВОЗМОЖЕН ПРОИГРЫШ - ^6270)
5490 ^^5990
5520 УСТАНОВКА МОЩНОСТИ ЩИТОВ, ^1990
5680 РЕМОНТ, ТЕЧЕНИЕ ВРЕМЕНИ, ОТЧЕТ, ^1990
5990 ПОДПРОГРАММА СТРЕЛЬБЫ КЛИНГОНОВ^
6090 ЩИТЫ ПРОБИТЫ^6240
6140 ПОВРЕЖДЕНИЯ ОТСЕКОВ
6210-6370 КОНЕЦ ИГРЫ
6330 НОВАЯ ИГРА^10
6420 БЛИЖНИЙ РАДАР (ОДИН КВАДРАНТ), СТАТУС^
6490 ПРОВЕРКА СТЫКОВКИ С БАЗОЙ
7280 ВЫБОР КОМАНДЫ КОМПЬЮТЕРА: 7530,7890,8060,8500,8150,7390
7390 КАРТА ГАЛАКТИКИ (СТАТИСТИКА), ^1990
7530 ДОП.ВХОД ДЛЯ ИМЕН
7630 ВЫВОД СТАТИСТИКИ
7740 ВЫВОД ИМЕН
7890 "ХОД КАМПАНИИ", ^5690
8010 "ВСЕ БАЗЫ ПОТЕРЯНЫ!", ^5690
8060 РАССЧИТАТЬ КУРС НА ВСЕХ КЛИНГОНОВ, ^1990
8150 ДОП.ВХОД ДЛЯ ЛЮБЫХ 2-Х ТОЧЕК
8500 ДОП.ВХОД ДЛЯ КУРСА НА БАЗУ
8580 ПОИСК ПУСТОГО МЕСТА НА КАРТЕ КВАДРАНТА^
8670 ЗАПИСЬ НА КАРТУ КВАДРАНТА^
8780 ИМЯ ОТСЕКА^
8820 СВЕРКА С КАРТОЙ^
9010 ИМЯ КВАДРАНТА^

Все, в общем-то, очевидно. Особенно, то, что BASIC провоцирует программиста писать код как попало. Почему один код выделен в подпрограмму, другой продублирован, а третий доступен путем переходов с "указанием обратного адреса"? Вплоть до установки флага "невхода в цикл", перехода внутрь цикла и выпрыга из него по флагу, не доходя до NEXT (см. 8150).
***

Можно также заметить, что калькулятор вытащен из программы наружу и игроку позволено кое-что считать самому.
***

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

АТАВИЗМЫ ПРОГРАММИРОВАНИЯ

Забавно наблюдать, как одни и те же решения все возвращаются и возвращаются на каждом витке развития программирования. Диалектика или инерция мышления?
***

Побочные эффекты преобразования типов.
Поборники Объектно Ориентированного Программирования все верят, что, если придумать достаточно адекватные внешнему миру типы данных-объектов, то большинство действий с ними совсем не надо будет программировать. Они, якобы, сами запрограммируются, исходя из внутренних свойств объектов. Чаще бывает, однако, наоборот - свойства мешают и порождают побочные эффекты.
Что, конечно, не мешает их использовать. Например, здесь.

5920 ... PRINT ... INT(D(R1)*100)*.01

т.е. округление числа используется для нормализации его вывода - две цифры после запятой.

Еще один трюк:

7700 PRINT RIGHT$(STR$<Z(I,J)+1000),3);

Печать числа с ведущими нулями.

Встречаются и сложные предосторожности "на всякий случай":

475 DEF FNR(R)=INT(RND(R)*7.98+1.01)

Чего они тут боятся? Что INT(RND(R)*8 )+1 даст 9?
***

Тригонометрия.
Тут все совсем плохо. Казалось бы, на то и компьютер, чтобы считать честно, но здесь стоит явная заглушка. Например, приращения координат при единичном перемещении (в зависимости от курса - C1) считаются по формуле:

3110 X1=C(C1,1)+(C(C1+1,1)-C(C1,1))*(C1-INT(C1)): ...
3140 X2=C(C1,2)+(C(C1+1,2)-C(C1,2))*(C1-INT(C1)): ...

Здесь массив C() содержит единичные вектора, соответствующие "розе ветров", причем, с обычной для квадратных сеток проблемой ускоренного движения по диагоналям, т.к. длина вектора (1,1) больше длины вектора (1,0).
Расчет курса (обратная процедура) сделан так же, да еще с кучей проверок, какая компонента вектора длиннее и в какую примерно сторону вектор указывает (см. 8060).
***

Еще один пример сложных данных - обработка строк.
Конечно, BASIC позволяет свободно размещать, перемещать и обрабатывать строки в памяти, совершенно не заботясь о том, что это "байтовые массивы переменной длины", но программисты привыкли хранить строки именно в массивах, и прямая "функциональная" работа с ними кажется слишком нудной:

9010 REM QUADRANT NAME IN G2$ FROM Z4,Z5 (=Q1,Q2)
9020 REM CALL WITH G5=1 TO GET REGION NAME ONLY
9030 IF Z5<=4 THEN ON Z4 GOTO 9040,9050,9060,9070,9080,9090,9100,9110
9035 GOTO 9120
9040 G2$="ANTARES":GOTO 9210
9050 G2$="RIGEL":GOTO 9210
...
9110 G2$="POLLUX":GOTO 9210
9120 ON Z4 GOTO 9130,9140,9150,9160,9170,9180,9190,9200
9130 G2$="SIRIUS":GOTO9210
9140 G2$="DENEB":GOTO9210
...
9200 G2$="SPICA"
9210 IF G5<>1 THEN ON Z5 GOTO 9230,9240,9250,9260,9230,9240,9250,9260
9220 RETURN
9230 G2$=G2$+" I":RETURN
9240 G2$=G2$+" II":RETURN
9250 G2$=G2$+" III":RETURN
9260 G2$-G25+" IV":RETURN

"Структурный" программист наверняка бы засунул эти строки в списки (мол, возьми строку #18 и добавь суффикс #24). Конечно, если мы берем имена "из функции", а не "из массива", географию можно было бы сделать и посложнее, менее регулярной, подобно "ОРЕГОНСКОЙ ТРОПЕ".
Атмосфера игры поддерживается строками-репликами персонажей одноименного сериала, в основном, комментирующими промахи командира.

Впрочем, и BASIC-программисту никто не запрещает использовать массивы строк. И, даже, использовать байтовые массивы. Например, в ВЫБОРЕ комманд:

710 A1$="NAVSRSLRSPHATORSHEDAMCOMXXX"
...
2060 INPUT"COMMAND";A$
2080 FOR I=1 TO 9:IF LEFT$(A$,3)<>MID$(A1$,3*I-2,3)THEN2160
2140 ON I GOTO 2300,1980,4000,4260,4700,5530,5690,7290,6270

Присутствует и "строковая арифметика:

440 ... X$="":X0$=" IS "
...
1200 ... IF B9<>1 THEN X$="S":X0$=" ARE "
...
1260 PRINT"   ON STARDATE";T0+T9;"  THIS GIVES YOU";T9;"DAYS.  THERE";X0$
1270 PRINT"  ";B9;"STARBASE";X$;" IN THE GALAXY FOR RESUPPLYING YOUE SHIP"

***

Подобно "плиточным платформерам" здесь тоже попытались использовать одни и те же массивы и для рисования, и для расчетов взаимодействия нарисованных объектов.
Так, есть "карта квадранта" - строка Q$ по три символа на позицию (выводимая на "экран радара") и совершенно жуткий строковый калькулятор для нее: подпрограмма СВЕРКА С КАРТОЙ (8820) - проверяет стоят ли в данной позиции именно эти три символа, ЗАПИСЬ НА КАРТУ КВАДРАНТА (8670) записывает в позицию новую тройку, а ПОИСК ПУСТОГО МЕСТА НА КАРТЕ КВАДРАНТА (8580) методом тыка ищет позицию, в которой стоят пробелы. Через эти три операции выражаются операции перемещения объектов (корабля, звезд, базы, клингонов) и проверяются контакты. Например, перемещение клингона описывается как вызов 8670 для затирания текущей позиции, затем - 8580 для поиска нового места, и снова 8670 для рисования в новом месте.
К сожалению, этих трех операций не всегда достаточно и работают они с жуткой избыточностью. Вместо простой проверки, что здесь стоит, нужно вызвать 8820 со всеми возможными тройками символов... местоположение клингонов приходится дублировать в другом массиве и т.д.
***

Но, в общем, BASIC работает с строками гораздо естественнее, чем с обычными арифметическими массивами, обозначающим координаты объектов. Все эти проверки на пересечение границ квадрантов и попадание в звезду запутают кого угодно.
Да и хранение карты галактики (массивы G$() и Z$(), второй - для исследованного пространства) в виде набора трехзначных чисел (первая цифра - клингоны, вторая - базы, третья - звезды) вызывает жуткие проблемы преобразования туда-обратно. Хранить в символьном виде было бы проще.
***

Конечно, в "платформерах" и "симуляторах" мы уже встречались с необходимостью заполнять большие массивы данных до начала игры, но здесь и без всякой графики приходится генерировать достаточно сложный мир игры, причем, в отличие от AKALABETH подразумевается, что наличествует некий баланс исходных чисел, делающий игру интересной.
Другой, связанный с массивами данных, прием состоит в том, что карты квадрантов не сохраняются при уходе из них, а при повторном заходе генерируются заново. Сохраняются только общие статистические данные - число клингонов, баз, звезд.

ПОДРОБНОСТИ АЛГОРИТМА

ВСЕЛЕННАЯ: 8*8 квадрантов, каждый разбит еще на 8*8 позиций - секторов. В среднем: клингонов в 2% квадрантов - 3, в 3% - 2, в 15% - 1; базы в 4% квадрантов (не меньше 1). Звезд - 1-8 на квадрант. Времени (дней) дается на игру не меньше числа клингонов.
КЛИНГОН. Сила - 101-200.
КОРАБЛЬ. Начальная энергия - 3000. Запас торпед - 10. Пополняются на базах (достаточно стоять рядом). Отсеки соответствуют командам, их повреждение ограничивает команды.
КОМАНДЫ: КУРС, БЛИЖНИЙ РАДАР, ДАЛЬНИЙ РАДАР, ФАЗЕР, ТОРПЕДЫ, ЩИТЫ, РЕМОНТ, КОМПЬЮТЕР. В угловых скобках - вызванные нашими командами ответные или фоновые действия.

- КУРС. Ввод направления - 1.-9. (по розе ветров: 1.0 - Восток, 2.0 - Северо-Восток, 3.0 - Север, ... 8.0 - Юго-Восток, 9.0 - опять Восток). Скорость - 0-8 (при повреждении двигателя - 0-0.2). Энергозатраты = [скорость*8]+10 (недостаток может быть покрыт за счет исправных щитов, но не более 10). Попытка сдвинуться на число квадратов, равное скорости. Могут помешать звезды и границы вселенной, начало нового квадранта. Продолжительность = min(1, скорость), при попытке пересечь границу квадранта - 1. <Движение клингонов> <Регенерация>
- Б.РАДАР. Выдача карты квадрата и состояния. Проверка стыковки с базой.
- Д.РАДАР. Выдача статистик по соседним квадрантам.
- ФАЗЕР. Мощность = затраты энергии (при повреждении компьютера умножить на 0-1). Для каждого клингона в квадранте: удар = мощность / число клингонов / расстояние * 2-3. Если удар <= сила клингона * .15 - ничего. Иначе - уменьшить силу клингона на удар, при занулении - уничтожить. <Стрельба клингонов>
- ТОРПЕДЫ. Направление - 0-9. Затраты энергии - 2. Торпеду останавливает звезда или граница квадранта - без последствий, клингон или база - уничтожаются. <Стрельба клингонов>
- РЕМОНТ. Если работоспособно, то ничего (см. регенерацию), только статистика. Иначе - полный ремонт на базе, на которую уйдет времени: число ремонтируемых отсеков * 0.1 + 0.1, но не более 1.
- ЩИТЫ. Увеличивает величину защиты и на величину затраченной энергии в день. (Щиты менее 200 считаются опасно слабыми).
- КОМПЬЮТЕР. Одна из команд: КАРТА, СТАТИСТИКА, ПРИЦЕЛ, НАВИГАЦИЯ, ВОЗВРАТ, РЕГИОНЫ.
- - КАРТА. Вывод статистики обследованных квадрантов.
- - СТАТИСТИКА. Сколько осталось дней и клингонов.
- - ПРИЦЕЛ. Расчет торпедной стрельбы.
- - ВОЗВРАТ. Курс на базу в квадрате.
- - ДИСТАНЦИЯ. Расчет перелета из точки в точку.
- - РЕГИОНЫ. Показывает имена квадрантов.

ДВИЖЕНИЕ КЛИНГОНОВ. Случайное маневрирование в квадрате. <Стрельба клингонов>
СТРЕЛЬБА КЛИНГОНОВ. База защищает от огня. Удар по щитам с силой клингона / дистанция * 2-3. Сила клингона уменьшается в 3-4 раза. (Какое-то непонятное самоистощение.) Если щиты пробиты - корабль уничтожен. Если удар >= 20 и удар / щиты > 0.2 в 60% случаев повреждается один из отеков на удар / щиты + 0-0.5.
РЕГЕНЕРАЦИЯ. Все отсеки чинятся пропорционально времени (коэффициент 1). В 3% одно из устройств повреждается на 1-1.5, в 2% - чинится на 1-4.
***

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

УСЛОЖНИТЕЛИ

Итак, основная часть жуткого листинга на Python (TXT, 0.2Мб). 6 с лишним тысяч строк. По словам автора, автоматически сгенерирована из C-программы (доведена вручную) и имеет штук 20 дополнительных возможностей, которые можно включить/выключить установкой специальных флагов-опций.
Смотрим:

- Сразу бросается в глаза обилие списков констант: описывающих основные "физические константы", цвета, опции, отсеки, уровни сложности, события... Упаковывание констант в функцию, их использующую, тоже встречается, но реже. Разумеется, "структурный программист" не может считать достаточно "самодокументированным":

8780 REM PRINTS DEVICE NAME
8790 ON R1 GOTO 8792,8794,8796,8798,8800,8802,8804,8806
8792 G2$="WARP ENGINES":RETURN
8794 G2$="SH0RT RANGE SENSORS":RETURN
...
8806 G2$="LIBRARY-COMPUTER":RETURN

И пишет:

# Define devices
DSRSENS = 0
DLRSENS = 1
...
DDSP = 15
NDEVICES = 16 # Number of devices

Впрочем, иногда связь идет чисто "через комментарий", как в худших примерах BASIC:

"Choose a device to damage, at random."
weights = (
105, # DSRSENS: short range scanners 10.5%
105, # DLRSENS: long range scanners 10.5%
...
30, # DDSP: deep-space probes 3.0%
)

Оказывается есть и отдельный массив имен устройств, но его связь с константами уже совершенно неочевидна:

device = (
_("S. R. Sensors"), \
_("L. R. Sensors"), \
...
_("D. S. Probe"), \
)

Первая же попытка проследить хотя бы некоторые из этих констант проливает свет на причины ужасающего размера кода: Python-текст произведен из запутанного BASIC-кода путем его старательного "раскатывания в блин". Если, в "МАРИО" мы видели "матрешку" циклов, то здесь мы видим "елочку", имеющую по отдельной веточке для каждого мыслимого случая, причем никаких действий на пути от "ствола", практически, не предпринимается - только проверки условий.
Конечно, "елочка" не уменьшает числа ошибок (наоборот, увеличивает, т.к. все комбинации предусмотреть невозможно), но помогает программисту уменьшить их влияние на работу программы путем дополнительных проверок на опасных ветвях.
Как следствие, почти каждая из подпрограмм, посвященных какому-либо действию, по размеру равна всей BASIC-программе.

- А как же модульность/структурированность? Программное отображение структур отсеков, команд... Никак. Вот классы, с которыми мы имеем дело (за исключением чисто "внутрипрограммных"): coord (пара чисел), planet, quadrant, page (три числа - характеристика квадранта), snapshot (состояние игры), event (событие), enemy, gamestate (полное состояние игры), course, sstscanner - т.е. исключительно собранные в одно место наборы переменных для выполнения отдельных действий. А "игровые объекты" (за исключением врагов - enemy - и событий - event) размазаны по всему коду, как выше - отсеки. То, что мы называли "ООП - чтоб как у людей".

- Рассмотрим класс-объект enemy:

class enemy:
- def __init__(self, type=None, loc=None, power=None):
- - self.type = type
- - self.location = coord()
- - if loc:
- - - self.move(loc)
- - self.power = power
- - game.enemies.append(self)
- def move(self, loc):
- - motion = (loc != self.location)
- - if self.location.i is not None and self.location.j is not None:
- - - if motion:
- - - - if self.type == 'T':
- - - - - game.quad[self.location.i][self.location.j] = '#'
- - - - else:
- - - - - game.quad[self.location.i][self.location.j] = '.'
- - if loc:
- - - self.location = copy.copy(loc)
- - - game.quad[self.location.i][self.location.j] = self.type
- - - self.kdist = self.kavgd = (game.sector - loc).distance()
- - else:
- - - self.location = coord()
- - - self.kdist = self.kavgd = None
- - - game.enemies.remove(self)
- - return motion
- def __repr__(self):
- - return "<%s,%s.%f>" % (self.type, self.location, self.power)

Что мы видим?
Собственно, к классу относятся всего три операции: создания врага (сила, место, тип), перемещение в новое место, отладочная выдача. "Елочка" налицо: "перемещение" вызывается аж в трех случаях - первое выставление на игровое поле, собственно перемещение и убирание с поля. Какой "случай" имеется в виду, операция определяется аж тремя проверками. Причем, даже в таком огрызке уже есть дублирование проверок: __init__ проверяет loc и вызывает move, который опять проверяет loc. А, собственно, кода, который что-то делает - тут "кот наплакал". Нет даже намека на то как и куда происходит перемещение объектов.
С четвертой проверкой все еще хуже: если тип "T" - толианин - то он вместо себя оставляет не пустое место, а "космическую паутину". Вот она гадость - проверка в неожиданном месте - попробуйте найти все, что умеет толианин, и вам придется перелопатить всю программу (а это уже не сотни, а тысячи строк!).
Список типов врагов (и прочих космических тел) мы найдем только в самом конце кода:

def cramen(type):
"Emit the name of an enemy or feature."
if type == 'R': s = _("Romulan")
elif type == 'K': s = _("Klingon")
elif type == 'C': s = _("Commander")
elif type == 'S': s = _("Super-commander")
elif type == '*': s = _("Star")
elif type == 'P': s = _("Planet")
elif type == 'B': s = _("Starbase")
elif type == ' ': s = _("Black hole")
elif type == 'T': s = _("Tholian")
elif type == '#': s = _("Tholian web")
elif type == '?': s = _("Stranger")
elif type == '@': s = _("Inhabited World")
else: s = "Unknown??"
return s

Да-да, невзирая на все структурности, тип объекта обозначается той самой буквой, которая рисуется для него на экране, а совсем не указателем на "структуру его свойств".
Т.е. вывод очевиден, никого проку от структуризации программы мы не видим. Нам, по крайней мере, она не поможет. То, что добавлено в игру по сравнению с первоначальной версией, будем искать методом тыка.
Найдя следующий кусок о врагах, мы видим, например, 50 строк, потраченных на выяснение может ли враг покинуть квадрант (tryexit). Проверяется 12 условий (одно в цикле), и есть, по крайней мере, одна ошибка.
Такое усложнение вызвано желанием иметь много интересных разновидностей врагов. Враги отличаются не только силой, но и своим поведением, поэтому в любой процедуре "имеющей с ними дело" большая часть проверок посвящена выяснению, с каким врагом мы имеем дело и может/будет ли он использовать в данный момент свои специальные способности.
Следов какого-либо "искусственного интеллекта" я не заметил, только правдоподобно выглядящие "если ..., то ... с вероятностью ...". Нечто подобное нам предлагали запрограммировать в "ВОРОТИЛАХ".

- Конечно, больше всего нас должны заинтересовать события - event:

# Define future events
FSPY = 0 # Spy event happens always (no future[] entry)
# can cause SC to tractor beam Enterprise
FSNOVA = 1 # Supernova
FTBEAM = 2 # Commander tractor beams Enterprise
FSNAP = 3 # Snapshot for time warp
FBATTAK = 4 # Commander attacks base
FCDBAS = 5 # Commander destroys base
FSCMOVE = 6 # Supercommander moves (might attack base)
FSCDBAS = 7 # Supercommander destroys base
FDSPROB = 8 # Move deep space probe
FDISTR = 9 # Emit distress call from an inhabited world
FENSLV = 10 # Inhabited word is enslaved
FREPRO = 11 # Klingons build a ship in an enslaved system
NEVENTS = 12

Как они работают? Точно так же, как в "ЗВЕЗДНЫХ ТОРГОВЦАХ". "Жетоны" событий помещаются на "табло ходов"! Только два отличия: хоть время события назначается достаточно произвольно, его тип и место назначаются в результате действия противников и других космических объектов. Второе отличие - т.к. это игра не компьютерная, а не настольная игра, проверка того, что событие случилось, производится в момент обсчета "длительных" команд. Как в "БОМБЕРЕ".

- Еще одно нововведение - планеты. Они, во-первых, порождают новую цепочку команд для их исследования и организации добычи энергетических кристаллов. Во-вторых, они участвуют в событиях, например, захват их Клингонами и строительство там вражеских флотов.

Такая эволюция игры привела не только к росту "увлекательности", но и к смене, собственно, игровой концепции. Вместо игрока, вокруг которого вращается игровая вселенная, мы опять получили игрока, живущего во вселенной на общих основаниях. В исходной игре практически все внешние по отношению к игроку объекты создавались только по мере необходимости, в новой версии - они существуют уже сами по себе, независимо от него. И, даже, иногда обладают "свободой воли", как в не раз уже упомянутой статье Родионова.
***

Еще пример скелета игры, на этот раз, выдранного из игры ELITE (там на нем базировался трехмерый "симулятор космического полета") - TXT, 0.02Мб. Программа - модель очередного многопланетного рынка. Не будем еще раз вникать в механику ценообразования, хватит этой фигни. Посмотрим на скелетообразующую механику. Конечно, здесь опять видим избыточную структуризацию (программа-то - на языке C), с лишними пересылками данных.
Скелет строится, практически, как в STAR TREK - сначала buildgalaxy для, кто бы мог подумать, построения вселенной, затем - циклический повтор ввода-исполнения комманд (parser). Более того, хотя "машина вселенной" очень напоминает "ЗВЕЗДНЫХ ТОРГОВЦЕВ", ее состояние генерируется случайным образом "по ходу дела", на основании свойств товаров и свойств рынков (genmarket).
Из других интересностей - еще один вариант простого генератора чисел (myrand) и развитой калькулятор текстовых сообщений с использованием макрогенерации (goat_soup).
***

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



Вылитый "Сапер", только не "целочисленный". Числа означают потенциальную опасность самих клеток, а не их соседей. Но, ведь, мы можем комбинировать и изобретать свои правила...

В этом и плюс "скелета" - он не мешает экспериментировать. Хотим проверить, вполне ли соответствует алгоритм "Сапера" разумному выбору пути - пожалуйста!
***



Вот еще один космический бой - SPACE ACE 21 (TXT, 0.02Мб). Странные строки 71-82 - в кодировке компьютера TRS-80 гораздо симпатичнее (это отсеки кораблей):



Первое, что бросается в глаза - неожиданное использование псевдографики для рисования. И, если это можно так назвать, "заставка на движке игры" - строится и взлетает демонстрационный корабль.
Корабль может иметь до 21 (7 "этажей" по 3 отсека) отсека 12 типов: Armor, Bridge, Cargo, Disruptor, Engine, Fuel, Generator, Life Support, Missiles, Phaser, Sensor, Torpedo. 5 обязательных (Bridge, Engine, Fuel, Generator, Life Support) нужно иметь не менее, чем по одной штуке. Непосредственно за Engine обязательно должно располагаться пустое место (поэтому естественно поставить их на нижнем "этаже"). А Bridge естественно смотрится на верхнем этаже.

Для рисования трехмерного космоса на экране используется две проекции, а курс как и прежде вводится заданием углов (в объеме их нужно два - азимут и возвышение).
К счастью, и курс и скорость можно задавать не только в цифрах, но и в человеческих терминах: курс может быть проложен на вражеский корабль, на его базу, на свою базу, оставлен прежним; скорость можно задать максимальной/минимальной или прежней. Но считать, все равно, придется много: сложные взаимозависимости отсеков, ТТХ оружия...
По идее, это тот же HIGH NOON, только более сложный - "улица" получила новые измерения, поведение противников усложнилось, кроме двух кораблей-дуэлянтов в бою участвуют их базы. Атавизмом осталось введение команд по требованию программы, обязательно в порядке: отчет, направление, скорость, стрельба. И отсчет времени равными отрезками (а не от события к событию).

Программа написана в манере, которую достаточно сложно считать исконно бейсиковой. Сплошь подпрограммы по одной строчке (и, как же без них, есть в кодах процессора). По идее, это означает, что нормальный BASIC авторов игры не устраивает и они на нем написали свой язык программирования BASIC', к сожалению, слишком трудночитаемый. Язык BASIC' базируется на наборе переменных (а на чем же еще?): в O1, O2, O3 передаются параметры пищания, слово для впечатывания в строку - W и т.п. Впрочем, этот язык здесь не столь уж необходим, скорее, это такой выпендрежный стиль автора. Хотя, обращения к массивам им удалось инкапсулировать очень хорошо, нет как в STAR TREK этих жутких выражений с индексами по всей программе.
Программа работает в два прогона: при первом RUN загружаются кодовые процедуры и удаляются строки DATA, их содержащие (проверка номера прогона в начале строки 90).
Затем (после перезапуска) - заставка - строки 0, 90, 95. Да, да, всего три строки, зато, с кучей процедур (а, по сути - операторов нашего нового языка). Причем, активно используется способ сращивания хвостов - вызовов процедуры по GOTO вместо GOSUB, чтобы она по RETURN завершила, заодно, и того, кто ее вызвал. Из интересных операторов: 40 - строительство и выдача одного из 10 кораблей, 20 - постройка и выдача корабля по его "чертежу", 26 - выдача одного отсека. Остальные - разного рода пищалки и позиционирования, потом добавится еще мелочь для ввода/вывода.
После заставки следует блок ввода параметров (со строки 120) - ввод числа и имен игроков, выбор корабля для компьютера, выбор сценария (их целых три - предполагающих разную роль баз), решение играть в двух или трех измерениях. Создаются корабли игроков (проверяется правильно ли это сделано). Плотность использования подпрограмм в этом блоке уже поменьше.
Сам цикл игры начинается со строки 300. Сначала - ввод команд: 305 - отчет, 310 - направление, 330 - скорость, 340 - оружие. После (400) - их исполнение. К "операторам" ввода/вывода добавляются тригонометрические и прочих вычислений.
Со строки 500 - "искусственный интеллект".

УПРОЩАТЕЛИ


Очередной STAR TREK. Немножко другая вселенная, чуть-чуть другие команды.

Почему я отношу эту и последующие игры к упрощениям? По очень простой причине: взяв за основу известную программистскую игру, авторы ее слегка причесали/обрезали и выдают за окончательный продукт. А как раз отсутствие "окончательности" тут интереснее всего.
***


Например, в советском клоне "Звездный патруль" добавили реальное время. Для этого пришлось объединить все экраны в один (их некогда переключать) и упростить геометрию (убрать калькулятор). Правда, я так и не понял, играет здесь таймер роль напоминалки о бренности бытия или заставляет рулить быстрее.
***

Немного покопавшись в истории игры STAR TREK, обнаружил целое семейство "продолжений":


STAR FLEET - тоже самое, но в обобщенной вселенной "наши против зеленых";


STAR FLEET II - игра "за зеленых", добавлено немного графики и возможность высаживать десанты на планеты;


STAR LEGIONS - опять "за зеленых", практически одни наземные операции (зато - графика по поводу и без);


EMPIRE - совсем простая вселенная "наши против ненаших", только наземные операции, но очень похоже на STAR FLEET II.

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

ОПЫТ "ЛУНОЛЕТА"

Сравнивая игрок-центрированные и вселенно-моделирующие игры, мы упустили один момент. Сам корабль игрока может быть столь сложен, что может сам играть с игроком. (Кусок приведенный ниже немного отличается по стилю, т.к. написан уже очень давно и по другому поводу).
***

В рассматриваемых здесь играх интересна прежде всего разнородность объектов управления. Позже, осталось только два интерфейса (и соответственно типа объектов): "общий", реализуемый меню главного окна (СТРАТЕГИЧЕСКАЯ КАРТА, т.к. здесь я опять возвращаюсь к комнатной модели) и "частный", реализуемый контекстным меню отдельного "танка" (ПУЛЬТ). В те же далекие времена даже у стратегий наблюдался разнобой в сложности объектов.
Сразу бросается в глаза, что "общий" интерфейс во всех играх серии (кроме EMPIRE) привязан к некоторому сверхобъекту - космическому кораблю. Интерфейс сложный, состоящий из ПУЛЬТОВ, СТРАТЕГИЧЕСКОЙ И ТАКТИЧЕСКОЙ КАРТ. Однако, обычное для нас управление (тыкнуть мышкой в нужный орган) в ранних играх отсутствует. Для ввода команд используется текстовый набор.
Неоднородны и "частные" объекты - здесь, "танки", участвующие в наземных операциях. По сравнению с "CIVILIZATION", где подразделения сведены в более-менее строгую систему (не говоря уже о конструкторе подразделений в EMPIRE II), в EMPIRE - форменный винегрет. Можно условно разделить тамошние "танки" на совсем простые (армии и авиакрылья) и посложнее (города и корабли). Да-да, разнобой в подразделениях такой, что города не являются чем-то особенно выдающимся (ср. CIVILIZATION).
Армии тупые до безобразия - тупо ползают по карте с единичной скоростью и захватывают города (уничтожают армии врага) с вероятностью 50%. Управление авиакрыльями посложнее. И скорость у них побольше (4-5 единиц) и запас топлива ограничен (разбиваются не успев вернуться в города).
Корабли (не говоря уже о городах) обладают кучей самых разных особенностей - вместимостью, живучестью, скоростью, ударной мощью. По сути, вся стратегия игры сводится к строительству сбалансированного флота.
Итак, имеем сверхобъекты (один сложнее и красивее другого) и малые объекты (забавные своей разнородностью). Пытаться свести все к общему знаменателю, как в современных играх? Или, найти каждому свою КОМНАТУ? Если заводить речь о реализме модели, то безусловно, второе. Иначе придется строить полноценный симулятор жизни. Частные же модели вполне могут быть честными.
Не могу не упомянуть и еще об одном минусе "стандартизации", проявившемся уже в EMPIRE. Недоработанность СТРАТЕГИЧЕСКОЙ КАРТЫ привела к наличию кучи команд, отдаваемых как меню, так и кликами мышкой, цель которых - избежать выхода простых объектов из-под контроля: засыпания, потери фокуса, пропуска акции... Забавно, но, по мере развития жанра, число таких предохранителей все увеличивалось. В современных стратегиях можно практически "тыкать" куда попало, не опасаясь роковых последствий. Этакий Windows-стандарт: лишний клик дела не испортит. Вот и тыкаешь, как дурак, пока не сработает.

Еще одним явно проявившимся в серии отличием сверхобъектов (далее буду называть их сложными) от простых является разный подход к их "автоматизации". Если для простых объектов автоматизация сводится к простенькому программированию (приказам передислоцироваться, патрулировать, эскортировать...), то для сложных - сверхобъект дополняется управленческим "компьютером" для облегчения расчета сложных команд (например, торпедной стрельбы или прокладки курса).
Разделение объектов на простые и сложные также служит мне оправданием в деле размежевания ТАКТИЧЕСКОЙ И СТРАТЕГИЧЕСКОЙ КАРТ. Очевидно, что "при прочих равных", бой сложного объекта естественнее смотрится на ТАКТИЧЕСКОЙ, а кучи простых - на СТРАТЕГИЧЕСКОЙ КАРТЕ.
Посмотрим теперь на устройство наших объектов. Комнатная модель, вроде бы, позволяет все разложить по полочкам в компьютерной реализации, но как быть в настольной игре или книге-игре?
В настольных играх с простыми объектами проблем нет - фишки, как фишки. Все их особенные свойства без труда описываются правилами. Однако, со сложными объектами возникает проблема. Использование сложных органайзеров вполне допустимо, пока сложные объекты ассоциируются с игроком (см. "TALISMAN"), но требует введения игрока-банкира, при описании в виде сложного объекта "общеигровой обстановки" (см. "MONOPOLY"), или, даже, введения гейм-мастера.
Имеет ли это смысл? Может, сложные объекты допустимы только в играх на одного игрока? Т.е. мир, в котором "живет" игрок имеет смысл усложнять введением подобных монстров только тогда, когда мы хотим сделать сложность противником игрока. Зачем, например, банк в "MONOPOLY"? По моему мнению, он нужен только постольку, поскольку игра заведомо случайная и игрок не может полностью управлять своими объектами. Если игра полностью зависит от взаимодействия стратегий игроков, то вполне достаточно фиксации игровой ситуации изменениями позиции на игровом поле и изменениями настроения игроков.
Соображение здесь такое. Игроки, начинающие партию в случайную игру, каждый раз предвкушают, что в этот раз случайные числа сложатся в такую комбинацию, которая породит нечто очень интересное и незабываемое (при минимальном участии игроков), породит некую "новую сущность". А для этого необходимо как можно полнее учесть все случившиеся события в разнообразных накопителях и органайзерах. Впрочем, это только моя гипотеза.
Гораздо большее влияние на современные игры оказывает появление "промежуточных" объектов. Сложных, но присутствующих в большом количестве. Например, города в стратегических играх, начиная с "CIVILIZATION". В настольных играх ярким примером служат т.н. wargames. Каждая группа фишек-солдат на столе снабжается листочком подробного учета состояния подразделения, в который аккуратно заносятся все потери, траты боезапаса и изменения "морали". Причем, игры, в которых подобное отражается одним-двумя жетонами-маркерами ("ASL" или "DIRTSIDE II") клеймятся как "нереалистичные". Кроме того, что использование подобной механики не имеет никакого отношения к реализму, ничего сказать не могу.
Книги-игры, это игры для одного игрока (а нередко и того меньше - только для автора). Значит сложный объект, описывающий состояние вселенной и состояние игрока, здесь вроде бы уместен, как нигде. Простые объекты здесь обычно выступают двумя способами - как объекты, вступающие во взаимодействие со сложным объектом игрока (как Клингоны, атакующие Энтерпрайз в STAR TREK), и как трофеи-награды, которые копятся игроком (друзья и предметы в TALISMAN).
***

Целая "теория", обосновывающая моделирование сложных систем вместо того, чтобы заниматься сюжетом...
Почему мне кажется, что, если вселенную имеет смысл генерировать как можно более случайно (вокруг игрока), чтобы не хранить в памяти честно-трехмерную модель всего сущего, то "корабль" игрока, должен быть жестко, наоборот, структурированным? Причем, лучше, чтобы составные части "корабля" были не "данными" а "функциями"...
***

Начиная работу над "Лунолетом" (ТЕМА #43, АБЗАЦ #431), хотел сделать корабль как можно более модульным. Что-то вроде:


Смотреть надо не на планеты, хотя, я всегда хотел снабдить "Лунолет" иллюминатором, а на разные наборы кнопок на пультах.

Чтобы можно было постепенно добавлять к "Лунолету" модули - "Изменение гравитации", "Центробежные силы", "Сопротивление атмосферы"...
Пока речь шла о параметрах вселенной и вводе/выводе все было просто, однако, нарисовать чертеж корабля никак не получалось. Потом я понял, что это не требуется - проще представить корабль в виде функции, а его части в виде макросов.

БЕЗ ДИНАМИКИ ПРОЩЕ И СКУЧНЕЕ

А если, все-таки, строить "корабль" в данных?
Можно.
Помните, мы формулировали четыре игровых действия?

1. Изучение правил.
2. Изучение игрового мира.
3. Изменение игрового мира.
4. Изменение персонажа.

Мы просто описываем в виде структур данных те отсеки "корабля", при помощи которых выполняем эти действия.
И получаем...
... так называемые 4-Х игры: eXploration (исследование миров), eXploitation (освоение миров), eXpansion (развитие) и eXtermination (уничтожение конкурентов). По сути, с некоторой потерей "ортогональности осей" (для играбельности) это те же пп.1-4.

Конечно, XXXX-играм свойственны:
1. Рутина. Один из "X" обычно превращается в сложный ритуал, автоматическое повторение которого отнимает до 90% игрового времени. Например, строительство баз в "Deuteros".
2. Рудименты. Другой из "X" обычно остается бедным родственником, оставленным непонятно зачем в ущербном состоянии. Например, производство в "X-Com".
3. Эклектика. Совмещение разных "X" в одном флаконе приводит обычно к появлению жутких мутантов. Например, графика в "Reunion".
4. Несуразности. Для притирки "X" друг к другу обычно приходится идти на жуткие натяжки в правилах. Например, скорость размножения людей в "Millennium".

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

Кстати, дальше пойдя по пути разбиения действий игрока на смысловые группы, мы можем превратить в "Сапер" любую игру. Это позволит не только добавить в игру количественные оценки сюжета, но и, если надо генерировать его автоматически.

Сначала выбираем в нашей игре четыре "направления".
Например, для X-Com: 1 - чтение педии, допрос инопланетян; 2 - исследования; 3 - бои; 4 - строительство, производство, экипировка. Для платформера - деление экранов на: 1 - тренировочные; 2 - сюжетные; 3 - боссов; 4 - важных предметов...
Возможны и любые другие варианты "направлений", лишь бы "направления" были примерно "ортогональными": наступать-обороняться, действовать по внешним или внутренним линиям, торговать-производить... В какой теории вы чувствуете себя докой, ту и применяйте.

Приписываем нашим направлениям вектора: изучение правил - (-1,0); изучение мира - (1,0); изменение мира - (0,1); самосовершенствование - (0,-1).

Строим минное поле. Большое не надо. Допустим, 6*6 на шесть мин. Мин в точке (0,0) и ее трех соседях нет. Как и в точке (5,5). Выбор одного из игровых действий преобразуется в перемещение по выбранному направлению. Успешное перемещение играется как обычно. Наступание на мину - (почти) смертельная игровая неприятность. Выход за границу поля - топтание на месте. Победа - достижение точки (5, 5).

На простом уровне показывается поле, как в Мастдайном "Сапере".
На среднем - показывается только число мин, соседних с текущей позицией, и близость к финишу (сумма координат).
На сложном - число мин и близость к финишу выдаются намеками ("горячо-холодно").

Этот метод применим, надеюсь, и к добавлению игровой составляющей в совсем не игровой процесс. Что и попробую сделать во второй части Заметок.

КСТАТИ, А КАК БЫТЬ СО СЛОЖНЫМИ ИГРАМИ?

ПО МАТЕРИАЛАМ МОЕГО УЧАСТИЯ В ФОРУМАХ:

- Gudleifr, короче, правильно ли я понимаю, что ты сам не понимаешь, о чем хочешь в этой теме говорить? И название нужно нормальное.
- г.Модератор, неправильно, но какая разница?
- gudleifr, разница в том, что если бы был внятный ответ, то тема осталась бы открытой.

А, ведь, в той теме был получен важный результат: было окончательно выяснено, что игра состоит из практически независимых частей -
1. идеи,
2. реализации и
3. общественного мнения;
и то, что большинству "историков" признание такого деления крайне невыгодно.
***

Чуть выше мы вспомнили второй набор "кубиков":
1. изучение правил;
2. изучение игрового мира;
3. изменение игрового мира;
4. изменение персонажа.
***

Третий набор "кубиков" (являющийся классическим - по Бруксу):
1. программа;
2. программный продукт;
3. программный комплекс;
4. системный программный продукт;
***

Ах, да, из последнего закрытого модераторами: с точки зрения игры, как игры, можно выделить:
1. создание привлекательного мира для завлечения игрока (не имеющего отношения к игре)
2. собственно игру - обмен некими сигналами-ходами с игроком (позднее я придумал термин - "машина игры")
3. игру автора (управление игроком, совершенствование игры...)
***

В разговоре о возможности группировки игр по типам всплыла ссылка на статью "Смысл игровых жанров" - http://www.lki.ru/text.php?id=37, где игры делились на
1. Игры движения. В этих играх ключевой фактор - движение, скорость, точность. Мозги тоже нужны (иногда), но без отличных навыков управления делать тут просто нечего.
2. Игры планирования. Здесь основное - это планирование событий и борьба за получение преимущества в дальнейшем.
3. Игры сюжета. В этой группе может быть важна и динамика, и план, но на деле и то и другое - лишь средства, а не цель. Цель же - продвижение по сюжетной линии.

Однако, легко можно видеть, что на эти три "вида" делятся не только сами игры, но и отдельные их блоки. Разве что с некоторым "масштабированием" терминов.
На уровне игры, например (см. предыдущий комментарий), есть блоки, создающие сюжет (контент), блоки "движения" - интерфейса с игроком, "планирования" (точнее, конфликта стратегий) - игры автора.
Внутри основного блока (собственно игры, интерфейса с игроком) имеем опять: "движение" - мышкоблудие, "планирование" - решение головоломок, "продвижение по сюжету" - управление потоком информации (в обоих направлениях - и к игроку, и от него).
Головоломки можно опять поделить на те, что рассчитаны на скорость реакции на изменяющуюся обстановку - "движения"; на решаемые обычными методами (на логику, на математику, на правила игры) - "планирование"; и на те, которые требуют ориентации в контексте (анализа "сюжета")...

ЕСЛИ ВСПОМНИТЬ, ЧТО ИГРЫ ПРИХОДИТСЯ ПРОГРАММИРОВАТЬ...

(Что такое программирование, см. ТЕМА #15).

К сожалению, описанное выше "кубиковое" деление задач на части работает только для простых задач. Когда с "высоты задачи" можно видеть "фундамент".
А как быть со сложными?
Для сложных работает метод FORTH: Имеем A (язык машины), пишем на нем на коленке за неделю язык F (Forth), затем на нем - P (проблемно-ориентированный язык), отдаем последний пользователю для решения своих задач. Пусть, это будет метод #4. Пока, здесь, рассмотрим более простые.

Возможно, настоящие писатели могут писать свои романы в свободной форме - все более углубляя и расширяя произведение - и не имеют проблем с добавлением новых поворотов сюжета или свежих идей туда, куда надо. Возможно, даже, есть программисты, способные так же писать программы - постепенно добавляя все новые и новые возможности, и без труда преодолевая тот рубеж, на котором мои программы если и не перестают работать, то начинают терять в функциональности после каждого исправления ошибок, вызванных очередным "улучшением". Однако, я не видел ни таких программистов, ни таких программ. Если угодно, эту проблему описал Дейкстра еще в 70-е годы XX века. А Брукс сделал популярной ее формулировку: "Серебряной пули не существует".
Какие же способы, кроме очевидного "взять и написать то, что надо", существуют?
Видимо, есть два "философских" способа. Первый - рассматривать большую программу как машину, собранную из других машин, связанных простыми интерфейсами (см. "Заметки о структурном программировании" Дейкстры). Вопрос модификации программы т.о. решается как замена одной из машин на другую с тем же интерфейсом. Второй - изобретение языка, на котором решение задачи можно описать достаточно просто. Программа в этом случае представляется как набор переводчиков с языка на язык.
Т.к. между понятиями "машина" и "язык" в программировании существует взаимнооднозначное соответствие, то выбор "философии" определяется, скорее тем, с чем мы имеем дело - с компилятором или с интерпретатором.

Каковы практические решения, порожденные нашей философией? И, самое главное, какие подводные камни нас ожидают?

1. "Плюем и копипастим". Очевидно, что чем "последовательнее" куски кода, тем длиннее они могут быть. Но где найти столь выразительный язык, чтобы на нем можно было бы писать без "петель"? На помощь приходят Операционные Системы. Они разрешают пользователю писать только отдельные главы "Что произойдет, когда пользователь нажмет на кнопку?", "Что надо не забыть при размещении окна на экране?",.. А связь между главами берут полностью на себя. В такой умной среде даже достаточно сложно привязанную к сюжету "главу" можно просто приписать в конец программы. Минус подхода, разумеется, в том, что здесь не писатель управляет сюжетом, а сюжет - писателем. Мы постоянно видим вокруг программы, напрягающими пользователя заполнением ненужных ему форм, требуя от него ненужных подтверждений очевидного, навязывая ненужные ритуалы.

2. "Структурное программирование". В своей книге "Дисциплина программирования" Дейкстра ввел аксиоматику соединения программных глав в единое произведение. Два важнейших способа - операторы выбора и цикла. Со временем аксиоматика забылась и программисты уверовали, что цикл может гарантировать им чуть ли не кибернетическую ультраустойчивость, а выбор обеспечит возможность учесть "все". Эти два оператора ответственны за увеличение мусора в программах на один, а то и два, порядка. Чтобы это оценить нужно вспомнить аксиоматику. Она проста (если не вникать в математику): основное качество цикла не способность вовремя остановиться, а способность сохранять т.н. "инвариант цикла", что позволяет ему не пойти вразнос; с выбором все очевиднее - этот оператор должен учитывать все варианты не в смысле "все что придет в голову", а в смысле "честной мат.логики" - всех возможных наборов значений переменных, входящих в условие выбора. Как это работает?
Обычная ошибка применения циклов, как мы видели ранее - "матрешка". Циклы вкладываются один в другой не "по логике", а "по сюжету". Кроме потерь на лишние переборы, порожденные изменением одной-двух переменных состояния, приходится слишком долго проверять, не был ли поврежден "инвариант". А, если программист сам плохо понимает, какой инвариант к какому циклу относится, число проверок/восстановлений растет в геометрической прогрессии.
Аналогичной ошибкой при использовании оператора выбора является упомянутая выше "елочка". Вместо последовательной обработки отдельных переменных состояния, при неудачном распределении последних, получается громоздкое дерево. Для всех вариантов значения первой переменной, проверяются все значения второй, для каждого значения второй - все значения третьей... В сложных елочках часто происходит более одной проверки одного условия, т.к. понять была ли ранее сделана та или другая проверка достаточно сложно, особенно после внесения пары-другой исправлений.
Как избежать матрешки и елочки? Нужно стараться отделить логику управления от других вычислений программы. А затем - попытаться ее упростить по правилам обычной математики.
Несмотря на трудность правильного применения структурного программирования, оно позволяет писать очень красивые (и доказуемо соответствующие логике задачи) программы.

3. "Масштабирование". С ростом популярности языка C термин "структурное программирование" стал использоваться в другом значении - как программирование путем бесконечной группировки структур (кода и данных) в более крупные структуры. Появилось (такое же дурное) понимание понятия "объектно-ориентированного программирования" - как создания неких универсальных структур (объединяющих - "инкапсулирующих" - в себе и код, и данные вместе).
Для увеличения сложности таким путем, очевидно, характерен "синдром чайника" - когда "вылить уже налитую воду" проще, чем переписать процедуру "кипячения".
Другой источник мусора при таком подходе - избыточность предохранительных процедур, которые "для универсальности и безопасности" вставляют во все процедуры, где неправильные данные могут вызвать ошибки. Такой подход не только приводит к жуткой избыточности ненужных проверок, но и служит источником ошибок - необнаружению критических сбоев.

Но, может, я преувеличиваю влияние размера программ на их неработоспособность? Может, если большая программа состоит из большого числа простых частей, она остается простой? Нет. Ни одна из возможных (да, да, не существующих, а именно возможных) методик не сможет доказать, что программа работает правильно.
Размер программы - всегда главный враг. И если он растет не потому, что этого требует задача, а потому, что таков наш путь решения, то - горе нам!
Вернемся к нашим "чистым" методам: машинам и языкам.
Для "метода машин" очень полезным будет рассмотренная выше помощь Операционных Систем. Нужно не надстраивать над ней свои интерфейсы взаимодействия, а пользоваться уже готовыми. Причем, совершенно не важно, будет ли операционка ориентирована на процедуры или сообщения. А, раз главным интерфейсом будет интерфейс системы, то нет никакой потребности усложнять язык программирования. Простого компилятора будет достаточно.
Аналогичные рассуждения приведут нас к тому, что и интерпретатора достаточно самого простого. Возможность написания языка под задачу гораздо важнее свойств языка-зародыша.

BATTLEZONE

Принесли походные видеокамеры, чтобы расширить обзор и наблюдать подробности развернувшегося сражения. Видны были сцены кровавых стычек и разрушений...
С подковы на плече потекла информация. Он сбрасывал ее на вторичные носители. На экранах было видно, что его войска очищают от противника периметр обороны. Битва шла в небе и на земле в радиусе по крайней мере пятидесяти переходов...
Шум битвы, скрытый за окрестными зданиями, становился все громче. Тег слышал хриплые крики, шипение огнеметов, смешанное со свистом лазерных лучей и пуль легкого стрелкового оружия...
Он возвысил голос, стараясь перекричать грохот боя, в микрофоне, прикрепленном к плечу адьютанта, раздавалась быстрая речь офицеров, докладывающих обстановку...
- Почему у меня нет средств связи?
- Они сожгли обе запасные установки одним выстрелом из лазерной пушки.
- Установки перевозились вместе?!
/Ф.Герберт "Капитул Дюны"/

Большая часть нижеследующего писалась полтора десятка лет назад.- G.

КОМПЬЮТЕР, НАКОНЕЦ, ЗАРАБОТАЛ  
Наконец-то компьютеру предоставили делать что-то более интеллектуальное, чем воспроизведение на дисплее заранее нарисованных картинок или избавление игрока от бросания игральных костей. Были, конечно, различные симуляторы, но число моделируемых ими функций было удручающе мало. BATTLEZONE - первая и последняя игра, которая предлагает игроку не бессильно наблюдать с высоты птичьего полета идиотизм своих подчиненных или, в лучшем случае, порхать вокруг них неким бесплотным духом, но полностью погружает его самого в мир боя.

КРАТКАЯ ХАРАКТЕРИСТИКА ИГРЫ
ДЕЙСТВУЮЩИЕ ЛИЦА - боевые механизмы изнутри и снаружи
МОДЕЛИРУЕМЫЕ СОБЫТИЯ - боевые действия от первого лица
ПОЛЕ БОЯ - виртуальная реальность
СОЛДАТИКИ - от солдата до боевого корабля
ИГРОВОЕ ВРЕМЯ - различные приближения к реальному времени
ГЕНЕРАТОР СЛУЧАЙНЫХ СОБЫТИЙ - сложность реалистичной модели мира
РАСЧЕТЫ "ЗА КАДРОМ" - вплоть до искусственного интеллекта сподвижников
ОБЩИЕ ЗАМЕЧАНИЯ - недостижимая мечта всех любителей военных игр

ОСНОВЫ ЖАНРА
Вечная проблема: создать у игрока эффект присутствия в игровой вселенной, заставить его сопереживать событиям, там происходящим. Во все времена находились люди, твердящие нам, что их передовые технологии, наконец, с ней покончили... А через полгода выходил очередной [xxl-разрядный, аудио-, видео-] процессор... (Что такое Unreal? Помнишь, в Quake II, мухи вокруг трупов вились? Так здесь они честно трехмерные!)
Значит, попробуем поговорить об играбельности, не касаясь технических проблем. Писал же Станислав Лем о виртуальной реальности в своей "Сумме технологии" еще полвека назад.

Рассмотрим основные приемы повышения жизненности игровых вселенных:
- Смешение игр. Это, пожалуй, последнее из чисто игровых решений, сделанное программистами: "А давайте объединим несколько игр в одну, зато с пониженными требованиями к игроку!". На тот момент уже были перепробованы все средства улучшения настольных игр путем компьютеризации: компьютер - противник, компьютер - творец, компьютер - симулятор, компьютер - игровое поле... Но все эти решения не давали возможности привлечь к играм широких кругов непрограммистов. Нужны были игры, имеющие "товарный вид", подавляющие игрока своей сложностью (И не думай сам такое писать!) и видимостью законченности (Вот вам игра - творение художника, который учел все!).
Благодаря упрощению компонентов, круг играющих расширился, а, благодаря возможности компенсировать недоработки баланса одной части за счет другой, производство игр стало возможным поставить на поток. Кроме того, совмещение нескольких игр под одной крышей снижало вероятность выхода уставшего игрока из игры, чтобы "поиграть во что-то другое".
огда, видимо, и появились жанры - до этого были просто (видео)игры. Именно выпуск упрощенных игр-мутантов породил стремление разложить все по полочкам.
- Художественные вставки. Особенно широко пользовались этим способом в те времена, когда компьютеры не могли держать на экране качественные картинки постоянно. Вот и приходилось все красивости сводить в видеоролики, перемежающие игровой процесс, или рисовать две отдельных модели танков - похуже, для игры и, получше, для энциклопедии. Даже, если не брать в расчет технических предпосылок, то этот метод все равно, как никакой другой, создает атмосферу игры. Именно из роликов игрок узнает внезапно получаемом наследстве или коварной измене. С другой стороны, число вставок ограниченно, и сюжет такой игры становится практически линейным.
- Генерация случайных событий и ландшафтов. Такое умели только очень толковые авторы. Никому не удалось, пожалуй, переплюнуть почти доисторический Rogue. Карты X-Com нудноваты, а в других играх и вовсе случайность ограничивается параметрами отдельных планет (Millennium) или замков (King's Bounty, Trans Arctic).
- Вид из глаз. Раньше такое могли позволить себе только симуляторы (в т.ч. стрелялки), но, каково искушение! И вот появились Incubation и BattleZone. Не знаю, как вы, но я, отныне, хочу игры только от первого лица. Правда иногда такое желание реализуется при помощи довольно замысловатого интерфейса. Например, в Millenia, где Вы управляете эволюцией, не выходя из кабины звездолета.
- Режим реального времени. Напряженности он игре прибавляет, а вот реализма - вряд ли. Тут все дело в умелом подборе масштабов. Одно дело, Вы - "впереди на белом коне", и совсем другое, бегать (летать) вокруг колонны самоходов, пытаясь их развернуть в нужную сторону (ср. гв.мл.л-т Малешкин).

Еще немного размышлений (с картинками) на эту тему - ТЕМА #34

REAL TIME STRATEGIES - СТРАТЕГИЯ ИЛИ ТАКТИКА?  
Обычно, критики, с оттенком пренебрежения, называют игрушки, в которых игрок пытается командовать бестолково мотающимися по экрану армиями танков, "тактическими". Наверное, они полагают, что под словом стратегия подразумевается что-то гораздо более интеллектуальное.

Пойдем по пунктам.
- ДЕЙСТВУЮЩИЕ ЛИЦА. На первый взгляд кажется, что все единицы сугубо тактические: танк, солдатик, самолетик, вооруженные, обычно, каждый одним видом оружия. Однако если рассматривать партию в целом, мы увидим совсем другую картину. А именно, несколько центров производства, из которых исходят потоки единиц постоянной плотности и состава. В месте пересечения потоков происходит их аннигиляция, и поток с более продуманным составом тоненьким ручейком продолжает свое течение, затапливая карту. Извините, но это уже стратегия.
- МОДЕЛИРУЕМЫЕ СОБЫТИЯ. Какие решения принимает в течение игры игрок-генерал? Выбор процентного состава и плотности потоков, направление их движения. Причем, решение должно быть выбрано еще до начала кампании и только в первых играх могло худо-бедно корректироваться. На тактику, в прямом смысле слова, не остается времени. Единственная уступка ей, появившаяся в более-менее современных играх, возможность использования нескольких видов боевых построений.
- ПОЛЕ БОЯ. В погоне за зрелищностью, авторы часто превращают поле боя в лабиринт, не столько создавая простор тактическому маневру, сколько облегчая стратегическое планирование (так как ваши потоки могут течь только по заранее проложенному руслу).
- СОЛДАТИКИ. Вроде бы они выглядят, как отдельные тактические единицы, но произвести их индивидуальный учет и контроль невозможно. Управлять можно только целыми толпами.
- ИГРОВОЕ ВРЕМЯ. Именно режим реального времени задает подобные правила игры. Он ставит нас над схваткой и заставляет оценивать картину в целом, выделяя ключевые моменты в суматошном копошении разноцветных бронетараканов. Казалось бы, простор для тактических перестроений? Не в этой жизни. Любое нетривиальное изменение картины боя, потребует коренного изменения же всей структуры снабжения-производства. В принципе, сама идея уравнивания скоростей производства-разрушения определяет стратегический уровень моделирования.
- ГЕНЕРАТОР СЛУЧАЙНЫХ СОБЫТИЙ. Узкое место всех этих игрушек. Во-первых, карта любого боя определена заранее, как и стратегия компьютерного супостата. Во-вторых, умственные способности компьютерных солдатиков заведомо ниже даже среднеофицерских.
- РАСЧЕТЫ ЗА КАДРОМ. Об этом не принято говорить, но любой игрок сначала запускает любой сценарий в "тестовом" режиме не стремясь победить, а просто познакомиться с картой и посмотреть на противника. Только затем он восстановит тщательно сохраненную игру и будет играть "в зачет". Так что "астратегичность" подобных игр не в "тактическом уровне проблемы", а в способе решения проблем стратегических - методом проб и ошибок.
- ОБЩИЕ ЗАМЕЧАНИЯ. Сейчас подобные игры чаще всего применяются как спортивные. Два игрока как можно быстрее реализуют домашние стратегические заготовки. Практически, усложненная игра "камень-ножницы-бумага".

Конечно, есть много разновидностей подобных игр. Например, в Z скорость увеличена до футбольной, а в Settlers снижена до типично немецких стандартов. Были и попытки сделать эти игры более "тактическими", совсем отказавшись от производства на поле боя (например, в Force21), но в чем преуспели, так только в окончательном сведении игры к одному-единственному удару. А есть еще такая игра - BattleZone...

BATTLEZONE  
Введя необходимые определения, перейдем к рассмотрению, собственно нашего рекордсмена играбельности.
- Смешение игр. Хитрость в том, что здесь его не заметно. Соединение столь бесшовно, что речь идет о цельном тактическом симуляторе. По сути, это "окончательное решение" - смешение игр путем построения мира, в котором во все эти игры можно играть одновременно.
- Художественные вставки. Как же без них! Тем более, что механизм съемки (для незнающих русского языка - 3D Engine, движок) позволяет просчитывать их, как и игровую ситуацию, в реальном режиме времени. Вставки донельзя реалистичны и драматичны. Шаг за шагом перед нами открываются сразу две загадочные истории: палеокосмонавтики (точнее перенесения в космос мифов Древней Греции) и "истинной" космонавтики современной.
- Генерация случайных событий и ландшафтов. Тут все как у всех - единственный непредсказуемый элемент вселенной - сам игрок. Другое дело, игровая вселенная настолько сложна (реалистична), что предсказать заранее даже вполне закономерный результат действий довольно сложно.
- Вид из глаз. Изюминка игры. Он реализован на всех уровнях управления войсками. Даже, уткнув нос в экран радара общего обзора, игрок не должен забывать, что его зад остается на поле боя и весьма уязвим.
- Режим реального времени. Как писалось выше, большинство подобных игр - стратегии. Эта - исключение. Просто потому, что большинство стратегических решений принимает за игрока кто-то другой (автор сценария). Игроку же остается симулятор. Конечно, реальной эту эпопею мотания на полной скорости, в попытках выполнить молниеносно сменяющие друг друга вводные, назвать трудно.

ИНТЕРФЕЙС  
Величайшая заслуга авторов игры состоит в создании единой схемы управления подчиненными, независимо от состояния и положения игрока. А игрок может: а) бегать в скафандре по поверхности, б) заходить в здания (во второй части), в) работать с пультом (в первой части только радара), г) управлять танком. Сразу надо оговориться, что вселенная приспособлена исключительно под ведение боевых действий, и, практически, все команды являются разновидностями команды "атаковать". Итак, игрок оперируя, практически только десятью клавишами, вводит командные цепочки. Часто часть команды можно заменить просто тыканьем пальцем (мышкой): "Ты", "Туда", "Его, ... мать!".

Каждая команда начинается с указания исполнителя. Группы исполнителей следующие:
1 НАПАДЕНИЕ - собственно, танки;
2 ОБОРОНА - передвижные огневые точки;
3 РАБОЧИЕ - сборщики ресурсов, тягачи;
4 НАВ.КАМЕРА - буйки;
5 ЗАВОД - вечная для игр реального времени единица - производитель всего сущего.
6 ФАБРИКА - менее самостоятельна и универсальна, чем завод, зато может строить тяжелые танки.
7 АРСЕНАЛ - забавное приспособление заправки-ремонта, катапультирующее(!) все необходимое в любую точку карты.
8 КОНСТРУКТОР - универсальный строитель зданий. Зданиями командовать не надо - они работают самостоятельно и непрерывно.
9 СПУТНИК - небесное всевидящее око.

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

Обычные команды для всех танков:
1 ЗА МНОЙ
2 ОБОРОНЯТЬ
3 АКЦИЯ
4 ВЗЯТЬ МЕНЯ
5 РЕМОНТ
6 ПЕРЕЗАРЯД
0 ПРОДАТЬ / ПАКОВАТЬ

Остальные специфичны для отдельных видов техники.
Команда АКЦИЯ означает реализацию той функции, для которой танк и предназначается.
Команда ВЗЯТЬ МЕНЯ означает, что пилот танка уступает вам место за штурвалом и пешком отправляется на базу. Нельзя не упомянуть и самую забавную возможность игры - игрок может пристрелить вражеского водителя и занять его место.
В команде ЗАВОДУ, ФАБРИКЕ, АРСЕНАЛУ и КОНСТРУКТОРУ указывается, что именно надо произвести.
Таким образом, путем достаточно очевидных упрощений удалось сделать достаточно сложную систему управления очень простой.
Во второй версии игры пошли еще дальше, сделав меню полностью контекстным, т.е. добавляя и удаляя из него команды в зависимости от оперативной обстановки.
***

Надо заметить, что в дальнейшем (даже уже во второй части), интерфейс подобных игр постепенно возвращался к общепринятому - отказываясь от сложных команд в пользу простых. Мол, если игрок хочет выполнить сложное действие, он должен физически воспринимать его как набор простейших, а, часто, и с кучей промежуточных (балетных) телодвижений, например, перейти фишкой главного героя от одного пульта к другому.

НЕДОРАБОТКИ:
- программистских ляпов в игре очень много, как принципиальных (вплоть до непроходимости отдельных миссий), так и просто вызывающих излишнее ресурсопотребление;
- сюда же можно отнести местами абсолютно неадекватный перевод;
- многие миссии проходятся гораздо легче недокументированными способами;
- о том, чтобы использовать все разнообразные виды техники и оружия, речи нет; кажется, многие из них доступны только при легком взломе.

"НАСТОЯЩАЯ" ИСТОРИЯ КОСМОНАВТИКИ  
Как говорили раньше: "восьмая страница газеты "ТРУД"". Теперь такое печатают не только во всех газетах и журналах, но и в достаточно толстых книгах. "Спасибо" Бушковым и Пелевиным. "Разумеется", Гагарин и Армстронг не были первыми. "Разумеется", спецслужбы давно поделили ближний космос и теперь воюют за дальний, по пути то и дело вступая в близкие контакты "третьего" и прочего родов...
Все начинается с общеизвестной трансляции высадки американцев на Луну. Затем камера невзначай разворачивается, и становится видно, что на самом деле, наш космический сосед уже довольно плотно заселен. Под сенью звезд и полосок, раскинулся целый городок, идут строительные и изыскательские работы, снуют антигравитационные ездилки. Но тут из-за близкого горизонта выпархивают краснозвездные соколы, и понеслось...
И в первой части, и в довеске к нему играть можно за обе соперничающие стороны, но информационно-познавательно-завлекательными вставками снабжены только кампании американцев. Кампании русских и китайцев - просто набор миссий повышенной сложности.
Сначала простые американские парни проходят всю солнечную систему в поисках биометалла оставшегося от древнегреческих космонавтов. Первоначально он используется только в антигравитационных движителях танков, а потом злобные советские Кулибины создают на его основе разумные танки, пробуждая к жизни злобных древних демонов. В продолжении американцы идут по следам гадких китайцев, научившихся строить звездные врата. Во второй части место китайцев занимают инопланетные чужаки. Линия древних греческих космонавтов сводится к использованию имен из древнегреческих мифов для именования разбросаных по всем планетам солнечной системы обломков циклопических биометаллических конструкций.

ВСЕЛЕННАЯ  
При таком беспрецендентном расширении возможностей симулятора, неизбежно наложение на вселенную жестких ограничений. Первое, чисто количественное, очевидно. Оно следует из ограниченности числа команд, количества и численности групп, изначально заложенного в интерфейс. Второе, качественное, вызванное общими техническими и программными проблемами, на состав и проработку боевых единц, участвующих в конфликте. (Далее я не буду указывать, что относится к какой серии игры).
На поле боя присутствуют, в основном, антигравитационные танки, выглядящие как нечто среднее между танком и самолетом. Их разновидности и вооружение типичны для всех стратегий реального времени. В дополнение к этим "летунам" есть несколько гусеничных ползунов и огромных шагателей. Активно используются танки, имеющие два состояния (походное и боевое) - пушки и фабрики. Артиллерия и авиация поддержки реализованы, подобно АРСЕНАЛУ, в виде устройств, позволяющих кидать всякую гадость через все поле. Есть мотопехота, как неотъемлемая часть танка-бронетранспортера.
Из экзотики присутствуют (почти исключительно в роликах): исполинские танки-корабли Древних Греков, людские и инопланетные артефакты (в том числе - лунный модуль "Орел" и корабль "Вояджер"), космические корабли, посадочные модули и звездные врата.

ВОТ ПРИМЕР ТИПИЧНОЙ МИССИИ  
Ваши силы - командирский танк, завод и пару передвижных огневых точек - выгружают из десантных кораблей. Первое задание - развернуть базу и удерживать периметр. Ничего сложного - ставишь турели охранять ближайшие источники энергии, строишь пару харвестеров и ждешь развития событий. Поступает вторая вводная - перехватить вражеский конвой. С одним средним танком против двух средних и четырех легких? Даже применяя "военную хитрость", она же "кривизна вселенной" - упереться бампером в борт одного из вражеских танков и жать на полный газ, не отпуская гашетки пушки, задача очень не простая. В лучшем случае, приходится идти на базу пешком и строить новый танк. Тем временем, враг укоренится, и для выполнения очередного задания - полного уничтожения супостата - придется строить заводы и производить небольшую армию. Наконец, враг уничтожен, и поступает новый приказ - найти источник загадочного сигнала по ту сторону горного хребта. Дорога туда известна - через туннель, которым прошел вражеский конвой. Вражеских турелей, прикрывающих подходы немного - ничего сложного. Источник сигналов забавен - маленький гусеничный танк с огромной антенной-деревом. Бомбардировщики вылетели, вам приказано возвращаться на базу. Но в последний момент туннель заваливают огромные каменные глыбы... Последняя вводная - следовать к месту посадки спасательного десантного корабля. Азимут и расстояние для всех точек, которых нужно достичь по условиям миссии (кроме вражеской базы) заботливо выводятся компьютером на дисплей, местность не такая уж и сложная, в общем, все просто.
Но, если заранее знать вводные, можно пройти миссию гораздо быстрее: сразу поставить турели на выходе из туннеля и подождать вражий конвой. Строить в этом случае вообще ничего не придется. Надо только не забывать, при обнаружении вражеской турели, выходить из танка и доставать снайперскую винтовку...
Вывод: любой самый замысловатый сценарий уступает генератору случайных чисел.

КУДА ВСЕ ЭТО ДЕВАТЬ?  
Вот, наконец, я и дошел до изложения каких-то мыслей. Ну, игрушка, ну, хорошая, ну, старая... Дальше то что? Бросить все и искать ее по барахолкам? Доставать производителей, чтобы они выпустили еще одно продолжение? Самому написать что-нибудь подобное? Наверное, последнее, но, конечно, не в полном объеме, с честной трехмерной графикой, тенями и прочими аудио-видеоэффектами. Вообще, хоть я и увлекся описаниями компьютерных красивостей, речь-то в статье идет о реальности, о приближении правил к жизни, настолько, насколько это увеличивает играбельность. А на этом пути компьютер может нам помочь, делая то, что нам не по силам, или скучно - рассчитывать вероятности и траектории, засекать время реакции, подводить итоги. Попробуем на примере вселенной BattleZone, определить, чем стоит пренебречь, что имеет смысл поручить компьютеру, а что нарисовать или смастерить самим.
Не ждите от меня законченной системы (хотя, идея интересная - наполовину компьтерно-виртуальная настольная игра), как всегда, одни огрызки.
(Вот тут-то и возникла, наверное, идея написания "Заметок".- G.)

МЕЖИГРОВЫЕ СВЯЗИ
Глядя на бодро покидающих поле боя пилотов подбитых танков, вприпрыжку убегающих по пустыне в своих голубых скафандрах, сразу понимаешь, откуда взялись заложники в игре Descent. В этой честно-трехмерной коридорной леталке-стрелялке именно таких ребят и приходилось на своем горбу вытаскивать из зловещих инопланетных пещер. А вспомнив Descent, сразу задаешься вопросом, а почему в ВattleZone, мне не дают полетать? Зачем эти гонки по дюнам на антигравах, если при такой силе тяжести легче разбомбить, сесть, забрать что надо и смыться? Опять же, приветствуя желание авторов разровнять для нас поверхность небесных тел, признаем, что они все же не вполне здесь правы.
Есть ли еще игры с настолько же замкнуто-управляемой и увлекательно-познаваемой вселенной? Colobot! Colobot! (ТЕМА #44, АБЗАЦ #437). Правда, это проект не столько игровой, сколько обучающий.
***

И еще...

ОГРЫЗКИ...
Начнем с того, что в BattleZone присутствует "за кадром" - с космических полетов.
Если верить произведениям западных фантастов, космические корабли маневрируют в пространстве с легкостью назойливой мухи, кружащей вокруг люстры. Артур Кларк, конечно, не в счет. Еще роман Мартина Кэйдина "В плену орбиты" и рассказ Тома Годвина "Неумолимое уравнение". А еще? Разве что, документальная книга Нормана Майлера "Из пламени на Луну".
Производители игрушек от фантастов не отстают. Корабли скрипят тормозами и заходят на посадку под прямым углом. Редкие известные мне исключения - "Проект "Орбитер"", да, частично, Millennium. В традиции советской фантастики, наоборот, механике полета уделяется огромное место. Родина Циолковского, однако.
Как рассчитывать подобные эволюции? Оказывается, не так уж и сложно. Рассмотрим материалы клуба электронных игр, существовавшего на страницах журнала "Техника-молодежи" с июня 1985г. Они взяли за основу доисторическую программульку "Посадка на Луну", добавили рельеф, межпланетные полеты, атмосферу... (См. выше про ЛУНОЛЕТ.- G.).
Так что Ваш любимый настольный ролевик без проблем может быть дополнен компьютерным (калькуляторным) блоком симуляции компьютерных полетов или, хотя бы, блоком расчетов длительности межпланетных перелетов. (Скажу по секрету, испытываю жуткое желание "ужать" вселенную Void до размеров одной звездной системы). Еще о космических игрушках - ТЕМА #28.

ГЕНЕРАЛЫ ПЕСОЧНИЦЫ

Что изменилось за десять лет (уже больше.- G.), прошедших с открытия этого раздела (BATTLEZONE)?
- Узнал о существовании близкого "родственника" - серии Carrier Command;
- Придумал "кольцо классов настольных игр" и теперь упражняюсь в классификации.

КОЛЬЦО КЛАССОВ И РЕАЛ-ТАЙМ СТРАТЕГИИ

Напомню классы:
1. "Змейки и лесенки" и простые ролевые (одна фишка и навязанный сюжет).
2. "Уголки" и другие паззлы (стратегия неухудшения против тактики улучшения позиции).
3. Шашки и прочие исторические варгеймы (тактика).
4. Шахматы (стратегия и тактика).
5. Сложные симуляторы и ролевики (много фишек и управление сюжетом).

Ну, во-первых, можно ли вообще применять мою классификацию к компьютерным играм?
Разумеется. Т.к. ее применение даже к настольным играм ничем особо не подкрепляется, то почему бы и не применить где-нибудь еще? С тем же основанием. Точнее, с его отсутствием.
Во-вторых, существуют ли компьютерные игры, которые явно не вписываются в классификацию?
Тут тоже все во многом очевидно. Ведь есть много компьютерных игр, которые заключаются в тщательном исполнении каких-либо [спортивных] упражнений. Разнообразные тиры, проверялки реакции и тесты на внимательность. Задним умом понятно, что подобное можно найти и в настольных играх, хотя там, обычно, подобные развлечения очень редко считаются самостоятельной игрой. Даже к Дартс прилагается замысловатая система подсчета очков, приводящая игру ко 2-му классу.
Так и быть, размещу "в центре кольца" класс "0", откуда все остальные классы могут черпать миниигры для разнообразия своего процесса. Назову игры этого класса интерфейсными, чтобы подчеркнуть их несамостоятельность. Т.е. для серьезной игры, например, "стратегического" StarCraft (класс где-то 2-3), сражения отдельных фишек - только деталь интерфейса (и нужно быть южнокорейцем, чтобы находить удовольствие, соревнуясь в тщательности их проведения).
***

И вот такой классификационный экстремизм приводит нас к крамольному выводу - реал-тайм-стратегичность лишь незначительная подробность реализации игр, но не ее классовый признак (если кто еще помнит, как раз вопросы тактики и стратегии привели меня к делению игр на классы). Конечно, я и раньше подозревал, что между Z, Settlers, Battlezone и StarcCraft очень мало общего.
(Здесь надо особенно выделить Settlers. Игра имеет очень мало общего с настольным первоисточником - Die Siedler von Catan - но класс обеих игр (2) полность совпадает. Разработчики компьютерной игры сделали свое дело очень бережно и качественно).
***

Отличие игр BattleZone и Carrier Command от других реал-таймов в том, что они относятся к 5-му классу, колеблясь в разных версиях в сторону 4-го или 1-го. (Понятно, что в эпоху "великого упрощения геймплея", чем новее игра, тем ближе она к 1-му классу - "веселому приключению").
***

В чем смысл этого самого 5-го класса? Кому жарко или холодно от принадлежности наших игр именно к нему?
- Подобно шахматам, игры этого класса делятся на уровни. Но, в отличие от них, привязать эти уровни к тактике/стратегии обычно невозможно. Кроме вертикального деления на уровни возможно деление "шизофреническое" - придание "шахматным фигурам" "самостоятельности и интеллекта".
- Для игр этого класса очень важно существование полноценной "игровой вселенной". Либо, как слепка с какого-то аспекта мира реального (например, деловые и штабные игры), либо, как условной, но непротиворечивой и законченной модели (например, компьютерные игры серии X-Сом).
- Сползание в 4-й - шахматный - класс наблюдается, если "ролевая составляющая" носит лишь иллюстративный, украшательный характер (например, коллекционные карточные игры). Или, когда, хотя бы одна из шахматных составляющих - стратегии и тактики - остается на месте, а вторая подменяется чем-то более насущным (военно-морская игра Джена).
- В первый класс сползти еще легче - упростив сюжет и/или сделав одну фишку игрока главной, а остальные - лишь ее "свитой".

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

РОДСТВЕННИКИ  
Когда я говорил о книгах-играх, то упоминал о необходимости, по крайней мере трех уровней: "стратегического" (где "живет механика вселенной", прописаны ее законы), "тактического" (где описываются окружающие игрока "пейзажи") и "личностного" (переживаний и состояния игрока).

Так вот, в BattleZone (1998) таких уровней целых пять:
1. история космических ушельцев, которая открывается игроку по мере прохождения сюжета;
2. описание хода кампании по захвату американцами Солнечной Системы (обоснование миссий);
3. описание текущей тактической обстановки (получение вводных по ходу миссии).
4. строительство базы (обеспечение игроком своей операции) и отдача приказов войскам. Именно в этом одна из хитростей этой игры - строительство базы обеспечивается тем же интерфейсом, что и вождение войск.
5. езда на танке (или на своих двоих).

Неплохо для игры, первая серия которой (1980) содержала только последний из перечисленных уровней - танковый. Впрочем, он так и остался главным: и "исторические открытия" делаются не выходя из танка, и ошибки управления приходится исправлять бегом. ("Дурная голова ногам покоя не дает").
Для игр, которые мне кажутся родственными, имеем:

Уровни	BATTLEZONE (1998)	BATTLEZONE II (1999)	CARRIER COMMAND (1988)	HOSTILE WATERS (2001)	CARRIER COMMAND (2012)
1	Космические ушельцы	-	Предыстория конфликта	Самодельные чужие	Вселенная Gaeа (что бы это значило?)
2	Космическая экспансия	Космическая экспансия, деление на миссии очень условно	Стратегический уровень игры	Океанская экспансия	По выбору - миссии или стратегия
3	Вводные		-	Вводные
4	Строительство базы и войск		Строительство войск
5	Езда на танке, беготня, снайпинг		Управление танком		Управление танком, беготня

Разница только в деталях. Самое главное отличие - наличие в Carrier Command стратегической составляющей вместо навязываемой сценарием цепочки миссий.
Сейчас граница этой серии "с первым классом" достаточно размыта, т.к. во многих современных бегалках-стрелялках присутствует некая "тактическая составляющая" и возможность "порулить на танке".

НЕДОРАБОТКИ  
К сожалению, увлечение созданием "бескомнатной" - честно трехмерной - модели интерфейса (в старом Carrier Command - "оконная"), привело к жутким ошибкам в работе программ:
- На экране (и в динамиках) постоянно куча несуразных сообщений.
- Невзирая на обилие брифингов и подсказок миссии проходятся, в основном, "методом тыка", часто "недокументированным способом".
- Поведение фишек часто совершенно неадекватное.
- Рельеф изобилует "дырами", обсчитать которые компьютер не в силах... Танк, попавший туда, "выпадает из игры".
- Интерфейс получился не всегда удобным и очевидным, особенно в Hostile Waters, где он зачастую создает больше проблем, чем неприятель.
- Получилась какая-то ерунда - техника фантастическая, а управляется хуже современной. В Carrier Command 2012 рулить надо одновременно и танком (клавишами), и его башней (мышкой).

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

И совсем уж непонятно, зачем Hostile Woters сделали детскую игру в танчики "детям до 16" (по нынешнему - "18+"), добавив туда истерзанных трупов в купальниках и без?

HOSTILE WATERS  
Когда увидел эту игрушку, не смог сдержать возмущения. Так нагло предвосхитить мою идею - играть за корабль-носитель разнообразных танков (о Carrier Command я еще не знал)! Идея, конечно, совершенно очевидная. Меня на нее, видимо, навели воспоминания о виденных три десятка лет назад играх серии Star Trek (еще текстовых) и чуть позже - стрелялках-скроллерах, где очень часто самолетик стартовал с борта какого-нибудь футуристического носителя.
По законам жанра, введение "авианосца" дает игре удобное средство, во-первых, "хранения" каких-то общезначимых функций (в HW, это, например, не только строительство новых танков или проведение исследований, но и стрельба из корабельных орудий), так и, во-вторых, удобного к ним доступа из комнаты-рубки.
С другой стороны, модель игры Battlezone - "где стою, оттуда и командую" - идет прахом, и ее надо срочно на что-то менять.
В HW вместо физического присутствия игрока на поле боя применена система виртуального вселения в различные танки. "Нормально" танки управляются "душами" давно погибших бойцов (см. идеи Росоховатского и Стогния о Кибернетическом двойнике или рассказ Сайберхэгена из серии "Берсеркер" - "Эскадрилья из забвения").
Идея состоит в том, что количество "душ" ограничено. Если число танков его превышает, то приходится лишней техникой управлять вручную (что за исключением редких миссий, основанных на этой шутке) практически невозможно. Кончились "души" - убивай лишний танк, чтобы освободить "душу" (при этом "душа" обычно оказывается непрофильной и для нового танка малопригодной).
Вместо руления танком вручную большую часть игрового времени наблюдаешь из-за спины за работой "мастера".
Насколько "души" специфичны, насколько разная техника отличается по своим ТТХ, каковы плюсы и минусы разного оружия - вопросы для меня оставшиеся открытыми. Игра кончается раньше, чем успевает накопиться статистика.
***

Как я играл в HW?
(Зачем это я? Кому нужны эти ностальгические изыски от первого лица? Нужны. Потому как в 5-м классе нас как раз и привлекает "полное погружение". Если в других классах сюжет часто нужен "для чисто поржать", то здесь заинтересованное личное восприятие - важнейшая компонента игровой механики).

Не помню, были ли там уровни сложности (если были, то я выбрал средний).
В первый раз проходил методом тыка и дошел до 9-й миссии (из 21), где дополнительная вводная оказалась слишком сложной. Написано было просто: "Уничтожьте подлодки при помощи Электромагнитного Оружия". Но, во-первых, все мои бойцы в этот момент были заняты добиванием вражьей базы; во-вторых, где находятся, подлодки и сколько их - неизвестно; в-третьих, топить их другим способом запрещается; в-четвертых, время ограничено... В общем, прикинул, сколько раз придется переигрывать миссию, и плюнул (тем более, что это была отнюдь не первая миссиия, требующая многократного переигрывания).
Сам принцип многократного переигрывания мне кажется глубоко порочным для игр 5-го класса. Нет, если тактическая задача ставится "академически", то многочисленные попытки ее решения (как и последующий разбор) уместны. Но "симулятор жизни", это - немного другая игра. Ошибся - отвечай по всей строгости, и исправляй, а не реинкарнируй и переигрывай. Следовательно - рассчитывай силы и готовься к неприятностям. Но для этого надо больше знать о "вселенной"...
Радостное: "Сюда было нельзя, начинай с начала",- повторяется в HW из миссии в миссию.
В Battlezone все-таки обычно оставался шанс исправить ошибку - перестрелять вражеских водителей, захватить танк или добраться до базы пешком...
С другой стороны, стиль игры: "тупо строим танк, тупо бомбим, тупо дохнем..." (это когда вражеское сопротивление уже сломлено, но на карте еще разбросано много вражеских укрепрайонов), никак в HW обычно не наказывается. Тяжелые последствия синдрома "последнего алиена" (мисия закончится, когда вы "пойдете незнамо куда и найдете невесть что", т.к., вроде, все просимое вы уже сделали). Хочется закончить пораньше, одним броском, но враг все не сдается, танки все дохнут... А построить сразу побольше танков и скоординировать их действия, тем более, выполнять весь сложный ритуал починки, ну так лениво!
Ну ладно, это все лирика. Какие ощущения еще оставил "первый проход"?
Со временем все несуразности интерфейса забылись (а их много, просто очень много, Battlezone в квадрате) и осталось только какое-то чувство родства с этой самой Battlezone. Мол, есть возможность порулить на разных танках, посмотреть на поле боя с разных сторон. Есть немного строительных и совсем уж специальных танков, позволяющих строить забавные миссии. Однако, большинство подобных хитростей исключительно завязаны на сценарий и в "обычной" миссии мало применимы.
***

Второй проход я делал исключительно под управлением скачанного в Сети "решения". Очень быстро пробежал все 21 миссии. Сюжет понравился не особо. За исключением пары-другой панических сообщений: "Мы видим что-то страшное!",- и пары-другой заданий: "Доставьте образец для исследования",- наше участие в развитии сюжета минимально. Как-то в BattleZone было повеселее... Или, может, это влияет явная вторичность сюжета...
Проход по "решению" явно использовал некоторые "недокументированные возможности", но останавливаться и проверять, оправдана ли была подобная "инициатива" поперек "указаний брифинга", было опять лениво. Последнюю миссию вообще не понял: тебя нещадно мочат, ты вяло рыпаешься и, если рыпаешься определенным образом (обязательно ли тем, что описан в "решении"?), то иногда выигрываешь... То ли случайно врагу что-то отстрелил, то ли поставил его в тупик своей нелогичностью, то ли просто повезло...
Чувство родства с BattleZone как-то рассосалось. Кривой интерфейс, непродуманная связь экономики и тактики с сюжетом, слишком уж типовые реал-тайм решения...
Ближе к концу и танки перестали радовать новыми формами - просто более совершенные варианты более ранних, абсолютно в том же дизайне.

CARRIER COMMAND  
В первой версии интерфейс чисто "оконный" - по краям экрана располагаются три фрейма выбора команд (слева - общие, справа - уточнения выбранной общей, внизу - уточнения уточненной) и рабочее окно (обычно 3D) - посредине.
Исходя из опыта разработки реальных интерфейсов, три уровня вложенности - это явный перебор, а честно-трехмерное отображение по большей части избыточно.
Впрочем, в CC 2012 от интерфейса первой версии полностью отказались, приняв практически полностью интерфейс Hostile Waters. Следствие - постоянное непонимание того, за что отвечает в данный момент мышка.
В отличие от BattleZone и Hostile Waters танков здесь всего два вида: амфибийный и летающий, зато их можно по-разному вооружать. Как в Hostile Waters, есть авианосец и можно рулить техникой самому или доверить "профессионалу", однако здесь, наоборот, ручное управление оказывается лучше компьютерного. В первой версии воевать приходилось всегда самому.
Связь вселенной с BattleZone с CC оказалась более глубокой, чем просто "можно кататься на разных танках". А именно - участие игрока равно как в строительстве войск, так и в битве.
Правда, прочувствовать это достаточно трудно из-за сложностей интерфейса CC: в первой версии он вынужденно сложен по техническим причинам, во второй - по недомыслию.

5-Й КЛАСС  
Вернемся к главному отличию представленных здесь игр: стратегия в Carrier Command против набора вводных во всех остальных. Первое тяготеет к 4-му классу, второе - к 1-му.
И там, и там речь о какой-то реалистичности не идет. Мир целиком выдуманный. Технически-фэнтезийный. Как понять что правильно, а что нет?
Ответ, в общем-то, очевиден. Эскапизм чистой воды. Хочется нам мира, где дадут возможность стать великим полководцем, не вникая в тактику и стратегию, где для этого достаточно гонять танчики по песочнице. Да еще танки-то - почти всамделишные...
А дальше - просто добавляем уровней: для наиболее полной реализации управленческих амбиций и для удовлетворения простеньким миропознавательных запросов.
Если речь идет не о машинках, а о реальном мире, принцип тот же. Взять хотя бы работы Уборевича. Строим модель штаба нужного уровня, обеспечиваем нижние уровни демонстративными действиями специально выделенных частей, более высокие - привлечением начальников-посредников.
Уборевич даже специальные соображения представлял по организации работы, по недопущению ухода в теорию, по избежанию простоев...
***

Есть ли какие-либо правила?
К сожалению, главное звучит так: путем комбинирования поощрения-наказания любое времяпровождение (и даже некая производственная деятельность) может быть сделана привлекательной. Работает не только на людях, но и, например, на крысах (проверяли).
Поэтому так часто и приходится общаться с людьми, отстаивающими свой "игровой интерес" к вещам, кажущимися дикими стороннему наблюдателю.
Например, мое увлечение игрой в танчики-солдатики, которой и предлагают заняться данные игры, тоже кому-то кажется странным.
Приходится иногда слышать, что игры дают какую-то "свободу", позволяющую игроку "самовыразиться". Про это я уже писал в статье про книги-игры. Очевидно, речь идет не о "свободе", а просто замене одних правил другими.
Свобода была бы возможна только в случае разрешения игроку самому писать правила.
Т.е. неожиданно (честное слово, действительно, неожиданно) я опять пришел к старому выводу. Интереснее всего в этих играх не какие-то всеохватывающие вселенные, а набор мелких конкретных игр-моделей, позволяющих игроку создавать свои миры.
Правда, отсюда следует, что еще интереснее изобретать приспособления/программы для реальной жизни...

ПОЛЕЗНЫЕ МЕЛОЧИ?  
Что можно выдрать из этих игр?
- Интерфейсы? К сожалению, ничего лучше комнатной модели не придумать. Честно-трехмерный интерфейс все-таки чудовищно избыточен и местами так же чудовищно малоинформативен. Наверное, поэтому после BattleZone II - в Hostile Waters и Carrier Command (2012) - опять начали делать "как у всех" - разбавили его вспомогательными режимами - карты, брифингов...
- Управление? Мы видели два подхода: управлять "всем остальным", как обычным танком, или придумать специальные танки, чтобы сделать "все остальное". Первое дает возможность "бесшовного соединения" уровней, второе - большую свободу в создании новых уровней.
- В общем-то, все вращалось вокруг ввода команд в три этапа: субьект, действие, объект; но реализовано везде было по-разному. Переключение контекстов при вводе подобных сложных команд в некоторых играх приводило даже к судорожному нажиманию всего подряд, "пока не сработает".
- Виды танков. Рекорд, конечно, у Carrier Command - всего два вида танков, но способных нести разное вооружение/оборудование (было еще несколько боевых машин, но они являлись частью авианосца).
- В большинстве остальных, возможность вооружать танки по-разному сохранилась. Впрочем, никаких особо интересных танков ни в одной игре нет - обычный типовой набор реал-таймовых стратегий, скрывающий за разнообразием пушек отсутствие баланса и никак не вписывающийся в масштаб игры (песочница!).
- Опять дилемма: строить вселенную вокруг танков, или добавлять танки по сюжету?
- Ничего не получается - кроме идеи объединения нескольких уровней в одной игре, остальные решения рассыпаются в труху.

Однако, это значит, что идея очень сильная, способная поднять очень слабый сам по себе проект.
***

Стоит также отметить, что кроме очевидной пары BattleZone (1980-1998): стрелялка - "стратегия", существуют пары и у других упомянутых игр: Carrier Comman - Battle Command и Hostile Waters - Incoming Forces. Во всех случаях - танковые стрелялки.
Наверное, между супертанком - королем песочницы и стратегией по управлению миром песочницы есть глубинная психологическая связь...

НАВЕЯЛО:



Более интеллигентный генерал:



Самый амбициозный генерал:



Ракетный генерал:



И еще адмирал:



К сожалению, имбецильное лицо c обложки Carrier Command 2012 эту серию продолжить не может...

Настольная игра 1938 года: