Значительное влияние на результат моделирования оказывает порядок, в котором осуществляется обработка функций перехода. Рассмотрим, например, анимат, который находится в состоянии . Сразу после обнаружения присутствия противника анимат будет вводить в действие режим охоты. С другой стороны, если в ближайшей окрестности будут обнаружены доспехи, то может стать активным состояние сбора доспехов. Но применение этих вариантов потенциально приводит к возникновению трудноуловимых программных ошибок. Согласно теории, конечный автомат, по существу, интерпретирует символы, заданные в том или ином порядке, с учетом реализации, а это означает, что малейшие недочеты в проекте могут повлечь за собой непредвиденные результаты. Таким образом, применение процедурной реализации может привести к получению совсем других результатов, чем предусмотрено в самом проекте. Указанная особенность может трактоваться как своего рода недетерминированность . Потеря данных Если код является чисто процедурным, то каждый переход проверяется динамически. При наличии двух условий перехода, которые одновременно становятся истинными, обрабатывается только первый переход, а второй игнорируется. Вообще говоря, применение данного подхода приводит к тому, что фактически отбрасывается вся информация об условиях переходов, которые обнаруживаются после того, как было принято первое условие. Предположим, что анимат находится в боевом режиме. Но внезапно происходит так, что одновременно становится очень низкой его жизнеспособность и вблизи появляется объект доспехов. Проверка на наличие доспехов осуществляется в первую очередь, поэтому становится активным состояние сбора доспехов. Но анимат игнорирует другую составляющую сложившейся обстановки и забывает о том, что в связи с низкой жизнеспособностью необходимо выполнить переход в состояние бегства, и в результате становится застреленным. Возникновение этой проблемы обусловлено той неоднозначностью, которая возникает при использовании простого процедурного кода. Во многих подобных случаях игнорирование необходимых переходов может привести к возникновению не полных или несовместимых форм поведения. Еще раз отметим, что результатом становится возникновение ошибочных форм поведения, на потенциальную возможность обнаружения которых сам проект конечного автомата отнюдь не указывает. Управление потоком данных Обработка переходов в коде может осуществляться с помощью процедур, связанных с состояниями. Но в действительности часто проще проверять переходы во время обновления, что позволяет также исключить возможность избыточной обработки. Тем не менее остается нерешенной проблема, связанная с выбором направления дальнейшей передачи управления. В частности, приходится искать ответы на вопросы о том, следует ли немедленно выполнить переход и не лучше ли вместо этого в процессе моделирования продолжать обрабатывать процедурный код состояния. А во втором случае необходимо принять решение о том, как действовать, если имеется несколько переходов, которые должны произойти в разное время в течение обновления состояния. Средства усовершенствования процедурного управления Первым шагом к устранению указанных проблем должно стать их выявление. Затем, после обнаружения того, что проблемы действительно возникают, могут быть приняты меры по их устранению. Но лучший подход состоит в определении методологии, полностью исключающей возможность возникновения проблем рассматриваемого типа. Необходимость в перепроектировании В качестве причины большинства возникающих проблем может рассматриваться необходимость сталкиваться с крупными процедурами поддержки состояния . Попытка решения этой задачи, соответствующая стилю работы программистов, могла бы состоять в том, чтобы найти такой прием, характерный для используемого языка программирования, который позволил бы упростить проблему. Например, процедура поддержки состояния могла бы самостоятельно проверять условия перехода и возвращать код, указывающий на то, какой переход является необходимым. Если же для моделирования рассматриваемого состояния требуется несколько вложенных процедур, то коды возврата должны иметь каскадную структуру. Но инженер по искусственному интеллекту, ознакомившись с подобным предложением, может понять, что с его реализацией связано выполнение большого объема избыточной работы и что каждый из путей выполнения кода фактически может быть осуществлен с помощью самого конечного автомата. Для практической реализации такого замысла необходимо добиться того, чтобы в любом случае проверке подлежало лишь единственное ограничение, а процедуры поддержки состояния были неразрывными и прерывание их работы не допускалось. На основании этого принципа может быть спроектирован весь конечный автомат, а необходимость использовать вместо этого программистские трюки в качестве временного решения полностью отпадает. . Эмоции Глава . В частности, рекомендуется отделять друг от друга переходы и процедуры поддержки состояния. В таком случае появляется возможность выработать соглашение, позволяющее отдельно принимать решение по обработке переходов. Обычно все переходы проверяются после того, как будет завершено обновление состояния. Желательно также включить сразу все переходы в одну группу. Проблемы неоднозначности могут быть устранены очень просто. В таком случае переход с наивысшим приоритетом должен проверяться в первую очередь, а остальные должны отбрасываться. Данные о приоритетах могут быть встроены в проект и переведены непосредственно в код. Тем не менее все еще остаются две проблемы, которые не могут быть устранены за счет указанной реорганизации кода. Передача сообщений Решение обеих этих проблем позволяет найти небольшая структура данных, предназначенная для временного хранения запросов на выполнение переходов. Эта структура данных может представлять собой простой механизм передачи сообщений, который, тем не менее, используется для моделирования последовательности входных символов.