Этюды для программистов

Игра оканчивается после некоторого фиксированного числа кругов (13 или более) или когда обанкротятся все игроки, кроме одного. Чтобы подсчитать общий капитал компании, надо сложить стоимость всех фабрик (по цене, по которой их можно было бы построить заново), стоимость имеющихся у нее ЕСМ (по минимальной банковской цене текущего месяца), стоимость имеющихся ЕГП (по максимальной банковской цене текущего месяца) и имеющиеся у компании наличные. После этого надо вычесть общую сумму ссуд и предстоящих расходов по уже начатому строительству. Если к концу игры приходит несколько игроков, результаты считаются по их капиталам.

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

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

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

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

Указания исполнителю. Эта игра — пример последовательного, или пошагового, моделирования, при котором все события (кроме банкротств) происходят в строго определенном, заранее известном порядке. Цикл по месяцам — удобная структура для ведущей программы. Редко можно встретить задачу на программирование, прикладную или научную, столь удобную для хорошо структурированной реализации, как эта. Не премините воспользоваться такой возможностью.

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

Инструментовка. Эта задача прямо-таки просится, чтобы ее реализовали на языке с развитыми управляющими структурами. Потребность в совершенных структурах данных не столь велика. В качестве возможных кандидатов можно рассматривать Кобол и Фортран, но их недостаток — в их бедности. Для решения подобных задач успешно использовался APL, но в этом случае программу трудно хорошо структурировать. Вы вряд ли найдете язык, удовлетворяющий упомянутым выше требованиям к защите данных.