Приложение к заметкам о простых играх (полукомпьютерная игра TANKTICS, 1978)

Перейти вниз

Приложение к заметкам о простых играх (полукомпьютерная игра TANKTICS, 1978)

Сообщение автор Gudleifr в Чт Сен 07, 2017 12:49 pm

ЛИРИЧЕСКОЕ ОТСТУПЛЕНИЕ. Как я уже писал раньше, все военные игры огульно делю на группы (не забываем, что возможны и смеси; и что это не столько виды игр, сколько виды игроков):

1. Абстрактные.
1а. С миниатюрками.
2. Офицерские.
3. Военно-исторические.

В этот раз я хочу поговорить о временах, когда задумались о переносе игр 3-й группы на компьютер. (О компьютеризации остальных групп говорилось и так много. Примеры из группы 1 давно стали каноническими примерами программирования; про 2-ю мы уже 50 лет регулярно узнаем из специальной литературы; про 1a - наоборот, только и слышим проклятия из стана любителей солдатиков, клянущих покушающихся на их экологическую нишу программистов). А, вот, с 3-й группой вопрос очень интересный. И, конечно, спорный. Ведь любой поклонник гексов и жетончиков, очевидно, считает поклонников остальных групп "неваргеймерами", и твердо уверен, что только его способ моделирования военных действий воистину реалистичный, военно-исторический и подобающий не мальчику, но мужу.
Разумеется, любая модель в какой-то мере ограниченна. Иначе, она была бы не моделью, а реальностью. (Кстати, есть четкие критерии оценки применимости и адекватности моделей, их изучают поклонники 2-й группы). И говорить о том, что 3-я модель самая честная не приходится. Однако, если у автора хватает умения подпеть военному честолюбию "воинов выходного дня", то проект всегда сверхуспешен.
Т.о. перенос игр 3-й группы на компьютер должен быть соответствующим образом обставлен. Нельзя просто выдавать результаты столбцами. Надо показать что-то очень простое и красивое. А как быть, если на дворе конец 70-х и компьютеры еще совсем дохлые? Одновременно несколько производителей предложили выход (не только для военных игр) - сделать игру наполовину компьютерную, наполовину настольную. КОНЕЦ ЛИРИЧЕСКОГО ОТСТУПЛЕНИЯ.
***

Итак, Avalon Hill (как же без них), игра TANKTICS - 1978 (Commodore), 1981 (Atari, Apple...). В комплект игры входит игровое поле (24*32 гекса), жетоны и компьютерная программа. Курск 1943. Игрок за немцев, компьютер - за наших. В смысле - понятно, что компьютер не может сам двигать жетоны и видеть карту, игроку приходится самому дублировать свои ходы на клавиатуре и двигать советские жетоны согласно указаниям компьютера.


Выглядит это, по нынешним временам, жутковато.

СЦЕНАРИЙ #1. ВСТРЕЧНЫЙ БОЙ. Компьютер размещает танки игрока и свои куда попало. Определяет целевой гекс, кто достигнет его раньше, тот и победил.
СЦЕНАРИЙ #2. КРУГОВАЯ ОБОРОНА. Танки (орудия) игрока защищают целевой гекс, танки компьютера - атакуют.
СЦЕНАРИЙ #3. ЗАХВАТ. Тоже,что и #2, только игрок атакует, а компьютер обороняется. Компьютер берет себе противотанковые орудия.
СЦЕНАРИЙ #4. ФРОНТ. В этом сценарии игрок располагает свои танки (орудия) в столбцах H-L. Целевой гекс помещается где-то в столбцах A-G. Танки компьютера пытаются прорвать фронт.
СЦЕНАРИЙ #5. ПРОРЫВ. Тоже,что и #4, только игрок атакует, а компьютер обороняется. Компьютер берет себе противотанковые орудия.

ПАРАМЕТРЫ ТАНКОВ. (В скобках - значения в программе). И, конечно, это далеко не 1943-й.
GERMAN UNIT TYPES:
CODE #UNIT TYPEARMORGUN TYPEMOVEMENT COSTS
1PANZER IIIjThin (3, 2, 3)Weak (40)8
2PANZER IVhModerate (4, 2, 1)Moderate (60)7
3PANZER VGood (7, 2, 2)Good (100)11
4PANZER VIeThick (5, 4, 3)Good (80)8
5PANZER VIbVery Thick (9, 4, 3)Very Strong (130)7
650mm AT Gun* (3, 3, 3)Moderate (60)0
775mm AT Gun* (3, 3, 3)Good (100)0
888mm AT Gun* (3, 3, 3)Very Strong (130)0
RUSSIAN UNIT TYPES:
CODE #UNIT TYPEARMORGUN TYPEMOVEMENT COSTS
1T34/76cGood (4, 3, 2)Moderate (60)11
2T34/85Good (5, 3, 2)Good (80)11
3KV-IThick (4, 4, 4)Moderate (60)6
4KV/85Thick (4, 4, 4)Good (80)6
5JS-IVery Thick (7, 5, 3)Strong (100)7 (6)
6JS-IIVery Thick (7, 5, 3)Very Strong (130)7 (6)
776mm AT Gun* (3, 3, 3)Good (80)0
Скачать версию для Atari (с картами и жетонами) в Сети труда не представляет - RAR, 1.47Мб . Интересно другое: за исключением 1.5кб двоичного кода вся игра написана на BASIC, т.е. можно посмотреть, "как оно устроено". Программа состоит из 2-х BASIC-модулей. Первый (ок.20 строк) загружает в память бинарный код 16-ти процедур (1279 байтов, ок.550 команд) и карту (384 байта - по 4 бита на гекс), заполняет пару других массивов и передает управление второму модулю. Тот (ок.200 строк) дозаполняет массивы и переходит к циклу игры, время от времени обращаясь к кодовым процедурам. Такая организация требует двух видов массивов данных - как обычных BASIC-овских, так и расположенных по определенным адресам в памяти (доступных по PEEK и POKE).


