COMPUTER-AIDED SOFTWARE DEVELOPMENT BASED ON STATES
MACHINES FOR RPG
Maroš POLÁK
Slovak University of Technology in Bratislava, Faculty of Materials Science and
Technology in Trnava, Slovakia, e-mail: maros.polak.sk@gmail.com
Abstract. The article deals with the field of the finite-state machine in developed
computer game, genre role-playing game. The main objective of the thesis is to design and
implement structure of finite-state machine into role-playing game application, for design
and controlling objects of locations and their connections. Next objective is implement
code generator based on design structure of finite-state machine for generate source code
of states and transitions into project of game application.
Keywords: states machine, computer-aided, source code generation, role-playing
game
1. Introduction
This article follows up on my bachelor thesis: Fuzzy-based Decision Making in RPG [1]
about developing computer game. The developed computer game is role-playing game genre
(RPG). The player assumes the roles of main character, which he created to his liking. Next
player proceeds interactive story in fantasy environment. As the player character adventure
and gain experience, character advance in level, find up new items and equipments. Character
becomes stronger and he being capable to overcome various challenges and combat situations.
Interactive elements accompany the player throughout the whole game. Player chooses own
way of story. Story depends on the decisions of the player in key situations. The primary
element of games is adventures. Adventures consist of several different locations with
interactive features and they are connected with other locations. Locations can be divided into
the following categories:
 Place: Room or open space, which provides various options like move to other
locations, begin conversation, trade or combat, interact with characters inventory or
equipment contained in the location.
 Conversation: when you talking to other characters, location provides to the user
various options of questions, answers or actions which may result to additional
conservations opportunities, changing the overall impression of your character or the
reputation.
 Map: location show to the user a certain area with opportunities of transport between
different locations of the area.
 Trade: Here the player can buy, sell or steal equipment.
 Combat: player and his party are in combat, and may be using the combat actions and
abilities to move on the battlefield, fight with enemies and use options of interaction
with location.
In addition to these examples of basic options of locations, each location can contain its
own unique possibilities of actions, which that may have an impact on other locations.
When I was developing applications games, I found the problems associated with the
design and implementation of these game locations. Classical development methods were
inadequate for the complex designs varied objects of locations and their connections. After
discussions with my consultant Ing. Michal Sroka, I decided the best way to solve the
problem is design final-state machine, which will be responsible for controlling the objects of
locations and their connections, and design source code based on design structure of state
machine, for effective design and implementation of these objects.
2. Objectives
According to the previous section, objectives related to role-playing game application and
source code generator can be summarized as follows:
 Design structure of software application which implement finite-state machine.
 Implement role-playing game application with design structure of the state machine.
 Design and implement simple source code generator based on design structure finitestate machine in role-playing game application.
3. Design structure of state machine and generator
The purpose of this chapter is to analyze the design of the structure finite-state machine
and source code generator.
3.1. Finite-state machine
A finite state machine (FMS) is conceived an abstract machine that can exist in one of
finite different and predefined states. FMS also can define a set of conditions that determine
when the state should change. A machine is in only one state at a time. The state it is in at any
given time is called the current state. The current state determines how the FMS behaves. The
current state can be change to another state when initiated by a triggering event or condition.
This is called a transition. A particular FMS is defined by a list of its states, and the triggering
condition for each transition. [2]
Although FMS have been around for a long time, they are still quite common and
effective in today's games. The fact that they are relatively simply to understand, implement,
and debug contributes to their often use in game development. In this chapter, we discuss the
fundamentals of finite state machines and show you how to implement them. [2]
FMS is well suited for my problems with design objects of locations, because states of
machine can represent locations and transitions of machine can represent connections of
locations. Game after character creation initiates FMS with default start state, which is usually
prologue of the story. Current state display text data on graphical user interface (GUI), and
display too some opportunities to interact with the player's inventory or location.
State includes a list of transitions, connections on the other locations. Each of transitions
contains its own conditions, which must be true to realize of transition. Some transitions may
have a condition always automatically true. Conditions correspond to the actual game
parameters of external adventure and story events. All transitions that their condition is true
will be displayed on GUI in due form, usually in the form of buttons. The button can be
disabled to the user when the transition has already been executed once and transition not be
reused or if the final state of transition is disabled due to external adventure and story events.
The user selects a button determines which transition is to be executed. Entered transition is
performed by its unique action. The executed action may provide information of the situation
to GUI. Next FMS set the final state of transition as the current state and update GUI.
Fig. 1. Graphical user interface of game
Locations and their conections have certain features in common, by which they can be
categorized and is important to use inheritance and polymorphism in state machine. FMS
provide options for creating new state or transition inherit attributes and methods from
existing conditions and transitions. Some designed states and transitions may be abstract.
Fig. 2. Structure of the finite-state machine
3.2. Source code generator
Source code generator is adapted to the needs of the structure of FMS in role-playing
game aplication. Import all configuration files with the extension *state and *trans from the
user specified folder. Consequently, the following files will collect the necessary information
to create the source code according to predefined templates for objects of states and
transitions. Finally generated source files with the extension *cs exported to user specified
folder. GUI display the message about successful exporting or error. The user can enter the
desired directory for the import and export manually or can search to directory. Also, the user
has the option to delete all *cs source files from the destination folder before exporting the
new source files. Information about previous directory of importing and exporting folder is
saved in an external file, to be able to display when user restart the application.
Fig. 3. Graphical user interface of generator
4. Implementation
Role-playing game application and source code generator is implemented using objectoriented approach. The source code is developed using C#. This programming language I
have chosen for several reasons:
 is easy and modern,
 supports object-oriented programming,
 automatic memory management,
 I have yet most experience and knowledge of the C# language.
