Instrumentariy creating business logic
The possibilities available means of declarative programming with respect to the creation of business logic of casual games. Developed a tool for creating business logic games on the platform of the light flash of the analysis.
Gespeichert in:
| Datum: | 2015 |
|---|---|
| 1. Verfasser: | |
| Format: | Artikel |
| Sprache: | Russian |
| Veröffentlicht: |
PROBLEMS IN PROGRAMMING
2015
|
| Schlagworte: | |
| Online Zugang: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/108 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-108 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/c3/baa5b2d9cdaf88ebb1e1a485b830c2c3.pdf |
| spelling |
pp_isofts_kiev_ua-article-1082018-07-23T09:01:44Z Instrumentariy creating business logic Иструментарий создания игровой логики Iнструментарій створення ділової логіки Kozhaev, V. V. Автоматное программирование Автоматне програмування The possibilities available means of declarative programming with respect to the creation of business logic of casual games. Developed a tool for creating business logic games on the platform of the light flash of the analysis. Проанализированы возможности имеющихся средств декларативного программирования применительно к созданию деловой логики казуальных игр. Разработано средство для создания деловой логики игр на платформе flash с учетом выполненного анализа. Проаналізовано можливості наявних засобів декларативного програмування стосовно до створення ділової логіки казуальних ігор. Розроблено засіб для створення ділової логіки ігор на платформі flash з урахуванням виконаного аналізу. PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2015-09-22 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/108 10.15407/10.1234/ PROBLEMS IN PROGRAMMING; No 4 (2012) ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 4 (2012) ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 4 (2012) 1727-4907 ru https://pp.isofts.kiev.ua/index.php/ojs1/article/view/108/108 Copyright (c) 2015 ПРОБЛЕМИ ПРОГРАМУВАННЯ |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2018-07-23T09:01:44Z |
| collection |
OJS |
| language |
Russian |
| topic |
|
| spellingShingle |
Kozhaev, V. V. Instrumentariy creating business logic |
| topic_facet |
Автоматное программирование Автоматне програмування |
| format |
Article |
| author |
Kozhaev, V. V. |
| author_facet |
Kozhaev, V. V. |
| author_sort |
Kozhaev, V. V. |
| title |
Instrumentariy creating business logic |
| title_short |
Instrumentariy creating business logic |
| title_full |
Instrumentariy creating business logic |
| title_fullStr |
Instrumentariy creating business logic |
| title_full_unstemmed |
Instrumentariy creating business logic |
| title_sort |
instrumentariy creating business logic |
| title_alt |
Иструментарий создания игровой логики Iнструментарій створення ділової логіки |
| description |
The possibilities available means of declarative programming with respect to the creation of business logic of casual games. Developed a tool for creating business logic games on the platform of the light flash of the analysis. |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2015 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/108 |
| work_keys_str_mv |
AT kozhaevvv instrumentariycreatingbusinesslogic AT kozhaevvv istrumentarijsozdaniâigrovojlogiki AT kozhaevvv instrumentaríjstvorennâdílovoílogíki |
| first_indexed |
2025-07-17T10:03:58Z |
| last_indexed |
2025-07-17T10:03:58Z |
| _version_ |
1850413071413018624 |
| fulltext |
Інструментальні засоби та середовища програмування
© В.В. Кожаев, 2012
64 ISSN 1727-4907. Проблеми програмування. 2012. № 4
УДК 681.3
В.В. Кожаев
ИСТРУМЕНТАРИЙ СОЗДАНИЯ ИГРОВОЙ ЛОГИКИ
Проанализированы возможности имеющихся средств декларативного программирования применитель-
но к созданию деловой логики казуальных игр. Разработано средство для создания деловой логики игр
на платформе flash с учетом выполненного анализа.
Введение
В последние несколько лет рынок
казуальных [1] игр испытывает бурное
развитие – конкуренция между производи-
телями игр растет, игры усложняются. В
частности, всё более сложными становятся
правила поведения игровых сущностей.
Задача программирования игры с актора-
ми, поведение которых подчинено опреде-
ленному набору правил и быстрое их из-
менение, является не тривиальной, осо-
бенно, если это нужно сделать за ограни-
ченное время. Это обуславливает необхо-
димость создания средств, для упрощения
программирования таких правил. К сожа-
лению, средства применяемые для задания
логики в промышленных программах, тре-
буют серьёзной доработки из-за специфи-
ки программирования игр. В данной статье
проанализированы существующие подхо-
ды к созданию деловой логики и их недос-
татки для разработки игр, а также предло-
жен подход позволяющий избавиться от
ряда недостатков присущих существую-
щим средствам.
Под бизнес логикой понимается
совокупность правил, принципов, зависи-
мостей поведения объектов предметной
области (области человеческой деятельно-
сти, которую система поддерживает). Ина-
че можно сказать, что бизнес-логика – это
реализация правил и ограничений автома-
тизируемых операций. Является синони-
мом термина "логика предметной области"
(англ. domain logic).
В практике программирования час-
то используется явное разделение про-
граммы на логическую и семантическую
части. Под логической частью програм-
мы будем понимать декларативный набор
правил, характеризующий поведение акто-
ра. Под семантической частью – реализа-
цию конкретных действий производимых
в процессе работы программы.
Языки, описывающие логическую
часть программы, называются языками
описания бизнес логики, языками описа-
ния предметной области (англ. Domain
Specific Language или DSL - языки)
Под игровой логикой будем пони-
мать деловую логику характерную для той
или иной игры: совокупность правил игры
и правил, задающих поведение акторов.
Следует отметить, что в понятие игровой
логики не содержит указаний на графиче-
скую составляющую конкретной игры, или
принятую в определенной игре модель
физических, или других процессов.
Движок (от англ. engine – мотор,
двигатель) – выделенная часть программ-
ного кода для реализации конкретной при-
кладной задачи – программа, часть про-
граммы, комплекс программ или библио-
тека, в зависимости от задачи и реализа-
ции. Как правило, прикладная часть выде-
ляется из программы для использования в
нескольких проектах и/или раздельной
разработки/тестирования. Применительно
к разработке игр существуют графические
(для создания графики), физические (мо-
делирование физических процессов), изо-
метрические (создание игр в изометриче-
ской проекции). Существуют так же движ-
ки более высокого уровня, представляю-
щие собой композицию нескольких низко-
уровневых движков, часто от разных про-
изводителей. По сути, движки этого типа
являются архитектурными каркасами, ко-
торые могут быть превращены в игру
только заданием игровой логики.
Под структурами, используемы-
ми для задания деловой логики, будем
понимать продукционные системы, конеч-
Інструментальні засоби та середовища програмування
65
ные автоматы, деревья поиска и другие
структуры данных, применяемые в про-
граммировании логики.
Как правило, для управления каж-
дой игровой сущностью не создается от-
дельного потока. Вместо этого, сущности
объединяются в списки и обрабатываются
последовательно. Цикл в течении итера-
ции которого обрабатывается такой список
называется игровым циклом, итерация это-
го цикла – тиком. Название "тик" обуслов-
лено тем, что между итерациями цикла
проходит фиксированный интервал време-
ни. Существуют игры как с несколькими
циклами и созданием отдельного потока
для каждого, так и одним игровым циклом.
1. Обзор существующих подходов
к программированию деловой
логики применительно к
разработке игр
В промышленном программирова-
нии используется множество подходов
позволяющих выделить декларативную и
семантическую части программы. Однако
большинство из них требуют существен-
ной адаптации для применения в разработ-
ке игр ввиду того, что производство игр
существенно отличается от разработки
коммерческого программного обеспечения
(подробнее см. [16]). Далее представлен
обзор некоторых из существующих подхо-
дов и указание их основных недостатков
применительно к разработке игр.
1.1. Использование систем, осно-
ванных на правилах. Для задания деловой
логики в промышленном программирова-
нии широко используются разнообразные
системы, основанные на правилах. В этих
системах правила задаются в виде структу-
ры "Если – то". Для описания правил обыч-
но используются DSL языки, которые мо-
гут быть как интерпретируемыми, так и
компилируемыми. Во втором случае пра-
вила компилируются непосредственно в
бинарный код или в байт-код, исполняемый
на данной платформе. В обоих случаях су-
ществует возможность комбинировать дек-
ларативные выражения на DSL – языках с
вызовами кода на входном для данной
платформы языке. В качестве примера сис-
тем созданных на платформе Java можно
привести Jess [2], Drools [3], Algernon [4],
JEOPS [5] и другие. К достоинствам дан-
ных систем относится большое количество
документации и мощные средства, предос-
тавляемые платформой.
Однако применительно к разработ-
ке игр данный подход имеет ряд сущест-
венных недостатков, одним из которых
является отсутствие единого стандарта для
DSL-языков. На сегодняшний день не су-
ществует системы портированной на все
популярные платформы. Поэтому, при
переносе игры, например, с платформы
Java на flash придется полностью перепи-
сывать логическую часть программы, либо
переносить на данную платформу выбран-
ную систему. Кроме того системы осно-
ванные на правилах, не позволяют сохра-
нять состояние актора, что неудобно, по-
скольку при таком подходе приходится
каждый раз анализировать большое коли-
чество правил, часть из которых являются
значимыми только в небольшой промежу-
ток времени. Использование систем с со-
хранением состояний позволяет избежать
анализа всего множества правил при каж-
дом обращении.
В настоящее время данные системы
не используются широко в создании игр, но
могут быть использованы после адаптации.
1.2. Использование универсаль-
ных интерпретируемых языков высоко-
го уровня. Для декларативного задания
игровой логики часто используются ин-
терпретируемые такие языки с динамиче-
ской типизацией, как JavaScript, Python,
Lua, причем особенно популярен послед-
ний. К достоинствам этих языков относят-
ся простота их использования и изменения
ввиду безтиповости. Одним из недостатков
данных языков является невысокая ско-
рость работы, другим – то что, возможно-
сти встраиваемых версий таких языков
весьма ограничены. Сложную систему,
используя их создать тяжело.
Данный подход используется в соз-
дании не казуальных игр, для задания ин-
терфейса пользователя, или логических
связок очень высокого уровня.
Інструментальні засоби та середовища програмування
66
1.3. Использование дополнитель-
ных языков программирования. Более
общим, чем предыдущий случай, является
подход, в котором деловую логику разра-
батывают на универсальном языке, отлич-
ном от принятого на данной платформе в
качестве основного, без использования
логического движка. Как правило, это ди-
намические или функциональные языки.
Для платформы "Java" такими языками
являются Clojure [6], Scala [7], Groovy [8] и
некоторые другие. Для платформы .net –
F# [9], Nemerle [10] и так далее. Про-
граммный код на этих языках компилиру-
ется непосредственно в байт–код испол-
няемый виртуальной машиной. Ввиду при-
сутствия в данных языках функционально-
го подхода и их высокоуровневости игро-
вую логику на них создавать много проще,
чем на языках, которые являются основ-
ными для той или иной платформы. Кроме
того, данный подход позволяет переносить
игровую логику с платформы на платфор-
му в случае, если язык создания логики
реализован на обеих платформах.
Недостаток данного подхода к раз-
работке игровой логики состоит во-
первых, в отсутствии реализаций данных
языков программирования для популярных
игровых платформ, в частности для плат-
формы flash. Другой проблемой является
малая распространенность указанных язы-
ков среди разработчиков игр ввиду слож-
ности указанных языков.
1.4. Использование мультиплат-
формных языков. При разработке игр (и
других приложений, предназначенных для
кроссплатформенного использования) яв-
ляется подход, при котором код пишется
на кросс-платформенном языке, либо при-
ложение, написанное для одной платфор-
мы, конвертируется для запуска на другой.
В качестве примера можно привести
язык HaXe [11] и технологию Adobe
Alchemy [12].
К недостаткам этого подхода отно-
сится то, что в различных языках про-
граммирования различными являются и
библиотеки программ. Библиотеки для
решения одной и той же задачи на разных
языках могут иметь совершенно разную
архитектуру, или вовсе отсутствовать.
Кроме того, указанные средства совер-
шенно не упрощают собственно разработ-
ку игровой логики. Язык "HaXe" является
универсальным, объектно-ориентирован-
ным языком и разработка игровой логики с
его использованием ничем не проще, чем с
использованием Java, C#, C++ или других
универсальных языков программирования
высокого уровня. Adobe Alchemy пред-
ставляет собой технологию преобразова-
ния кода программ написанных на С++ в
промежуточный байт-код AVM2 (вирту-
альная машина для выполнения flash –
приложений).
1.5. Создание деловой логики с
использованием автоматного програм-
мирования. Задачи программирования
деловой логики как задачи реализации си-
стем с сложным поведением можно ус-
пешно решать с помощью автоматного
программирования (Этот термин впервые
введен в работе [13]). При таком подходе
управляющая (логическая) часть програм-
мы реализуется в виде конечного автомата.
В процессе перехода между состояниями
производятся действия (так называемые
управляющие), влияющие на акторов или
систему в целом (которую можно рассмат-
ривать как частный случай актора) и таким
образом, осуществляется управление.
Можно выделить следующие виды
управляющих действий:
действие входа выполняется при
входе в состояние;
действие выхода, выполняется при
выходе из состояния;
действие ввода, которое выполняет-
ся в зависимости от данного состояния и
входного условия;
действие перехода, выполняемое
при выполнении определенного перехода.
Действие неизменного состояния,
выполняется в системах с дискретным
временем, когда ни одно из условий пере-
хода не выполняется и состояние остается
неизменным.
К достоинствам автоматного про-
граммирования относится следующее:
автомат, полученный при создании
деловой логики, является моделью про-
граммы. Таким образом, в отличие от тра-
диционных способов программирования
Інструментальні засоби та середовища програмування
67
собственно созданию программы предше-
ствует её проектирование;
графическая диаграмма переходов
конечного автомата является наглядным и
интуитивным средством проектирования.
(В ходе рассуждений часто используется
людьми без специального образования в
виде стрелочной схемы);
позволяет легко тестировать логи-
ку: измерить покрытие тестами, сгенери-
ровать виды тестов, создать прототип сис-
темы и так далее;
представление логической части
программы в виде автомата удобно для
строгого доказательства её коррекции;
DSL-языки, используемые при соз-
дании автоматов, удобно использовать для
частичной генерации семантического кода.
Основным недостатком автоматно-
го программирования является увеличение
времени разработки программы. Другими
словами, к разработке добавляется время
необходимое на оформление кода в авто-
матном стиле.
1.5.1. Способы описания структу-
ры конечного автомата. Существует
большое разнообразие средств позволяю-
щих реализовать автоматный подход (пе-
речисление всех их выходит за рамки дан-
ной статьи). Тем не менее, их можно раз-
делить по подходу к заданию структуры
конечного автомата на использующие для
описания структуры языки полные и не
полные по Тьюрингу соответственно.
В первой группе средств часто ис-
пользуются расширения функциональных
языков, а во второй – метаязыки на основе
XML. Однако это – не правило: существу-
ют реализации средств использующих для
описания конечного автомата универсаль-
ные, сильно типизированные языки, такие
как Java или С# равно как и метаязыки
самой причудливой формы.
В качестве полного по Тьюрингу
языка можно привести Язык ASML
(Abstract State Machine Language) [14],
который разработан компанией Microsoft в
качестве языка реализации управляемых
моделей. Является одной из реализаций
формализма абстрактных машин состоя-
ний, описанных в [7] в виде языка про-
граммирования. Это объектно-
ориентированный, динамический слабо
типизированный язык, по идеологии име-
ющий некоторое сходство с Python и
Visual Basic. Является .net языком и в этом
качестве имеет доступ к любому .net со-
вместимому коду и стандартным сервисам
.net framework. (существует несколько реа-
лизаций данного формализма в виде языка
программирования, эта выбрана ввиду
большей распространенности).
Основное предназначение языка
ASML – разработка выполняемых специ-
фикаций, другими словами разработка мо-
делей программ с целью изучения их по-
ведения и структуры.
Центральными понятиями данного
языка являются abstract state (абстрактное
состояние) и step.
Под абстрактным состоянием по-
нимают состояние модели системы, кото-
рое абстрагировано от несущественных
для моделируемых процессов деталей. В
языке программирования не существует
соответствующей структуры, это скорее
некая концепция всего языка: конкретные
состояния системы задаются в виде мно-
жества пар (имя переменной, значение).
Step – конструкция языка (в отли-
чие от первого понятия), предназначенная
для задания действий, которые произво-
дятся при переходах между состояниями.
В терминологии предлагаемой в ра-
боте [13], данный язык предназначен для
создания конечных автоматов с активными
переходами.
Типичным средством использую-
щим метаязык является UniMod [15].
Представляет так называемое Case-
средство реализованное в виде plug-in а
IDE Eclipse, который включает графиче-
ский редактор графов состояний, парсер
XML – языка описывающего деловую ло-
гику и генератор кода по созданной диа-
грамме состояний. В отличие от предыду-
щего, средство предназначено для реали-
зации автоматов с пассивными пере-
ходами. Прогрессивным является то, что
возможна кодогенерация на различных
языках программирования (доступны Java
и Simbean C). В настоящее время разра-
ботка и поддержка этого средства прекра-
щена, что естественно является серьезным
Інструментальні засоби та середовища програмування
68
аргументом против использования его в
разработке.
Достоинством языков полных по
Тьюрингу является то, что они являются
исполняемыми, то есть позволяют протес-
тировать программную модель без реали-
зации семантической части программы.
Однако, реализация полного по Тьюрингу
языка на конкретной платформе является
на порядок более сложной задачей, чем
создание парсера метаязыка. Поэтому, ес-
ли предполагается перенос логики на не-
сколько платформ целесообразно исполь-
зование именно метаязыков. С другой сто-
роны, использование метаязыков более
удобно при создании графических редак-
торов графа перехода состояний.
2. Описание реализованного сред-
ства автоматного программиро-
вания
Хотя автоматное программирование
широко используется при создании про-
мышленных программ, не существует
средства, которое повсеместно использо-
валось бы в производстве игр. В качестве
причины можно указать некоторую кон-
сервативность разработчиков игр, а тот
факт, что игры менее требовательны к от-
казоустойчивости по сравнению с про-
мышленными программами. Действитель-
но, в случае отказа программы управления
атомной электростанцией может случиться
техногенная катастрофа, при сбое про-
граммного обеспечения банка возникнут
ошибки в финансовых операциях – люди
не получат деньги. При ошибке же работы
игры катастрофы не произойдет – пользо-
ватель просто перезапустит программу.
Поэтому, в практике разработки игр доби-
ваются исправления лишь часто возни-
кающих сбоев.
Однако необходимость в создании
версий одной и той же игры для разных
платформ и все усложняющееся поведение
игровых сущностей обуславливают необ-
ходимость создания такого средства. Что-
бы восполнить этот пробел, автором было
разработано средство под названием
"casual intellect". Это средство создано на
платформе "flash" (виртуальная машина -
AVM2) с использованием языка програм-
мирования ActionScript 3.0.
При разработке поставлены сле-
дующие задачи:
средство предназначено для разра-
ботки игр с коротким сроком жизни. Это
означает, что время в течении которого
пользователи активно играют составляет
от одного до нескольких месяцев. Особые
требования в создании таких игр предъяв-
ляются к скорости разработки. Поэтому
средство должно быть интуитивно понят-
ным;
должна быть возможность создания
редактора графических диаграмм, визуа-
лизирующих игровую логику;
должно давать возможность задать
все типы управляющих реакций;
соответствовать принятой методо-
логии производства игр;
позволять генерацию программ-
много кода для разных платформ.
В результате было решено создать
архитектурный каркас для реализации ко-
нечных автоматов с активными перехода-
ми с метаязыком на базе XML. В термино-
логии [13], средство реализует процедур-
ное программирование с явным выделени-
ем состояний. Например, таких как робот.
Рис. 1. Диаграмма классов робота игр
2.1. Описание демонстрационной
программы. Положим, необходимо реа-
лизовать следующую игру. На игровом
поле стоит несколько башен стреляющих
по противнику. Ремонт башен после раз-
рушения, зарядку пушек и улучшение так-
тических характеристик башен производят
роботы, специализированные для этих
операций: роботы ремонтники, заряжаю-
щие и инженеры соответственно.
Силы противника состоят из назем-
ных и воздушных боевых единиц. Воз-
Інструментальні засоби та середовища програмування
69
душные подразделяются на бомбардиров-
щики и вертолеты, наземные – на танки и
картечницы. За каждый уничтоженный
робот противника игроку начисляются
очки, за которые можно построить новых
роботов. Цель игры – найти оптимальную
стратегию постройки роботов.
2.1.1. Поведение робота игрока.
Типы поведения роботов игрока можно
представить в виде диаграммы наследова-
ния (см. рис. 1). Как видно из диа-
граммы, тип "робот" является базовым
поведенческим типом для боевых роботов
и механиков.
Поведенческий тип "робот – меха-
ник" базовый для типов ремонтник, за-
рядчик и инженер.
Поведение роботов задается конеч-
ным автоматом с помощью управляющих
воздействий. Рассмотрим диаграмму со-
стояний графа управляющего роботом
(рис. 2). Изначально робот находится в
состоянии покоя, если возникает необхо
димость в обслуживании башни движется
Рис. 2. Диаграмма состояний робота – ме-
ханика
к ней, обслуживает и переходит в состоя-
ние покоя до тех пор, пока в нем не поя-
вится необходимость. Поскольку по робо-
ту ведется стрельба, рано или поздно на-
ступает момент, когда его жизненные ре-
сурсы исчерпываются и он переходит в
состояние агонии из которого следует пе-
реход в конечное состояние – смерть.
Спецификация языка UML не по-
зволяет раскрыть все особенности поведе-
ния роботов. Невозможно указать, что
управляющие воздействия при переходах
из состояния в состояние в общем случае
зависят не от выходного состояния I или
входного J, а от вектора (I,J) Кроме того,
отсутствует возможность наследования
автоматов и переопределения управляю-
щих воздействий без изменения графа пе-
реходов состояний. Разработанный DSL
язык имеет указанные возможности.
2.2. Описание реализованного
DSL языка. Поскольку разработанный
DSL язык является XML – языком его спе-
цификация задана в виде DTD – схемы
(см. Листинг 2.1.).
Проверка условий перехода, и пере-
ход в новое состояние (если соответст-
вующее условие выполняется) произво-
дится единожды за тик. При переходах
между состоянием над актором выполня-
ются соответствующие методы, реализо-
ванные на языке программирования яв-
ляющимся входным для данной платфор-
мы (ActionScript 3.0 в данной реализации).
Каждое состояние имеет методы,
<!element object_logic (consts?, states?)>
<element variables (varialble+)>
<!variable @name>
<!element states state+>
<!element state (rooles?,methods?,extends?)>
<!element rooles roole+>
<!element roole (condition, roole_methods?)>
<!condition #equation>
<!roole_methods method+>
<!extends #statename)> (methods_before?,methods_after?,methods_in_process?)>
<!methods_before method+>
<!methods_after method+>
<!methods_in_process method+>
<!method #methodname>
<!roolemethod method>
Листинг 2.1. XSD схема языка программирования
Інструментальні засоби та середовища програмування
70
выполняемые после входа в него актора,
перед выходом, и методами выполняемы-
ми если состояние актора не изменилось.
Эти методы задаются тегом methods кото-
рый может содержать вложенные теги
methods_before, «methods_after» и
«methods_in_process» для задания множе-
ства методов выполняемых перед входом в
состояние, перед выходом и если состоя-
ние не изменилось, соответственно.
Вышеописанные теги содержат в
себе один или несколько тегов «method»
для задания списков выполняемых мето-
дов.
Условия перехода из данного со-
стояния задаются с помощью тега «rools»,
который содержит в себе список правил
(«roole»). И тега «roole_methods», содер-
жащего методы выполняемые, если усло-
вие истинно. Правило состоит из условия
…
<states>
<state name="move_to_tower">
<!--секция задающая состояния в которые можно перейти из текущего-->
<usecases>
<!-- Cостояние зарядка -->
<usecase name="charging">
<roole> <!--Переход происходит, если выполняется условие-->
((not energyIsLow) and
(not needRepairTower))
or (goalIsGetted)
</roole>
<!--Перед переходом выполняются
управляющие воздействия-->
<methods>
<!--В частности endMoving-->
<method name="endMoving"/>
</methods>
</usecase>
<!--Состояние "агония"-->
<usecase name="agony">
<roole>
energyIsLow
</roole>
<methods>
<method name="showAnger"/>
</methods>
</usecase>
</usecases>
<!--Секция методов выполняющихся всегда-->
<state_methods>
<!--Перед входом в состояние-->
<methods_before>
<method name="beforeMoving"/>
</methods_before>
<!--Перед выходом-->
<methods_after>
<method name="afterMoving"/>
</methods_after>
<!--Каждый игровой тик, пока актор находится в состоянии-->
<methods_in_process>
<method name="move"/>
</methods_in_process>
</state_methods>
</state>
…
Листинг 2.2. Декларативное задание состояния «Движение к башне»
Інструментальні засоби та середовища програмування
71
перехода «condition» представляющих со-
бой логическое выражение с атомами –
функциями языка программирования, воз-
вращающими логическое значение. Вы-
числение этого выражения осуществляется
с помощью перевода в обратную польскую
запись.
При обработке состояния произво-
дится проход по списку, содержащемся в
«rools». Для каждого элемента «roole» оп-
ределяется истинно — ли условие перехо-
да содержащееся в condition. Если это так,
производится последовательное выполне-
ние методов содержащихся в элементе
«roole_methods». Затем выполняются ме-
тоды, содержащиеся в теге
«methods_after», который в свою очередь
содержится в теге «methods» текущего со-
стояния. После этого выполняются мето-
ды, содержащиеся в теге «methods-_before»
нового состояния.
Если ни одно из условий перехода
из данного состояния не является истин-
ным, выполняются методы, содержащиеся
в теге «methods_in_process» текущего со-
стояния.
В качестве примера рассмотрим ре-
ализацию состояния «Движение к башне»
показанном в фрагменте программного
кода 2.2.
Из данного состояния можно перей-
ти в состояние «обслуживание башни»,
либо в состояние «агония» если жизнен-
ные силы истощились. Переход происхо-
дит, если истинны логические выражения
заданные тегом rules. Перед переходом
выполняются управляющие воздействия с
именами «endMoving» в случае перехода в
состояние «обслуживание» или
"showAnger" если происходит переход в
состояние «Агония».
2.3. Спецификация методов – об-
работчиков. Одна и та же декларативная
часть программы может быть интерпрети-
рована по-разному, в зависимости от спо-
соба её обработки императивной частью.
В качестве примера рассмотрим реа-
лизацию поведения роботов механиков.
Данные роботы управляются одним авто-
матом, разнятся лишь управляющие воз-
действия. Так для робота – ремонтника в
состоянии «обслуживание башни» управ-
ляющим воздействием будет «ремонт». Для
робота – заряжающего «зарядка орудия», а
для робота – инженера – «улучшение».
В разработанном программном
средстве управляющие воздействия ассо-
циируются в императивном стиле, с по-
мощью входного языка программирования
ActionScript 3.0 (см. Листинг 2.3).
Листинг 2.3. Императивное задание методов
//Инициализируем обработчик состояний
var _statesProcessor:StatesProcessor;
_statesProcessor = StatesProcessor.statesProcessor;
//Создаем контейнер операций
var opContainer:OperationsContainer = new OperationsContainer();
//Ассоциируем итендификаторы управляющих воздействий с конкретными методами
opContainer.addFunction("finishMoving", _robotController.endMoveCondition);
opContainer.addFunction("move", _ robotController .move)
opContainer.addFunction("beforeMoving", _ robotController .beforeMoving)
opContainer.addFunction("afterMoving", _ robotController .afterMoving);
opContainer.addFunction("endWating", _ robotController .endWating);
opContainer.addFunction("movingIsFinished", _ robotController .endMoveCondition);
opContainer.addFunction("watingIsFinished", _ robotController .watingIsFinished);
opContainer.addFunction("beforeWating", _ robotController .beforeWating);
opContainer.addFunction("afterWating", _ robotController .afterWating);
opContainer.addFunction("wait", _ robotController.wait);
//передаем обработчику состояний контейнер операций
_statesProcessor.operationsContainer = opContainer;
Інструментальні засоби та середовища програмування
72
Как видно из представленного кода,
за хранение ассоциированных методов
отвечает класс OperationsContainer, с по-
мощью метода addFunction методы – обра-
ботчики ассоциируются с идентификато-
рами. Таким образом, ассоциировав один и
тот – же идентификатор метода shoot c
разными обработчиками можно изменить
характеристики выстрела оставив при этом
неизменным общий характер поведения
робота.
<!‐‐Унаследовано от состояния airplane‐‐>
<extends parent=”airplane”/><!‐‐Константы‐‐>
<variables>
<variable name=”speed”>5</variable>
<variable name=”armour”>3</variable>
</variables>
<!‐‐Измененное состояние‐‐>
<states>
<state name="moving">
<usecases>
<usecase name="bombarding ">
<!‐‐Конкретно изменено текущее правило‐‐>
<roole>hasGroundTargets </roole>
<methods>
<method name="endMoving "/>
</methods>
</usecase>
</usecases>
<!—Методы выполняемые ‐‐>
<state_methods>
<!—Перед входом в состояние ‐‐>
<methods_before>
<method name="beforeMoving"/>
</methods_before>
<!—Перед выходом из состояния ‐‐>
<methods_after>
<method name="afterMoving"/>
</methods_after>
<!—На каждый тик ‐‐>
<methods_in_process>
<method name="move"/>
</methods_in_process>
</state_methods>
</state>
<!‐‐Запрещенное состояние‐‐>
<state name="shooting">
<forbidden/>
</state>
<state name="bombarding">
</state >
</states
</direction>;
Листинг 2.5. Декларативная часть программы, управляющая бомбардировщиком
<direction>
<extends parent=”airplane”/>
….
</direction>
Листинг 2.4. Использование тега extends
Інструментальні засоби та середовища програмування
73
2.4. Наследование декларативных
частей программы. Для декларативных
частей программы, реализованных с по-
мощью DSL–языка, реализовано наследо-
вание. Как и наследование классов в тра-
диционных языках, оно позволяет расши-
рить, изменить или запретить свойства
предка.
Указать, что управляющий элемент
программы наследуется от другого, можно
с помощью тега “extends”, как показано в
листинге 2.4.
…
<variables>
<variable name=”speed”>5</variable>
<variable
name=”armour”>3</variable>
…
</variables>
…
Листинг 2.6. Пример создания переменных
В качестве примера использования
рассмотрим два таких робота как самолет
и наследующий его поведение бомбарди-
ровщик. У первого из состояния полета
производится переход в состояние стрель-
бы по наземным целям. У второго же – в
режим бомбардировки, при этом состояния
стрельбы по наземным целям не существу-
ет. Кроме того, у бомбардировщика ско-
рость передвижения будет отличаться, от
самолета.
Листинг 2.7. Интерфейс «состояние»
Таким образом, необходимо изме-
нить значение константы “speed”, доба-
вить состояние bombarding, изменить со-
стояния, из которых актор-предок может
перейти в состояние “shoot” и удалить со-
стояние “shoot” актора-наследника. Насле-
дование декларативной части программы
показано в листинге 2.6 (детали для про-
стоты опущены). Изменено состояние
moving базового класса и добавлено со-
стояние bombarding.
Состояние shooting удалено из ав-
томата с помощью тега forbidden.
2.5. Константы. Поведение акторов
зависит не только от их реакции на опре-
деленные события, но и от таких началь-
ных условий, как, например, скорость
движения, количество выстрелов в секун-
ду, толщина брони и так далее.
В первом приближении можно счи-
тать, что начальные условия задаются с
помощью численных значений констант,
используемых в императивной части про-
граммы. Изменив их, можно специфици-
ровать поведение акторов, управляемых
одним и тем же конечным автоматом.
В DSL–языке константы задаются с
помощью тега variables. Название тега
подчеркивает тот факт, что константы
можно менять в течении игрового процес-
са. Константы подлежат переопределению
в ходе наследования, для этого нужно объ-
явить константу заново. При этом тип зна-
чения константы диаграммы предка дол-
жен быть совместим с типом константы
родителя.
2.6. Детали реализации каркаса.
Реализованный каркас состоит из трех час-
тей: парсера XML – языка задающего ма-
шину состояний, интерпретатора условий
перехода и машины состояний. В начале
работы программы парсер строит по XML
– текстам конкретные реализации машин
состояний управляющих акторами. При
этом, условия перехода преобразовывают-
ся в обратную польскую запись и вычис-
ляются уже в процессе работы программы
с помощью интерпретатора условий. Кар-
кас поддерживает архитектуру «модель –
вид – контроллер»: обрабатывающие ме-
тоды являются методами контроллера.
Эти методы должны принимать экземпляр
класса реализующего интерфейс
IStateObject. Другими словами все классы
акторов обрабатываемые с помощью реа-
лизованной машины состояний должны
реализовывать данный интерфейс.
package org.casualintellect.statemachineclases
{
public interface IStateObject
{
//Геттер и сеттер имени cостояния
function get state():String;
function set state(val:String):void;
//Итендификатор конкретного класса
//реализующего данный интерфейс
function get className():String;
}
}
Інструментальні засоби та середовища програмування
74
Как видно из листинга 2.7, объект
принимаемый методами контроллера дол-
жен иметь возможность изменить имя со-
стояния (функция сеттер), вернуть его
(функция геттер) и вернуть имя обрабаты-
ваемого класса.
Выводы и перспективы
дальнейшего развития
Реализованный каркас является од-
ним из первых применений автоматного
программирования к разработке казуаль-
ных игр, что обуславливает научную но-
визну (других применений автору не из-
вестно). Декларативную часть программы
можно легко перенести на другие плат-
формы, поскольку задается в виде XML.
В перспективе развития программы
стоит реализация графического редактора
декларативной части и генерации по ней
семантической части.
1. Статья в википедии об автоматном
программировании
ru.wikipedia.org/wiki/Автоматное_програм
мирование
2. Домашняя страница проекта Jess
http://www.jessrules.com/
3. Домашняя страница проекта Drools
http://www.jboss.org/drools/
4. Домашняя страница проекта Algernon
http://algernon-j.sourceforge.net/
5. Домашняя страница проекта Jeops
http://www.jeops.org/
6. Официальный сайт языка Clojure
http://clojure.org/
7. Официальный сайт языка Scala
http://www.scala-lang.org/
8. Официальный сайт языка Groovy
http://groovy.codehaus.org/
9. Официальный сайт языка F#
http://msdn.microsoft.com/ru-
ru/fsharp/default%28en-us%29.aspx
10. Официальный сайт языка Nemerlie
http://nemerle.org/Main_Page
11. Домашняя страница проекта Haxe
http://haxe.org/
12. Домашняя страница проекта Alchemy
http://labs.adobe.com/technologies/alchemy/
13. Автоматное программирование. Н. И.
Поликарпова, А. А. Шалыто M. 2008
14. Спецификация языка ASML
http://research.microsoft.com/en-
us/groups/foundations/AsmL/
15. Домашняя страница проекта UniMod
http://unimod.sourceforge.net/
16. Кожаев В.В. Разработка и тестирование
игр // Компьютерная математика. – 2011. –
№ 1. – С. 79 – 85.
Получено 08.08.2012
Об авторе:
Кожаев Владимир Викторович,
аспирант.
Место работы автора:
Институт кибернетики
имени В.М. Глушкова НАН Украины,
03680, Киев-187,
проспект Академика Глушкова, 40.
Тел. (044) 526 3603.
dep145@gmail.com
|