Последний раз редактировалось: Gudleifr (Ср Дек 06, 2017 10:22 am), всего редактировалось 1 раз(а)
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложение к заметкам о простых играх (полукомпьютерная игра TANKTICS, 1978)

Сообщение автор Gudleifr в Чт Сен 07, 2017 1:01 pm

БЛОК-СХЕМА

Изначально можно выделить два блока ПРЕВРАЩЕНИЯ (т.е. изменения положения или статуса фрагмента в окружении). В BASIC они выглядят одинаково - читаю символы/числа из строки программы и запихиваю в массив (чтение: через присваивание строкового литерала или READ из строки DATA, запись - присваиванием или POKE, с возможным ASC для получения кода символа).

1. ПРЕВРАЩЕНИЕ (литералы-массивы, литералы-код, read-массивы) - первый BASIC-модуль целиком.

2. ПРЕВРАЩЕНИЕ (read-массивы) - начало второго BASIC-модуля, тут же кусочек простейшей РЕГИСТРАЦИИ - настройка указателей на массивы, заполненные в (1).

Т.о. ПРЕВРАЩЕНИЕ, как всегда перерастает в РЕГИСТРАЦИЮ (поддержку программной базы данных; здесь БД не такая уж и маленькая - десятки фишек с кучей параметров).

3. РЕГИСТРАЦИЯ (заполнение массивов константами) - фиксация начала новой игры. Включает следующий ВВОД.

4. ВВОД параметров игры. Сначала вводится номер сценария (1-5). Затем, число танков игрока (1-8 ), компьютер берет себе вдвое больше. Остальные вводимые данные зависят от номера сценария. Если сценарий 2 или 4 (оборона) то для танков (для каждого танка тип указывается отдельно) игрока возможны типы 1-8 (т.е. не только танки, но и противотанковые пушки), иначе - 1-5 (только танки). Если сценарий 3 или 5 (атака), тип танков противника - 7 (пушки), иначе вводится тип (1-6) - один на все танки противника. В зависимости от номера сценария генерируется положение целевых точек и расположение танков (обычно, случайным образом, но в четвертом сценарии требуется ввести позиции своих танков). Активно используются кодовые процедуры.

После очевидных начальных РЕГИСТРАЦИЙ должно, по идее, начинаться УПРАВЛЕНИЕ (вещь, иногда достаточно сложная, и местами гомеостатическая, но, понятно, не в этой игре).

5. УПРАВЛЕНИЕ. Во всех пошаговых играх на одного игрока оно выглядит одинаково:
а. ввести данные;
б. если ввели туфту, вернуться к (а);
в. произвести расчет; если в (в) случилась "авария",
г. провести коррекцию и снова - к (в), иначе - к (а).

Разница между играми только в размазывании этого управления по всему коду до такой степени, чтобы никто не догадался о его наличии.
В данном случае можно сразу выделить три основные пути проведения (в):
РЕГИСТРАЦИЯ хода игрока;
ПРЕОБРАЗОВАНИЕ данных по его завершению (ход противника) и
обработка "аварии" "конец игры" - возврат к (3).

6. ВВОД команд игрока. Сначала вводится номер танка, ввод 9-ки (или X) означает конец хода. Затем приказ танку вводится в виде текстовой строки, состоящей из: литеры F - стрелять - и второй литеры - по кому, литеры L - наблюдать (танк после этого еще сможет походить), 0 - пропуск, Q - конец игры; или последовательности литер 1-8 - команды перемещения (на карте есть расшифровка направлений). Команды поворота (7 и 8 ) нужны для того, чтобы в конце движения повернуться мордой к неприятелю.

Вот, собственно, и все.
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложение к заметкам о простых играх (полукомпьютерная игра TANKTICS, 1978)

Сообщение автор Gudleifr в Чт Сен 07, 2017 1:05 pm

ЗАМЕЧАНИЯ ПО РЕАЛИЗАЦИИ

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

2. Основная процедура ввода достаточно забавная. Можно вводить как цифры 0, 1, 2, .., так и буквы A, B, ... A приравнивается к 1, B - к 2 и т.д. Производится проверка - вводимое "число" должно быть не меньше нуля и не больше указанного для операции максимума. Дополнительно разрешен ввод буквы X - символ конца.

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

4. Проверка линии видимости производится перебором гексов, лежащих на пути от танка-наблюдателя к проверяемому танку на пути, как можно более близким к прямому. На каждом гексе пути, кроме того, на котором стоит наш танк-наблюдатель, содержащем лес или гору (на последнем - лес или воронку) кидается "кубик" 0-7 (если наблюдатель на горе - 1-8 ). Если хоть один раз выпадает меньше пройденного числа гексов - линия видимости считается перекрытой.

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

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

7. Стрельба. В зависимости от поворота цели берется значение ее фронтальной, бортовой или кормовой брони. Вероятность успеха считается как

(CONST + Огневая мощь) / (Дистанция * Защитные свойства местности * Броня).

8. Никаких других признаков искусственного интеллекта не обнаружилось (разве что, компьютер при выборе приказа танку пытается заранее оценить результат стрельбы (по той же формуле стрельбы)).
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложение к заметкам о простых играх (полукомпьютерная игра TANKTICS, 1978)

Сообщение автор Gudleifr в Чт Сен 07, 2017 1:08 pm

ЗАМЕЧЕННЫЕ ОПЕЧАТКИ