Applications were programmed in development environment Microsoft Visual Studio
2013, ainly because of the good connections for the .NET Framework and a wide range of
tools supporting development of application.
In Table 1 are display functional requirements specifications for the design and
implementation of role-playing game applications and source code generator.
Table 1: Functional requirements specifications
ID
Functional
requirement
Functionality of
game
Additional informations
Priority
Game have all relevant functions to be playable for the
ordinary user
must
2
Gema
Mechanisms
Algorithm mechanisms based on role-playing game rules
must
3
Graphic
interface
User receives information about the plot and the situation
in the game using text and illustrations via Windows
Forms tools (textbox, label, picturebox etc.)
must
4
Communication
Interface
User enters his choice via Windows Forms tools (button,
textbox, combobox etc.)
must
5
Multilingualism
Import displaying the text data from a text file provides
the possibility of implementing a another language in the
game
can
6
Import of
objects
Import of objects, for example: weapons, armor, enemies
etc., from files provides the possibility of extending and
modifying games
can
7
Implemented
structure of
FSM
Import of states
and transitions
objects
The structure of software applications which implement a
FSM is responsible for controlling the objects of
locations and their connections.
Import of states and transitions objects from configures
files.
must
9
Automatic
include of
exported files
Automatic include generator created and exported source
files to the project of game
can
10
Documentation
of source code
generator
Documentation is used to describe the source code
algorithm of generator
must
1
8
must
4.1. Implementation of role-playing game application
Designed and implemented game is created based on object-oriented approach. RPG
application is programmed by using Windows Forms. Classes and their objects are virtual
equivalents of gaming objects, equipments, characters, locations and situations in the game or
user variables. The application is based on the mutual interactions of these objects. Most of
the objects keep their data in text or image files. Text files are created using the scripting
language Lua and keep numeric or text values. These files imported and processed RPG
application using external libraries LuaInterface. The files are saved in the data folders of
RPG applications. Files have specified extension by to objects. This determines which files
and how they have RPG application to import, and then processed. Import from files allows
quickly and effectively modify or create new objects.
The imported data will be used for creating game objects that are save in lists of data type
Dictionary with identifying name of the object. Where the game situation asks for object,
these lists provided via identification name.
Also, all of the text data in the visual interface is imported from text files, allowing quick
modification and proofreading, or offering the ability to easily to implement another
language to game.
The concept of role-playing game is implemented based on the model-view-controller
architecture. This architecture divided application into logical units and more-transparent the
source code. It also allows easy modification of algorithms without having to interfere with
the GUI and to modify the user interface without any direct danger to the game mechanics.
4.2. Implementation of finite state machine structure
Designed FMS software structure implemented in RPG application is created using the
object-oriented design. FMS mechanisms are divided into different classes, which handle the
process. Software structure FMS uses encapsulation, inheritance and polymorphism. As well
as RPG application structure of FMS is subject to the Model-View-Controller architecture. It
is very important to keep this architecture due to quick modifications and proofreading, or the
possibility to easily implement another language to locations.
The whole structure consists of fifth primary classes of section Model: StateMachine,
State, Transition, StateFactory and TransitionFactory.
Class StateMachine is primary class of FMS. He is responsible for initializing FMS,
controlling states and transitions and provides data for GUI.
• Constructor set default start state to current state and ensure initialized of static class
StateFactory and TransitionFactory.
• Method PosTrans provides a list of transitions, which condition is true and relevant in
formations for section View.
• Method AutoAction find the transition, which condition is true and is executed
automatically, without selected by the user.
• Method ExTrans find the transition, which is selected by the user and ensure to
execute of the transition action and set new current state.
Class State is abstract class, which represents state of FMS. Includes following private
attributes:
• idName is identifying name of the state,
• exploration represents the possibility of interaction with equipment in the locations,
• stat determines to display statistics and player's interaction with inventory,
• transitions is list of transitions for which this state is start state,
• part is a numerical index reflecting the current part of location, the initial index for
each state is value 1. Index is used to display some of the text on GUI, or can used by
conditions of transitions.
• enabled determines approach to transition for which this state is final state,
• object is a unique value that characterizes the state, e.g. whether it type of location is
map, combat or trade.
Class Transition is abstract class, which represents transition of FMS. Includes following
private attributes:
• idName is identifying name of the transition,
• startState is start state of transition,
• finalState is final state of transition,
• auto determines whether the transition execute automatically, without selected by
user,
• hide determines whether the transition disabled after its execution,
• point is value of x and y coordinates on GUI.
The essence of transition methods are following:
• Condition evaluates whether the condition of transition is true,
• Action executed to mechanics of game and provides the data for GUI.
Class StateFactory is a static class that is responsible for initializing all generated states.
Instantiated conditions are saved in the attribute states. The essence of classes is generated
methods that provide access to save or new instances.
Class TransitionFactory is a static class that is responsible for initializing all generated
transitions. Instantiated conditions are saved in the attribute transitions. The essence of
classes is generated methods that provide access to save or new instances.
Conclusion
Effectiveness of structure of FMS and source code generator was tested using professional
adventure settings Khyber’s Harvest [3]. Data from this book was easy and quick transformed
to configure files of FMS. This files was import, generate and export via source code
generator to RPG application. Finally was game adventure successfully tested by role-plaing
game application.
References
[1] POLÁK, Maroš. 2013. Fuzzy-based Decision Making in RPG. STU-MTF, Reg. No.:
MTF-5262-6510.
[2] BOURG, David., SEEMAN, Glenn. 2004. AI for Game Developers. O'Reilly, ISBN: 0596-00555-5.
[3] BAKER, Keith. 2009. Khyber’s Harvest. Renton: Wizards of the Coast, Inc.