Иструментарий создания игровой логики
Проанализированы возможности имеющихся средств декларативного программирования применительно к созданию деловой логики казуальных игр. Разработано средство для создания деловой логики игр на платформе flash с учетом выполненного анализа....
Saved in:
| Published in: | Проблеми програмування |
|---|---|
| Date: | 2012 |
| Main Author: | |
| Language: | Russian |
| Published: |
Інститут програмних систем НАН України
2012
|
| Subjects: | |
| Online Access: | https://nasplib.isofts.kiev.ua/handle/123456789/86640 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Cite this: | Иструментарий создания игровой логики / В.В. Кожаев // Проблеми програмування. — 2012. — № 4. — С. 64-74. — Бібліогр.: 16 назв. — рос. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1860003213265076224 |
|---|---|
| author | Кожаев, В.В. |
| author_facet | Кожаев, В.В. |
| citation_txt | Иструментарий создания игровой логики / В.В. Кожаев // Проблеми програмування. — 2012. — № 4. — С. 64-74. — Бібліогр.: 16 назв. — рос. |
| collection | DSpace DC |
| container_title | Проблеми програмування |
| description | Проанализированы возможности имеющихся средств декларативного программирования применительно к созданию деловой логики казуальных игр. Разработано средство для создания деловой логики игр на платформе flash с учетом выполненного анализа.
|
| first_indexed | 2025-12-07T16:37:03Z |
| 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
|
| id | nasplib_isofts_kiev_ua-123456789-86640 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Russian |
| last_indexed | 2025-12-07T16:37:03Z |
| publishDate | 2012 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Кожаев, В.В. 2015-09-24T13:26:05Z 2015-09-24T13:26:05Z 2012 Иструментарий создания игровой логики / В.В. Кожаев // Проблеми програмування. — 2012. — № 4. — С. 64-74. — Бібліогр.: 16 назв. — рос. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/86640 681.3 Проанализированы возможности имеющихся средств декларативного программирования применительно к созданию деловой логики казуальных игр. Разработано средство для создания деловой логики игр на платформе flash с учетом выполненного анализа. ru Інститут програмних систем НАН України Проблеми програмування Інструментальні засоби і середовища програмування Иструментарий создания игровой логики published earlier |
| spellingShingle | Иструментарий создания игровой логики Кожаев, В.В. Інструментальні засоби і середовища програмування |
| title | Иструментарий создания игровой логики |
| title_full | Иструментарий создания игровой логики |
| title_fullStr | Иструментарий создания игровой логики |
| title_full_unstemmed | Иструментарий создания игровой логики |
| title_short | Иструментарий создания игровой логики |
| title_sort | иструментарий создания игровой логики |
| topic | Інструментальні засоби і середовища програмування |
| topic_facet | Інструментальні засоби і середовища програмування |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/86640 |
| work_keys_str_mv | AT kožaevvv istrumentariisozdaniâigrovoilogiki |