ЛИРИЧЕСКОЕ ОТСТУПЛЕНИЕ. Многие программисты свято верят, что, если программа работает, то никаких ошибок в ней уже нет. Однако, это не так. В целях удобства можно разделить ошибки "не мешающие работе" на четыре группы, по мере возрастания зловредности:
1. Ошибки, известные разработчикам: временные "заплатки" и "заглушки", куски, тщательная проработка которых оставлена "на потом", и т.п. Их "безвредность" состоит в том, что о них программистам известно, и их надеются рано или поздно устранить.
2. Ошибки, которые корректируются дальнейшим кодом, компилятором или операционной системой: излишние/бесполезные операции, недоинициализация переменных, неосвобождение ресурсов...
3. Ошибки, проявляющиеся только при очень неблагоприятных обстоятельствах: конкуренции процессов, нехватки ресурсов, неадекватных действиях пользователя...
4. Явные несоответствия работы программы техническому заданию и/или документации. То ли программисты "не так поняли", то ли "забыли", то ли решили, что "и так сойдет".

Вообще же главную аксиому программирования никто не отменял: в каждой работающей программе есть две серьезные ошибки, причем, это число не зависит от того, сколько раз программа проверялась и исправлялась. КОНЕЦ ЛИРИЧЕСКОГО ОТСТУПЛЕНИЯ
***

Данная программа, разумеется, не стала исключением:
1. Скорость всех советских тяжелых танков в программе ниже, чем в описании. (Ошибка 4-й группы).
2. Ввод литеры 'X' в некоторых диалогах, не рассчитанных на прием этой команды, вызывает крах BASIC-программы. (Ошибка 3-й группы).
3. Для обозначения числа 2699 (последний гекс, абсциссу которого можно обозначить одной буквой) была введена константа N2699, но ее забыли инициализировать. (Ошибка 2-й группы).
4. Не думал, что удасться найти ошибки 1-й группы, однако не без этого. Удалось обнаружить "забытый в программе" простенький тестовый BASIC-фрагмент, дающий наглядный доступ к упомянутому выше ссылочному блоку.
5. Еще заметил явные заплатки в процедуре расчета перемещений танков компьютера. Ее явно правили, чтобы она хоть как-то заработала. Однако, т.к. танк должен перемещаться более менее "случайно", то отличить здесь "баги от фич" практически невозможно.

И разумеется, где-то еще - "две серьезные ошибки".
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложение к заметкам о простых играх (полукомпьютерная игра TANKTICS, 1978)

Сообщение автор Gudleifr в Пт Сен 08, 2017 9:32 am

ВЫВОДЫ

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

1. Универсальная ЭВМ.
2. Набор "виртуальных драйверов", превращающих ЭВМ в специализированный игровой калькулятор.
3. Программа игры на языке программирования калькулятора, близком к человеческому.
4. Набор "канцелярских принадлежностей" и "органайзеров", ориентированных на ручные операции. Последние и составляют собственно игру.

Конечно, среди присутствующих много людей, способных написать игру целиком, но для начинающего игрока/программиста будет гораздо полезнее покопаться в подобной модульной системе, постепенно погружаясь все глубже и глубже.
Все знают, что хорошенько покопавшись в некоторых играх, можно выделить куски, которые можно легко и безболезненно править: от текстовых ресурсов, до описания сценариев. Не о чем-то подобном говорим и мы? Только не полученном в результате злостного хакинга, а предусмотренном заранее.
***

P.S. Сколько раз, играя в какю-либо "нормальную" компьютерную игру, я пользовался "органайзером", т.е. записывал на бумажке пароли и описания локаций, сохранял скриншоты и т.п...
***

P.P.S. Есть еще два возражения:

1. "Виртуальные драйвера" у сложных игр зело много весят. По сравнению с ними все остальные модули - только тонкая "оболочка". Это, конечно, так. Однако, анализ показывает, что разнообразие основных операций для конкретного класса игр не так уж и велико.
2. Ручная игра парой-тройкой танков, это просто, но если хочется сложных стратегий? Запутаешься цифири вводить. Так, ведь, органайзер же тоже может быть электронным! Универсальный "планшет" для перемещения фишек по гексам и/или диалоговые панели для ввода параметров реализовать не так уж сложно, если заранее устаканить формат обмена между модулями. А на этапе конструирования новой игры, так, просто, приходится вводить данные, если не с бумажки, то из заранее заготовленных файлов и/или программ генераторов.
***

P.P.P.S. А ведь, посмотрев на это убожество под другим углом, можно найти признаки еще одной игры - игры в программирование игр. Взять хотя бы сюжет игры BATTLE ISLE (или фильма TERMINATOR) - борьба людей с компьютерами. Ведь, очевидно, открыв какие-либо уязвимости в программе машин-убийц, мы сможем атаковать по-новому (если и не перепрограммировать их, то заранее предугадывать их поведение).
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложение к заметкам о простых играх (полукомпьютерная игра TANKTICS, 1978)

Сообщение автор Gudleifr в Пт Сен 08, 2017 9:55 am

КАК ПИСАЛСЯ ЭТОТ ОБЗОР

В целях природы обуздания,
В целях рассеять неученья
Тьму
Берем картину мироздания - да!
И тупо смотрим, что к чему...
/А. и Б.Стругацкие, Понедельник начинается в субботу/
***

Сразу отмечу:

- Разбор этой программы я производил урывками на протяжении довольно значительного времени. Поводом "все-таки, с ней разобраться" послужила бурная полемика о проблемах дизассемблирования на одном из форумов.
- Ни в коей мере не собираюсь обосновывать выбор инструментария. Брал то, что было под рукой, даже, не особо заморачиваясь использовать что-либо во "всей его мощи".
- Основное мое жульничество состоит в том, что вся сложность дизассемблирования состоит в большом объеме кода и только в нем. Следовательно, этот маленький пример совершенно не показателен. Для назлядности я буду помечать методики, просто неприменимые для больших программ, меткой !РАЗМЕР!

Сначала я нашел в Сети игру: игровое поле, жетоны, руководство, диск для ATARI. Прочел там же, что игра написана на BASIC, следовательно, есть реальная возможность посмотреть, как она устроена. Особенно, конечно, меня заинтересовало устройство "компьютерного противника". Да и сама идея этакого примитивизма - "простейшая программа + настольная игра" - не могла оставить меня равнодушным.
***

