Вторая часть задачи — написать программы поведения игроков. Каждая программа-игрок должна быть в состоянии отвечать на любые запросы программы-банкира по ходу игры: она должна уметь предлагать цену на сырье, принимать решения, продавать готовую продукцию и т. п. Если для моделирования используется диалоговая система, реализуйте одну из программ-игроков таким образом, чтобы она просто передавала свои запросы игроку-человеку, находящемуся за терминалом. Такая программа должна уметь отвечать на запросы человека о состоянии игры.
После того как будет написано несколько программ-игроков, их надо объединить с программой-банкиром, чтобы получилась полная игровая система. Проведите с этой системой несколько игр и изучите результаты. Заметим, что несколько экземпляров одной и той же программы-игрока вполне могут выступать в качестве противников (т. е. мы считаем людей в соответствующей реальной игре изначально одинаковыми). Но для полной гарантии надо написать хотя бы две нетривиальные программы-игрока.
Указания исполнителю. Эта игра — пример последовательного, или пошагового, моделирования, при котором все события (кроме банкротств) происходят в строго определенном, заранее известном порядке. Цикл по месяцам — удобная структура для ведущей программы. Редко можно встретить задачу на программирование, прикладную или научную, столь удобную для хорошо структурированной реализации, как эта. Не премините воспользоваться такой возможностью.
В формулировке первой части задачи имеется некий подводный камень. Программа-банкир должна защищать всю существенную информацию от несанкционированного доступа программы-игрока. Иначе говоря, программа-банкир должна сохранять в тайне все счета, как свои, так и игроков, обеспечивать секретность торгов и в то же время предоставлять игрокам информацию в ответ на их запросы. К сожалению, во многих языках обеспечить это бывает трудно, если вообще возможно. В Фортране критические значения не должны помещаться в общих блоках, поскольку доступ к общим блокам программы-игрока не контролируется. В языке с блочной структурой критические значения не могут быть глобальными по отношению к программам-игрокам по той же причине. Даже если предположить, что программа-игрок не допускает таких нарушений правил исходного языка, как, например, выход за границы массива или пользование автокодными вставками, обеспечить полную сохранность трудно. Один из моментов, который должен найти отражение в документации, — средства сохранности и их надежность.
Инструментовка. Эта задача прямо-таки просится, чтобы ее реализовали на языке с развитыми управляющими структурами. Потребность в совершенных структурах данных не столь велика. В качестве возможных кандидатов можно рассматривать Кобол и Фортран, но их недостаток — в их бедности. Для решения подобных задач успешно использовался APL, но в этом случае программу трудно хорошо структурировать. Вы вряд ли найдете язык, удовлетворяющий упомянутым выше требованиям к защите данных.
Длительность исполнения. Одному исполнителю на 4 недели, двум — на 3 или трем — на 2. Две недели должно уйти на программу-игрока.
Развитие темы. Дополнительное удовольствие от программирования игр — возможность поиграть с программой-игроком. Иногда при применении совсем простых эвристических методов может получиться удивительно сложное поведение. В программу, реализующую стратегию игрока, несложно включить элементы самообучения, чтобы ее поведение со временем совершенствовалось. Проведите несколько тренировочных турниров с участием как людей, так и программ (люди тоже обучаемы). Имеется стандартный прием обучения интеллектуальных программ новым стратегиям. Один экземпляр (Альфа) обучается в тренировочной серии игр, второй (Бета) остается на том же уровне знаний, какой он имел перед этой серией. Затем устраивается сравнительная серия игр между ними; если Альфа побеждает, его знания передаются всем копиям программ-игроков, в противном случае Альфа эти знания забывает как бесполезные и с ним проводится новая тренировочная серия.