То есть (возвращаясь к программированию) становится очевидным, что для эффективной разработки сложных интеллектуальных систем необходимо опираться на элементы, обладающие достаточной самостоятельностью. Как же должен быть устроен Субъект, чтобы реализовать все эти возможности? В первую очередь нужно формализовать на уровне системы существенные особенности такого элемента, а именно:
1. Субъект живет самостоятельной жизнью. Его сердцем является таймер, который как бы «питает» Субъект машинным временем операционной системы.
2. Субъект имеет органы осязания в виде сенсоров. Сенсоры следят за состоянием внешней и внутренней среды Субъекта. На основании анализа этих состояний Субъект выбирает ту или иную линию поведения.
3. Субъект содержит набор линий поведения. Каждая из них представляет собой роль, которая может быть выражена набором подпрограмм, преследующим определенную цель.
4. С роли на роль Субъект переключается самостоятельно исходя из анализа состояния системы.
На самом деле платформа для этого подхода в архитектуре систем подготавливалась на протяжении последних десяти-пятнадцати лет.
Некий прообраз описания Субъекта мы уже имеем, создавая AciveX (COM+) объекты; они могут загружаться в память системы и работать как вполне самостоятельные модули. Здесь в качестве связей с внешним миром используются интерфейсы, которые фактически являются сенсорами. С другой стороны, «магические» свойства операторов переключателей (case и switch) подвигли постановщиков задач для систем автоматического управления на разработку особой методологии программирования — switch-технологии, или автоматного программирования. Эта методология основывается на выделении состояний объекта, что позволяет приблизиться к формализации описания алгоритма программы. Дальше всех продвинулись в управлении объектами, которые по функциональному исполнению вполне подходят на роль Субъектов, разработчики анимационной графики и компьютерных игр.
Таким образом, на сегодняшний день имеется достаточно предпосылок, чтобы попытаться решить задачу формализации описания программного элемента — Субъекта.
Парадоксально, но факт: совершенствование самоорганизующихся приложений в мире информационных систем повторяет эволюцию живой природы — от простейших одноклеточных к более сложным организмам.
Не случайно первыми объектами, хорошо приспосабливающимися к среде обитания, были компьютерные вирусы, чье поведение очень похоже на поведение их «собратьев» из реальной жизни, а именно:
внедриться в тело программы и использовать для «питания» ее машинное время;
скрытно размножиться;
выполнять деструктивные действия в зараженных системах.
Такие «организмы» прекрасно себя чувствовали даже в однозадачной среде под DOS.
Современные многозадачные операционные системы уже сами собой представляют подобие многоклеточного организма, который пытается поддерживать работоспособность системы в целом, находясь в неком симбиозе с пользовательскими приложениями. Клетками этого организма являются службы ОС, выполняющие достаточно большое количество задач, таких как: контроль целостности данных в оперативной и дисковой памяти, контроль работы периферийных устройств, контроль сетевых устройств, управление правами доступа к данным и т. д. Понятие «оживление» напрашивается, а кое-где оно уже введено в индустрии компьютерных игр. Это относится как к процессу анимирования моделей игровых персонажей, так и к логике их поведения. Еще на этапе создания модели в нее могут включаться скрипты, имитирующие бег, ходьбу, повороты, мимику и другие способы анимации. В результате модель уже содержит набор линий поведения, которые могут использоваться разработчиками игр в соответствии с сюжетом. Создатели игровых сюжетов много внимания уделяют логической составляющей в поведении персонажей. До искусственного интеллекта им, конечно, еще очень далеко, но факт появления шахматных программ гроссмейстерского уровня говорит сам за себя.
Спор хозяйствующих субъектов…Многим разработчикам приходилось создавать приложения, напоминающие поведением Субъекты. И каждый решал эту задачу по-своему.
Очевидно, что для стандартизации желательно применять такой способ решения задачи описания Субъектов, который был бы уже заложен в основу компилятора языка программирования. В качестве каркаса, на котором формируется структура Субъекта, можно использовать привычную структуру класса, просто введя в нее дополнительные понятия. Как известно, в описании класса в ООП обычно заложены следующие категории:
свойства — как описание характеристик объекта;
способности — как описание действий с объектом;
правила наследования свойств и способностей объекта.
Остается дополнить объект новыми элементами, относящимися к функциональности Субъекта:
активность — как описание частоты активизации объекта с помощью внешнего или внутреннего таймера;
контроль состояния — как описание сенсоров, которые ответственны за перевод Субъекта из одного состояния в другое;
линии поведения — как описания ролей, исполняемых Субъектом.
Обычно линии поведения уже присутствуют в программе, но они не всегда логически выделяются и структурируются разработчиком.
Таким образом, внешние отличия одного и того же приложения, написанного с помощью ООП и субъектно-ориентированного программирования (СОП), сведутся к тому, что весь «свободный» код[В данном случае «свободным» кодом называется нестандартизованный код, который программист пишет заново для каждого экземпляра объекта] в СОП разносится по соответствующим секциям, называемым ролями (рис. 2).
В этом случае необходимо ввести понятие «состояние Субъекта». Состояние Субъекта представляет собой обычную переменную, в которой содержится «кодовое слово», переключающее алгоритм работы приложения с одной линии поведения на другую. Список состояний Субъектов системы должен быть доступен всем приложениям.
Что наша жизнь? Игра…Следует отметить, что роли могут модифицироваться разработчиком каждого отдельного приложения. Если потребуется сертификация некой линии поведения, то здесь возможно использование уникального ключа (Unique ID, UID). Это позволяет создавать пользовательские «коллекции» ролей, которые потом можно применять и в чужих программных проектах. Дабы обеспечить возможность повторного использования соответствующих ролей в описании Субъекта, формируется специальный раздел, который служит основой для сборки секций ролей в приложении (где можно указывать UID ролей из библиотек). В нем должна находиться информация о том, какому значению состояния соответствует данная роль, а также сведения о задержках переключения алгоритмов.
Функции, реагирующие на события и принудительно изменяющие состояние Субъекта, относятся к категории сенсоров. Эта категория функций весьма условна и выделена только для того, чтобы можно было контролировать последовательность смены внутренних состояний объекта, например — при отладке приложения. Так как тип рассматриваемых приложений предназначен в первую очередь для работы в режиме реального времени, то рационально использовать наиболее надежный и предсказуемый способ организации выполнения программы — циклический.
Проснись — и пой!Активность Субъекта определяется частотой «подключения» таймера к работе. Однако присутствие таймера во внутренней структуре Субъекта совсем не обязательно! Достаточно наличия метода (имеющего определенную структуру) обработки события от таймера. А «оживляться» этот метод может как по событию от внутреннего таймера, так и внешним вызовом.
Блок формирования состояния может понадобиться тогда, когда логика выбора состояния будет достаточно сложна (либо требуется наличие временных функций — задержек). И здесь самым подходящим языком описания алгоритма формирования состояния может служить язык из стандарта IEC 61131-3, применяемый в некоторых контроллерах. Например, для удобства описания интерфейсов СОМ-объектов был даже создан свой язык — Interface Definition Language. Однако этот момент является только предположением, поэтому говорить о нем пока рано. А вот без создания нового краткого «языка общения» между различными Субъектами, возможно, не обойтись.
Действительно, Субъектам достаточно обмениваться сообщениями о состояниях, а не сериями команд управления, как принято при управлении Объектами.
В любом случае, для формализации класса Субъекта все же понадобится разработка дополнительных спецификаций и стандартов, чтобы облегчить и систематизировать как сам процесс программирования, так и процесс использования подобных приложений в будущем.
Однако уже сейчас можно сформулировать несколько правил, которые могут использоваться при создании Субъекта.
Однако уже сейчас можно сформулировать несколько правил, которые могут использоваться при создании Субъекта.
в каждом Субъекте должен присутствовать как минимум один «счетчик жизни»;
в каждом Субъекте должны присутствовать роли запуска и завершения работы приложения;
в каждом Субъекте должна присутствовать «пустая роль» или «роль по умолчанию», которая выполняется в неопределенных состояниях либо в режиме ожидания;
алгоритм выполнения той или иной последовательности действий (роли) не должен быть вшит или «размазан» по программному коду, он должен иметь вид отдельной структурной секции программы;
вызов отдельных методов Субъекта извне допускается, но нежелателен;
в каждом Субъекте должен быть предусмотрен интерфейс обмена информацией с другими Субъектами системы;
все роли Субъекта должны быть подробно документированы в секции описания ролей.
По мере развития глобальных информационных систем и систем компьютерного моделирования реальной действительности субъектное программирование становится все более востребованным. Затраты на расширение функциональности таких систем растут в геометрической прогрессии, поэтому удешевление их разработки весьма актуально.
А для разработки систем, состоящих из множества приложений (от нескольких десятков до тысяч), технология субъектно-ориентированного программирования должна стать основополагающей, и кто знает, может быть, она заложит основу для следующего шага в программировании — создания сложных самоорганизующихся интеллектуальных систем!
Любопытно, что упоминаемая в статье switch-технология предложена российским ученым, представителем Гавриловской школы[ Школа по теории дискретных устройств была организована членом-корреспондентом АН СССР Михаилом Александровичем Гавриловым в конце 1960-х годов] А. А. Шалыто. Она основана на применении в программировании идей теории систем управления. Автор первоначально предложил ее для алгоритмизации и программирования систем логического управления, в которых ввод входных воздействий выполняется по опросу (как, например, в программируемых логических контроллерах и других подобных задачах).
В этой технологии базовым является понятие «состояние». Добавляя к нему понятие «входное воздействие», мы получаем «автомат без выхода». А дополнив технологию «выходным воздействием», мы получаем: автомат = состояния + входные воздействия +выходные воздействия. Соответствующий подход был назван «автоматным программированием».
В дальнейшем Шалыто и Н. И. Туккель развили этот подход для программирования более широкого класса задач. Авторы приводят пример применения switch-технологии при разработке системы управления дизель-генератором, реализуемой на промышленном компьютере с операционной системой QNX, в которой управляющая программа выполняется как один процесс, а программа, моделирующая объект, — как другой процесс. При этом был создан вариант switch-технологии для разработки программного обеспечения более широкого класса систем управления — «реактивных» (reactive), реагирующих на события. Такие системы обычно реализуются на промышленных компьютерах, работающих под управлением ОС реального времени. Рассмотренный подход является процедурным, а соответствующий стиль программирования был назван «программирование с явным выделением состояний»; существует и объектно-ориентированное программирование с явным выделением состояний.
Еще одна область применения автоматного программирования — классические алгоритмы, и в частности, построение визуализаторов алгоритмов.
У автоматных методов большое будущее, и хотя это научное направление все еще находится в стадии становления, switch-технология имеет все шансы занять достойное место в программировании.
Подробнее на эту тему можно прочитать в книге Шалыто А.А. Switch-технология. Алгоритмизация и программирование задач логического управления. — СПб.: Наука, 1998. Или на сайтеis.ifmo.ru.
ИГРЫ: Ролевые игры: Жизнь офлайн
Автор: Эмма Михейкина [email protected]
Компьютерная игра — это всегда имитация. Развитие технологий все сильнее приближает ее к реальности, но никакие пиксельные шейдеры и многомерный звук не способны свести это различие на нет. И если, например, любитель авиасимуляторов захочет узнать, каково на самом деле управлять настоящим боевым самолетом в боевых условиях — сделать это будет непросто. Особняком здесь стоят RPG, в которые можно легко поиграть «по-настоящему», безо всякого компьютера. Предлагаемая вашему вниманию статья посвящена именно таким живым ролевым играм. — И.Щ.
Объяснить человеку, который никогда не играл в ролевые игры, что это такое, — весьма непросто. Рассказать об этом явлении в одной статье и нигде не погрешить против истины — практически невозможно. Всегда найдутся люди, которые скажут, что «все было совсем не так, я знаю, я там был!»
Следует понимать, что все сказанное в этой статье — только одна из версий, которых существует великое множество. Ролевые игры как явление с трудом поддаются определению, описанию и классификации. Это одна из тех вещей, которые необходимо хоть раз попробовать самому. Потому что всякий опыт в данном случае уникален и не похож на предыдущие, поскольку каждый участник процесса приходит в игры за чем-то своим.
Ролевые игры — это вид интеллектуального развлечения для группы лиц, состоящего в моделировании различных жизненных ситуаций, с участием ведущего (мастера), исполняющего функции сценариста и арбитра.
Казалось бы, ролевые игры порождают гигантский информационный поток: сотни сайтов в Интернете, десятки периодических изданий, огромное количество художественных текстов, несколько защищенных диссертаций. Тем не менее все это информационное поле до сих пор хаотично: отсутствуют общепринятые термины, понятные любому, равно как и установленная раз и навсегда структура. Поэтому каждому следующему автору приходится выкручиваться, используя ролевой сленг и проговаривая определения каких-то ключевых понятий, дабы говорить с читателем на одном языке.
Мы поступим точно так же. Для дальнейшего понимания текста нам придется разграничить два понятия: ролевые игры и живые ролевые игры.
Ролевые игры — живые и не оченьРолевая игра — более общий термин, обозначающий широкую категорию игр развлекательного и профессионального характера, связанных с выбором той или иной роли (модели социального поведения). В ролевые игры играют все, но не все об этом знают. Каждый из нас играет множество ролей — ребенка, родителя, подчиненного, начальника, слушателя, ученика, учителя, супруга, — и у каждого свой собственный список. Мы ведем себя по-разному в зависимости от обстоятельств, даже если нам кажется, что мы всегда остаемся собой. Умение вести себя — это умение правильно выбирать роль в каждой конкретной ситуации. Под ролевыми играми понимают огромное количество вещей, начиная от психологических тренингов и заканчивая театрализованными представлениями.
Нас интересуют так называемые живые ролевые игры. Это гораздо более узкое понятие, которое означает сознательную попытку пожить какое-то время в шкуре другого человека (или существа), производя от его лица какие-то действия, обусловленные обстоятельствами или необходимостью достичь поставленной цели. При этом все действия выполняются «как на самом деле», а не просто проговариваются или моделируются иным способом. Наиболее показательны в этом плане полигонные игры (те, которые проводятся на природе, на достаточно большом пространстве). Сотни и тысячи людей, среди которых преобладают студенты, но встречаются и дети, и солидные взрослые люди, с наступлением тепла едут в лес, где переодеваются в сшитые дома костюмы и начинают играть — странные актеры, которым не нужны зрители. Да, перед этим они еще несколько дней превращают палатки, сухостой, обрезки ткани и невесть что еще в декорации для своего причудливого представления. Человек, случайно оказавшийся среди играющих, чувствует себя Алисой, провалившейся в нору: любопытно, необычно и — совершенно непонятно. Как интересная книга, которую открыли на середине.
Что такое живая ролевая игра, почему она так привлекательна для людей? Не существует однозначного ответа на этот вопрос. Психологи и социологи радостно ухватились за это явление. Дж. Л. Морено, например, занимался «исследованием внутреннего мира и социальных отношений человека средствами ролевой игры»[Дж. Л. Морено, «Театр спонтанности». — Красноярск: Изд. «Фонд ментального здоровья», 1993. Дж. Л. Морено, «Социометрия». — М.: Изд. «Академический проект», 2001]. Но тут, как водится, сколько людей, столько и мнений. Так что придется разбираться самим.
Мы будем говорить об играх «на погружение». Во-первых, это живые игры, то есть те, в которых участник сам совершает все действия, а не управляет виртуальным персонажем, будь то компьютерная или словесная игра. Во-вторых, в них существует стартовая ситуация, но отсутствует сценарий, развитие сюжета не предопределено и полностью зависит от участников игры. И последнее, но самое главное: человек заранее продумывает своего персонажа (биография, характер, привычки, костюм) и на все игровые события реагирует так, как, по мнению игрока, поступил бы его персонаж — даже если личный опыт подсказывает сделать все с точностью до наоборот.