НА ЧТО ЭТО ОКАЗАЛОСЬ ПОХОЖЕ? Сначала я нашел пару эмуляторов ATARI, но ни один из них не понимал такого формата дисков. Зато нашелся преобразователь этого формата в другой, который эмулятор понял. Потратил еще несколько десятков минут на выяснение, каким способом диск подключается к эмулятору и какими клавишами этот эмулятор управляется.
Наконец эмулятор запустился и сразу начал исполнять программу. Пришлось его прервать клавишей Останова. Ура! Вбиваю вечное BASIC-овское LIST и смотрю на код.

Первые выводы:
- Я не знаю ATARI-BASIC, значит надо искать в сети учебник.
- Программа активно использует PEЕК и PОKЕ (операции чтения/записи по конкретным адресам памяти).
- Программа вызывает какие-то кодовые процедуры функцией USR.

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

КАК БЫЛ ИЗВЛЕЧЕН КОД? Я поленился искать более удобный эмулятор, который умел бы выдавать дампы, и просто распознавал в программе FineReader скриншоты выполнения операторов LIST и функций PEEK (для последних, кончно, пришлось писать прямо в эмуляторе простенькие циклы). !РАЗМЕР!

ЗАМЕЧАНИЕ. В случае использования FineReader опечатки ищутся гораздо легче (в силу своей нечеловечности), чем при ручной перепечатке текста на глаз. Поэтому если есть альтернатива: машинное распознавание или негритянская машинистка, выбирайте программу. КОНЕЦ ЗАМЕЧАНИЯ.

Ошибки распознавания в BASIC-программе правил по мере ее чтения, но, вот, ошибки в длинных списках чисел-кодов пришлось искать специально, сверяя количество распознанных чисел и размеры блоков. (Что, конечно, не гарантирует отсутствия ошибок в текстах). !РАЗМЕР!
Функция PEEK выдала мне длинные последовательности десятичных чисел, которые пришлось переформатировать в то, чем они были изначально - блок байтов с соответствующими значениями. Для этого я написал простенькую C-программку.

ЗАМЕЧАНИЕ. Если вам по работе требуется постоянно писать простенькие программы преобразования текстовых и бинарных файлов, а машины с Linux/Unix под рукой нет, то проще всего поставить под Windows программу Cygwin - эмулятор Linux. Конечно, его установка требует некоторых "танцев с бубном", но, зато, потом - C, Perl, Shell, sed, awk, lex/yacc, Tcl/Tk, TeX... КОНЕЦ ЗАМЕЧАНИЯ.
***

ДИЗАССЕМБЛИРОВАНИЕ. (Про BASIC пока забудем). Получившийся бинарный файл с кодами процессора (конечно, сначала пришлось выяснить, что ATARI работает на процессоре M6502) я скормил дизассемблеру IDA (к счастью, тот знает про данный процессор).
Каюсь, за все годы работы с IDA я все больше и больше забывал о всех его наворотах (как-то всегда его возможности были перпендикулярны моим задачам). Поэтому сейчас даже не стал заморачиваться с переносом кода по правильным адресам (хотя IDA сильно ругался, что код пересекается с данными). Тупо ткнул клавишу C[ode] в тех местах, которые были загружены в "промежуточный блок" (пересчитал их в обычном калькуляторе) и скинул получившийся текстовый фрагмент в файл. !РАЗМЕР!
Вроде срослось, значит, не сильно при распознавании наврал.

ЗАМЕЧАНИЕ. Что есть процесс дизассемблирования/декомпиляции? На входе - тысячи строк кода, на выходе - пара абзацев связного литературного текста. Очевидно, должны быть промежуточные представления - в сотни строк, в десятки строк... Т.е. во-первых, нужен какой-то алгоритм "сокращения" (которого, на самом деле не может быть), а, во-вторых, ничего нельзя поделать с тем, что при каждом "сокращении" теряется часть информации, может быть, делая дальнейший процесс бесполезным.
Даже на первом шаге (распознавания байтов как команд процессора и формирования листинга программы) уже возможно просмотреть что-то полезное: что некоторые куски кода могут впоследствии модифицироваться, перемещаться в памяти, накладываться друг на друга...
Создатели IDA, конечно, приложили огромные усилия, что бы облегчить промежуточные представления кода, но пользоваться их методами не всегда удобно, а иногда и невозможно. КОНЕЦ ЗАМЕЧАНИЯ.

Последнее, что я сделал, привел, по мере чтения, все числа листинга (кроме массива карты) в десятичный вид, чтобы не путаться.
***

Итого, программа распалась на следующие, вполне обозримые, фрагменты:
- Стартовый BASIC-модуль. После того, как я записал "на бумажке", какие массивы и чем он заполняет, особой надобности в его хранении нет.
- Основной BASIC-модуль. Обозначим его как BASIC-II. В его конце расположены нестолько процедур (вызываемых по GOSUB), к счастью, не имеющих дополнительных точек входа (это когда одна процедура, вместо честного возврата, плавно переходит в другую). Обозначим их (по номерам строк): B10000, B11000, B11500, B11600, B12000, B12600, B13000, B14000, B15000, B16000, B17000, B18000, B19000, B19967, B20000, B20100, B21000, B21100. !РАЗМЕР!
- Кодовый модуль, в свою очередь, состоит из 16 процедур (обозначим их по адресам переходного модуля): P1023, P1027, P1031, P1035, P1039, P1043, P1047, P1051, P1055, P1059, P1063, P1067, P1071, P1075, P1079, P1083. Адреса P1063 и P1067 - это дополнительные точки входа в процедуру P1059. !РАЗМЕР!
Очевидно, в большой программе процедур столько, что их приходится распознавать (очевидно, начерно) каким-либо автоматическим способом и регистрировать в какой-либо базе данных.
С каких процедур начать? С BASIC или с кодовых? Сверху или снизу? Если идти от BASIC (это возможно, т.к. я примерно знаю, что делает программа), то я смогу составить примерное мнение о внутренних процедурах еще до того, как перейду к их разбору. Здесь же можно дополнительно опереться на процедуры ввода/вывода, дающие мне человеческое толкование некоторых переменных. Идя снизу, я точно буду знать, что делает тот или иной кусочек кода, но получить человеческое толкование этого действия еще надо будет постараться. !РАЗМЕР! Понятно, в большой программе еще помучаешься, определяя место процедуры в общей иерархии.
Т.к. я принимался разбираться с этой программой несколько раз в различном настроении, то принимался ее разбирать то так, то этак, скорее выдергивая легко распознаваемые куски, чем планомерно сокращая "область непознанного".
Да, еще, я завел таблицу переменных (по именам и по адресам). Чтобы отмечать все случаи обращения к ним из процедур. !РАЗМЕР!
***

ЛЕГКИЕ КУСКИ.
- B19967. Эта процедура вообще выпадает из общего алгоритма, ее никто не вызывает. Она печатает первые байты кодовых процедур, выдергивая их адреса из "промежуточного блока" (те самые адреса). Очевидно, это просто отладочный код, используемый при разработке программы для контроля.
- B10000. Это процедура ввода (опознана по опросу клавиатуры и символьно-числовому преобразованию). Главный признак того, что процедуру будет легко разобрать, это минимальное число ее связей с другими по глобальным переменным и массивам. Здесь такая переменная всего одна. Вторая, очевидно, сугубо временная.
- B21100. Чистка/позиционирование на экране. Единственная строка очевидных операторов. Настолько проста, что совершенно непонятно, кто и с какой целью может ее использовать.
- B21000. Выполнить B21100 для строк с 16 по 23. Очевидно. Очистка части экрана. И позиционирование.
- B18000. Пауза. Просто пауза. Понятно, что тоже может быть применена в любом интерфейсном фрагменте.
- B17000. Пример использования B18000 - выдача сообщения о нехватке очков хода танка для заказанного пути. Соответственно обрезает команду на перемещение до приемлемой длины.
- B15000. Вызов P1023. И все. Зато в этой процедуре мы видим как связаны некоторые BASIC имена с адресами, используемыми в P1023. Судя по именам, это X- и Y-координаты.
- B14000. Еще одна оболочка вызова - P1035. Получаем еще несколько связей.
- B11600. P1055.
- B12600. P1051.
- P1083. Прокрутка экрана (опознана по обращениям к экранной области памяти). Еще одна ничего не говорящая экранная процедура. Разве что, по ее вызовам отслеживать конец/начало хода. Но их можно выловить и по циклам BASIC-II, хотя, если программа большая, такие "очевидные" куски служат чуть ли не единственными "путевыми указателями".
- P1031. Генератор случайных чисел. Процедура небольшая и вполне изолированная, однако ее алгоритм был не особенно понятен. Какой-то массив, в котором что-то складывается и сдвигается... Пришлось посмотреть в BASIC-II обращения к этому массиву. В начале программы туда загружается что-то подозрительно похожее на значение таймера. Случайные числа? Пришлось лезть во второй том "Искусства программирования" Кнута, чтобы убедиться, что речь идет о т.н. аддитивном генераторе. Для проверки написал его модель на C и немного погонял. Достаточно равномерный.
- P1079. Опять какая-то очень простая фигня. Никаких параметров. Добавляем 3 к значению аккумулятора и, если получается 7 и больше, то вычитаем 6. Вовремя вспоминаю, что направление в игре определяются числами от 1 до 6 (прямо на игровом поле так нарисовано). Разворот на 180град.? Но, зачем?
***

ЧИТАЕМ ИНСТРУКЦИЮ? Раз уж я начал подсматривать в документации, то поищу самый характерный кусок - карту поля боя. Да вот же она - начало блока кодовых процедур (первая из них начинается с 384 байта). 32 * 24 / 2 = 384. Сравниваю гексы на карте и в блоке - так и есть. Каждый байт - два гекса, по 4 бита на гекс. Заодно замечаю, что кое-где ошибся при распознавании. Когда доделаю, надо будет сравнить как следует.
На радостях начинаю искать и другие, описанные в документации, массивы констант. Нахожу: массив проходимостей разных типов местностей, массив скоростей танков, а, проявив немного воображения, и массив бронирования танков (спереди, сзади, сбоку?) и силы танковых пушек. (Заодно выясняю, что лучший танк ВОВ, по мнению авторов игры - "Пантера", ее параметры авторы завысили по всем статьям).

Посмотрев на использование этих массивов, опознаю пару процедур:
- P1035. Получение параметров гекса. Вот, что мы вызываем в B14000.
- B20100. Стрельба танка по танку. А, заодно, и еще один массив - каких-то параметров типов местности (защита?, видимость?).
- B20000. Та же стрельба, но с довеском: сравниваем результат со случайным числом.
***

Продолжаю тупо расшифровать кодовые процедуры. Когда совсем не понятно, смотрю в BASIC-II, чтобы посмотреть, с какими параметрами они вызываются. Веду записи в сводной таблице переменных. Пытаюсь запоминать/записывать, кто кого вызывает.

- P1039. Смещение к соседнему гексу в заданном направлении. Используется два массива: приращений X- и Y-координат для всех 7-и направлений (включая 0 - стояние на месте). Компенсация того, что нечетные столбцы смещены на полгекса вверх относительно четных, производится тут же, специальными добавками. (Очевидно, что, применяя другую систему координат, вычисления можно было бы здорово упростить. Оставив строки и столбцы для показа игроку, в программе было бы удобнее оперировать столбцами и диагоналями).
- P1051. Поиск танка игрока по координатам. Непонятно, зачем. Проверяются все танки игрока, за исключением какого-то одного (текущего?) и танков, у которых сброшен какой-то флаг. Возвращается 0, либо номер танка (тут еще одна тонкость, в BASIC танки логично нумеруются с единицы, а в кодовой части - с нуля, приходится постоянно пересчитывать в уме, аналогично - с координатами). Да, к этому времени, я уже подсмотрел во фрагменте ввода сценария, какие переменные обозначают число танков игрока и компьютера. (К сожалению, фрагменты расстановок танков оказались слишком замысловаты в своем взаимном переплетении, и я их отложил на потом). А анализ этой процедуры дал мне адреса массивов координат танков и их дееспособности.
- P1055. Поиск танка компьютера по координатам. Полностью тоже самое, что и предыдущая.
***

ТРУДНОСТИ ГЕКСОВОЙ АРИФМЕТИКИ. Ключевой процедурой для всех оставшихся кодовых кусков является P1023.

Она практически распадается на 5 простых фрагментов:
1. Нахождение разностей (и их абсолютных величин) координат гексов (по X и Y отдельно). Почему-то (для верности?) из них вычитается еще 1. (Это мне тогда так показалось).
2. Грубое определение направления от одного гекса на другой. По знакам разностей. Вертикальные направления "строго вверх" и "строго вниз" пока не определяются, только "вверх-вбок" и "вниз-вбок".
3. Уточнение направлений, расчет каких-то дополнительных параметров.
4. Финальная перетасовка результатов. Никаких расчетов, полько перемещение данных.
5. Процедура P1027 (учет вертикального смещения четных/нечетных столбцов), вызывается из (3).

Вроде бы все очевидно, но, исходя из моего понимания, того что, вроде бы, должно происходить в (3), там делается что-то совершенно обратное. Вроде бы вертикальные направления должны считаться там, где расстояние по вертикали больше, чем по горизонтали, а тут, вроде бы, наоборот... Пришлось взять паузу и заняться другими делами...

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

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

ЗАМЕЧАНИЕ. Возможна ли автоматизация таких действий? Метод называется "Доска объявлений". "Доска" разбита на строки. В самой нижней строке записываются распознанные "буквы". Как только букв накопится достаточно, запускается одна из связанных с этой строкой экспертная система, собирающая из "букв" "слоги". "Слог" записывается в следующую строку. Экспертная система следующего уровня собирает из нескольких готовых "слогов" "слово". И так далее, пока в верхней строке не соберется "фраза". Если "фраза" (а, может, уже "слово") оказывается бессмысленной, экспертным системам нижних уровней предлагается пересмотреть свои действия. По другим критериям, с учетом вероятных ошибок, другими методами... Ошибки, конечно, желательно исправлять на более высоких уровнях, но процесс пересмотра может все вернуть и на этап распознавания "букв"...
К сожалению, надежды, что подобные методы станут общеупотребительными, были похоронены в 92-м году, когда японцы окончательно прикрыли проект создания компьютеров "пятого поколения". КОНЕЦ ЗАМЕЧАНИЯ.
***

ОСТАВШИЕСЯ КОДОВЫЕ ПРОЦЕДУРЫ.
- P1047. Найти гекс, случайно удаленный от данного на 3-6 гексов (не озеро и не равнина). Используются процедуры: связка P1031-P1039 (сдвинуться в случайную сторону на 1 гекс), P1023 (найти расстояние) и P1035 (проверка гекса).
- P1043. Линия видимости от танка до танка. Опять используются те же четыре "основные операции".
- P1075. Еще одна странная промежуточная процедура, ищем гекс, удаленный от нашего на 9. И, зачем-то, находим половину числа танков компьютера.
- P1071. "Замыкание" цепочки процедур P1075, P1079. Раскидать танки компьтера на две кучки, удаленые от текущей на 9 гексов. (Как показало дальнейшее рассмотрение, P1079 используется еще и в другом месте (P1067), причем, очень активно).
Странно, массивы для координат этих кучек пока мне не встречались. Да и направления этих "удалений" какие-то странные. Случайные? Ставлю крестик - если встретятся эти адреса, не забыть сюда вернуться.
- Наконец, P1059-P1067-P1063. На первый взгляд, это одна процедура с двумя дополнительными входами. Вход P1059 - это просто установка в 0 двух переменных, далее следует P1067. За куском P1067 следует P1063, а в конце P1063 следует прыжок на P1067. Во, напутали...
На самом деле - два "дополнительных входа" появились только в связи с невозможностью записать "длинные переходы" иначе, чем через наш ссылочный блок. Т.е. процедура самая обычная, просто - с циклами.

(На этом месте я опять прервался, поэтому перед тем, как вернуться к чтению, снова пересчитал все переменные кодовых процедур. !РАЗМЕР!)

На самом деле, такие "путаные" куски разбирать даже приятно. Чем больше там проверок и прыжков, тем меньше остается места на нетривиальные вычисления непонятно-чего. Тем больше вероятность узнать в куске что-то стандартное. Переменные, которые проверяются при принятии решений на передачу управления или зацикливание, прямо-таки вопиют о логике фрагмента.
Главное, не запутаться в толковании условий (как я выше) и придумать для себя какой-то удобный способ записи блок-схем. Т.к. я пишу лежа на диване, то рисовать на бумажке неудобно. А на компьютере рисовать не удобно (сколько лет плодятся всякие "офисы", но удобной программы "для заметок" как не было, так и нет). Поэтому приходится использовать метод последовательных приближений - постепенного замещения в тексте неважных для текущего рассмотрения кусков краткими комментариями. Сначала заменяю ассемблерные операции операндами псевдо-C. Затем пытаюсь записать петли программного управления более-менее структурно. Потом не влияющие на ветвление куски заменяю однострочными комментариями... В конце, в идеале должна остаться всего одна фраза - описание фрагмента на человеческом языке.
Потом... Потом я это все выкидываю. Т.к. все эти "рисования" (как и сам предыдущий абзац) - лишь свидетельство того, что думать по-настоящему лениво.
При рассмотрении "через призму", стало очевидным, что речь идет об операции перемещения танка компьютера. Стало понятно, зачем нужна P1071: назначение танкам "вторичных целей", чтоб не толпились. А, заодно, и P1051 с P1055: проверяем, не въехали ли в кого.
Здесь должен бы быть "Искусственный разум", но его нет - простейшая оптимизация на каждом проходимом гексе.
***

ОСТАЛИСЬ BASIC-ПРОЦЕДУРЫ.
- B11000. Вызов B11500, B11600. Да не просто так, а в двух циклах - по танкам компьютера и до успеха. Т.е. B11500 ставит танки, а B11600 проверяет, не попали ли они друг на друга. Заодно заполняются массивы танков компьютера для кодовых процедур.
- B11500. Ставит танки обоих сторон. Зависит от сценария. Два способа случайной генерации позиций и, в 4-м сценарии, возможность расставить танки вручную.
- B12000. Аналогично B11000, только для танков игрока. B12600 вместо B11600.
- B13000. Генератор совсем уж случайной позиции на карте. Использует B14000 (как помним, анализ гекса - B1035).
- B15000. Процедура расчета текущего значения победных очков в зависимости от количества оставшихся танков (обоих противников) и их удаленности от целевых гексов.
- B19000. Расчет танковых таранов. Просто "по монетке", без учета чего бы то ни было.
***

ОКОНЧАТЕЛЬНАЯ СБОРКА. Я не всегда упоминал при разборе процедур, что, как только начинал сомневаться в правильности разбора, не стеснялся подсматривать в контекст ее вызова. Т.к. этот процесс шел постоянно, то "программа в целом" уже достаточно "разобралась сама по себе". Более того, правка и чиркание общего графического представления программы - одно из самых больших удовольствий разбора. Этакий план генерального сражения, на котором отмечены "указания генштаба", "рубежи нашего наступления на код", и "внезапные контрудары противника, обманувшего наши ожидания". Рисовать на бумажке полезно и приятно, даже, если мы тщательно заносим все тонкости разбора в специальную базу данных.

ЗАМЕЧАНИЕ. На компьютере, к сожалению, такую "карту" не нарисуешь. Разве что, первый вариант, который потом будет исчирикиваться уже в распечатанном виде. Отдельные аспекты могут отражаться к каки-либо MindManager-ах, но такая запись неизбежно будет тормрзить разбор. Сначала будешь приводить информацию в вид, пригодный для записи, а потом расшифровывать обратно. КОНЕЦ ЗАМЕЧАНИЯ.

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

ЗАМЕЧАНИЕ. Вот и все. Игра и ее алгоритм описаны. При желании можно написать такую же. Или лучше.
Но могу ли я дать гарантии, что нигде не ошибся в распознавании и/или понимании? И, даже, если не ошибся, могу ли быть уверен, что не забыл описать что-то важное? Ни в коем случае. "Утешает" только то, что ошибки могли быть и в программе изначально...
И так при любом дизассемблировании (исследовании). Убедиться в правильности и полезности выполненной работы можно только получая от нее практическую пользу.
Так что получать от подобной работы удовольствие по принципу "сделал - отчитался - похвастался" очень проблематично, "сам процесс" гораздо увлекательнее. КОНЕЦ ЗАМЕЧАНИЯ.


Последний раз редактировалось: Gudleifr (Сб Апр 07, 2018 6:11 pm), всего редактировалось 1 раз(а)
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложение к заметкам о простых играх (полукомпьютерная игра TANKTICS, 1978)

Сообщение автор Gudleifr в Пт Сен 08, 2017 10:22 am

РОДСТВЕННЫЕ ИГРЫ - 1

Самая похожая игра. Tank Attack.





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

А в древнейших версиях вместо компьютера использовался специальный прибамбас.



Эта игра (1977) рекламировалась, как первая в мире компьютеризованная игра в танчики. Электронный прибамбас использовался в качестве генератора событий игры. Его основу составляли три TTL-чипа (В сумме - более 300 транзисторов. Если, конечно, еще кто-то помнит, что это такое. В современных-то процессорах этих транзисторов уже миллиарды), тактовый генератор, 6 лампочек, две кнопки и три переключателя (и еще куча соединительной электронной требухи). Сама игра электроникой не контролируется, игроки вручную отслеживают свое перемещение по карте и захват вражеских территорий.
Лампочки прибамбаса (могут гореть, не гореть или мигать) указывают на текущие возможности игрока: "4" и "2" (очки хода?), "RANGE" (дальность огня?), "FIRING RESULT" (результат ведения огня, мигание - не убил, но ранил), "SERVICE READY" (ремонт окончен), "OPTION" (?). Кнопки "COMPUTE" (произвести генерацию ситуации, но результат ведения огня игроку не показывать) и "FIRE" (показать результат ведения огня).
Из трех переключателей один ("ON/OFF") просто сетевой включатель. Остается два - "RETREAT/ATTACK" (игрок выбирает тактику - осторожничать ил наглеть) и "OPTION/SERVICE" (игрок указывает состояние танка - готов или в ремонте).
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложение к заметкам о простых играх (полукомпьютерная игра TANKTICS, 1978)

Сообщение автор Gudleifr в Пт Сен 08, 2017 10:29 am

РОДСТВЕННЫЕ ИГРЫ - 2

Самая похожая гексовая игра. TANK! (журнал Strategy&Tactics, #44, май 1974) - PDF, 11.3Мб

Сначала я даже думал, что эти правила уж слишком сложные. Десяток журнальных страниц. Но, оказалось, что это бесконечные петли повторов. Не предназначен английский язык для изложения технических подробностей.
Что же удалось понять?
(Перевод выкладывать лениво, только, если попросите).
***

Авторы явно пытались добиться играбельности четыремя путями разом:
1. Главной идеей игры была объявлена одновременность событий, происходящих в течение одного хода. Вроде бы все должно упростится: один танк - один момент - одно действие. Но желание разнообразить действия танков привело к куче противоречий. Танки прямо-таки "размазались в пространстве-времени" и вместо "выполнения условия теоремы Котельникова" получился "принцип неопределенности Гейзенберга".
2. Где можно вставили в формулы как можно больше коэффициентов. Мол, чем сложнее, тем реалистичнее. (Впрочем, я знаю множество "военно-исторических" вагеймеров, которые тоже в это свято веруют. Недостаток образования, теперь повсеместный, что поделаешь).
3. Где можно, и где нельзя добавили "трения войны" - и систему приказов, и правила видимости, и панику... Явный перебор.
4. Сделали параметры политкорректными. Американцы - самые сильные. Советские - самые слабые. Самое неприятное, что подобный подход не только воспринимается многими нашими игроками как понятная примета времени, но и как приятное дополнение к "реализму".

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

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

Ну и, конечно, никакого военного реализма в предлагаемой модели нет и не было. Заслуженное второе место после того самого "Дыр-дыр-дыр... Уряааа! Боно-Боно!" в песочнице.


Последний раз редактировалось: Gudleifr (Ср Дек 06, 2017 10:25 am), всего редактировалось 1 раз(а)
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложение к заметкам о простых играх (полукомпьютерная игра TANKTICS, 1978)

Сообщение автор Gudleifr в Пт Сен 08, 2017 10:38 am

РОДСТВЕННЫЕ ИГРЫ - 3

Самая похожая компьютерная игра. Perfect General и Perfect General 2. Мануал к первой версии и таблицы из второй - RAR, 0.44Мб.

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

Что остается? Только слова о том, что на самом деле, это игра не компьютерная, а настольная. Причем, "военная" составляющая этой игры крайне мала - скорее, это игра в "военные машинки".

Ниже привожу правила настольной игры, приведенные в инструкции к компьютерной игре, в надежде получить ответ на вопрос: "В какой момент простенькие домашние правила становятся игрой?"

НЕМНОГО О СЦЕНАРИЯХ
Сценариев - громко сказано. "Сценарий" - лишь карта (с местами расстановки танков) и количество "денег" (на покупку танков). Иногда сценарием предусматривается еще немного денег на покупку подкреплений после какого-либо хода.

Иногда есть "нейтральные области" и игрок, на свой страх и риск, может вовлечь их в сражение.

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

В настройках сценария можно указать, означает ли поражение цели ее уничтожение, или только нанесение ей ущерба.

У серии игр "Perfect General" есть "продолжение" - "Battles in Times". Там над "танчиками" надстроены целых два сценарных "этажа":
1. Танчики объединяются в "армии", которые движутся по "стратегической карте". Встреча же с вражеской армией отыгрывается на "тактической карте" практически по правилам Perfect General.
2. Сценарий игры основан на перемещении во времени, и военные кампании ведутся в доисторические времена (с участием динозавров), в античности, во время Второй Мировой, в 2025 году и, в финальной части, далеком будущем (с инопланетянами).

Графика же игры и возложение комплектования армии на игрока остались теми же.

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

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

Пехота ходит медленно, а возимая артиллерия вообще не ходит, зато, и тех, и тех можно возить на любом танке (кроме самоходной артиллерии). По штуке на танк. Танк наезжает на груз (должен бездействовать на этом ходу), тратит 1 очко движения на погрузку и идет дальше. Аналогично - выгрузка. Груз не стреляет и уничтожается вместе с танком.
***

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

Есть правила на погоду и ночь, но о них почти ничего не написано. Например, ночью нельзя стрелять и двигаться вплотную. Видимость в ясный день - 25. В тумане - 10. Ночью - 5.
***

Цель, назначаемая для артиллерии должна быть видима хоть кем-то. Артиллерией можно стрелять и наудачу, например, по лесу, городу... Огонь артиллерии может случайно дрейфовать до 3-х гексов. В гексе попадания цель уничтожается. Рядом - поражаются с вероятностью 50% (33% для самоходной). В любом случае обстрелянные фишки не перемещаются на этом ходу. Артиллерия (кроме самоходной) может устанавливать огневое заграждение на каком-либо гексе: первая вошедшая - как при ударе, следующие - как рядом стоящие.
***

Все кроме нестрелявшие на этом ходу танки (кроме самоходной артиллерии) могут таранить врага. Выживает при таране только один (получает ущерб). Он остается на гексе, где случился таран. Если протараненный находится в городе, лесу, выше, вероятность успеха падает на 10%. Если протараненный уже отстрелялся - увеличивается на 20%. Если нападавший - поврежден, более, чем на 50% - уменьшается на 20%. Вероятность успеха не может выйти за пределы 5-95%.

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


Последний раз редактировалось: Gudleifr (Ср Дек 06, 2017 10:28 am), всего редактировалось 1 раз(а)
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложение к заметкам о простых играх (полукомпьютерная игра TANKTICS, 1978)

Сообщение автор Gudleifr в Пт Сен 08, 2017 10:45 am

РОДСТВЕННЫЕ ИГРЫ - 4

Наконец, стоит вернуться к первоисточникам - П.Н.Ткаченко и др. Математические модели боевых действий.- М.: "Советское радио". 1969. Глава 5. Стохастические модели боевых действий - ТЕМА #26, АБЗАЦ #16
С одной стороны много слов, о, казалось бы, само-собой разумеющихся вещах, например, об обосновании разбиения поля на клетки. С другой - непривычные для "варгеймеров" параметры и формулы. Но, некоторые алгоритмы TANKTICS, все-таки, явно оттуда.
avatar
Gudleifr
Admin

Сообщения : 725
Дата регистрации : 2017-03-29

Посмотреть профиль

Вернуться к началу Перейти вниз

Re: Приложение к заметкам о простых играх (полукомпьютерная игра TANKTICS, 1978)

Сообщение автор Спонсируемый контент


Спонсируемый контент


Вернуться к началу Перейти вниз

Вернуться к началу


 
Права доступа к этому форуму:
Вы не можете отвечать на сообщения