DEVELOP-FPS A First Person Shooter Development Too
DEVELOP-FPS A First Person Shooter Development Too
net/publication/235450784
Article in International Journal of Interactive Multimedia and Artificial Intelligence · September 2012
DOI: 10.9781/ijimai.2012.167
CITATIONS READS
0 1,967
3 authors, including:
Paulo Urbano
University of Lisbon
66 PUBLICATIONS 744 CITATIONS
SEE PROFILE
All content following this page was uploaded by Paulo Urbano on 22 August 2014.
that allow monitor and control an individual character, define II. GENERIC ARCHITECTURE
and deploy specific scenario situations, gather data and
Our generic architecture is composed by four main
statistics of running experiments, and get different perspectives
components: The NPC behaviour definition script; the
of the scenario.
individual control console; the global control console; and the
In the next section we detail our generic architecture in a
game engine server. These components were substantiated
global perspective. In section 3 we present our application and
using the Jess Rule Based Language [7] to define the
the options made. Finally in section 4 we make some
characters behaviour and the Unreal Engine as the game
conclusions and provide future development directions.
server. This architecture is outlined in figure 1.
Fig. 1. Generic architecture: the Unreal Tournament Server, The Global Console and the individual Non Player Character Agents with the Jess scripts.
We can split this architecture in two main component tool. The simulated environment provides a game world with
classes: individual character management, and global a physical engine, graphical representations of the environment
management. The first group comprise the tools to access, from different points of view, and functionalities to interact
monitor and control and individual character. Through those with the scenario – actions an NPC can perform and
tools the developer can issue commands to the agents, using information it can perceive. As stated before the actions and
the individual console, which can cause a wide range of perceptions are made available through the middleware
effects, from alterations in the character internal interface.
representations to consequences in the game environment. In The global console offers a set of functionalities to manage
order to maintain a certain degree on independence from the the characters as group, issuing commands that all of then must
specific game environment, all the control of the NPC avatar accomplish.
in the environment is actuated through a middleware interface One of our objectives with this generic architecture was to
(Pogamut), that provide an intermediate abstraction over the provide a relative independence between what are the tools
game engine. The NPC behaviour script can be debugged and made available to the development, debugging and execution
executed using the console, the developer can directly control of characters behaviour and the specifics of the game engine.
the interpreter, issuing commands, stopping execution, testing This architecture is an evolution of earlier work presented
alternatives, and monitoring execution. originally in [8].
The second group comprise the simulated environment
where all the characters actuate, and a global management
-53-
Special Issue on Intelligent Systems and Applications
III. THE SOFTWARE TOOL DEVELOP-FPS was designed for developing scripts for the Game Unreal
Tournament but it can easily be adapted to other game
DEVELOP-FPS is a software tool written in JAVA,
platforms.
specially designed for the development of First Person Shooter
In figure 2 we may see an example of DEVELOP-FPS in
(FPS) players controlled by Rule Based Scripts in Jess.
action: In the centre two NPCs are fighting, on the right the
DEVELOP-FPS may be very powerful if used by FPS
Global Console is displayed and on the top and left we can see
developers to create, debug, maintain and compare rule base
the individual console of one the players and the 2D-map as
player behaviours along a number of repeated experiments. It
seen from the that player perspective.
Fig. 2. A screenshot of the game control with four windows displaying a graphical view of the environment, two 2D maps representing a global situation an
individual position, an individual control console.
We will now proceed to detail the tool architecture and their position to the Global Console every 0.5 seconds.
main components and respective functionalities. In the top of the console we see the IDs of the connected
clients (the individual identification of each game character),
A. Global Terminal
and the one selected will have its respective console displayed,
The global console role functions are: 1) to offer a bird eye the others will be hidden—only one of the individual consoles
view of the world, providing a 2D map of the game world and can be displayed at any moment. In the bottom we may see
displaying the waypoints and character positions; 2) launching two buttons that are used to stop the game execution of every
an individual console for each character giving the user the character (“Stop All”) and to resume their execution (“Resume
possibility to monitor and control each NPC; 3) the possibility All”). This is an important feature for developing behaviours
to stop and resume the game execution; and 4) to automatically for game characters, due to the frequent necessity to stop the
run a certain number of game executions and collect data in game execution for debugging and testing behaviours.
order to evaluate and compare the characters performance There are three parameters for the repetition of a set of
along a sufficient number of similar experiments. In Figure 3, similar experiments: 1) The duration of each run; 2) the
we see a snapshot of the global console in a game played by 2 number of experiments and 3) the number of agents. Note that
NPCs with IDs 218 and 219. each game can end because there is only one player left or
AS we said above, the global console 2D map will represent because the duration has reached the defined limit.
an updated bird eye view of the NPCs positions (large circular The Global Console is responsible for start up the NPCs,
icons), with a different colour for each NPC, and also the run the game until it finishes, collect the game reports and
waypoints: the reference locations in the environment defined destroy the NPCs, repeating this procedure the right number of
by the user, for navigation purposes. The information is runs.
obtained from each NPC trough Sockets: each NPC sends its
-54-
International Journal of Artificial Intelligence and Interactive Multimedia, Vol. 1, Nº 6
Fig. 4. Example of a NPC terminal. On the top section the Jess data, which can be totally or partially hiden. On the left, three manual movement and orientation
button controls. On the right, the agent state may be displayed, and on the center, we see the command window .
-55-
Special Issue on Intelligent Systems and Applications
-56-
International Journal of Artificial Intelligence and Interactive Multimedia, Vol. 1, Nº 6
Fig. 8. Jess monitoring information: the working memory facts list, the rule activations and fired rule and also the user defined functions along with other
useful built-in functions.
After stopping a NPC, it will be easy to test the script rules, Thus, it is convenient that the script developer separates the
monitoring their activation in a certain situation. We can Jess rules in two modules: one specialized in gathering
follow the rule-based behaviour of a NPC using the step information like, for example, the nearest enemy location, and
control button and observing the Jess information on the the other specialized in actions, like moving or shooting. In
individual terminal window. each module more than one rule can fire—each module is
The user defined functions visualization was introduced executed only when no more rules fire. Therefore, the script
with the goal of helping the user just in case he wants to must carefully manage the return of the control to JAVA so
execute a particular function using the command window. It that Jess rules in any of the two modules do not fire forever.
will certainly be useful for him to look up for the right function
name. TABLE I
A JESS SCRIPT TO ILLUSTRATE A SIMPLE NPC BEHAVIOUR DEFINITION
On the right of the terminal window, depicted in Fig. 5, we USING A PERCEPTION/ACTION CYCLE.
see three buttons that allow us to hide any of these three Jess
;An example of Deftemplate
information types. ;to store all about the agent
(deftemplate bot
6) Command Window (slot see-enemy)
For a full agent monitoring and control, in the individual (slot hear-anything)
terminal is offered a command window, which is an interface (slot moving)
(slot nav-target)
where the game developer has the possibility to execute any (slot enemy-target))
Jess command and behaviour or perception functions and
;Setup
observe their output. This is an important tool for script (deffacts SETUP
exploration and debugging besides being very useful for (perception)
(action)
setting up test situations. (bot (see-enemy FALSE)
The user can fire rules step by step tracing the NPC (nav-target nil)))
behaviour, following the evolution of the NPC state and facts (defmodule PERCEPTION)
list as well as the rules activation and selection. Or he can
execute some specific Jess function that extends the NPC state ;Rule to collect info about the agent
(defrule perception
besides the standard information given on the right and ?f <- (perception)
referred on III.B.2. The user can even create a function in real- ?x <- (bot (nav-target ?target))
=>
time and execute it, and as Jess is written in Java, he can have (retract ?f)
full access to the Java API. (assert (perception))
(modify ?x (see-enemy
As an example, consider that we want to test the script when (see-enemy-func))
the user is facing the enemy. We would run the game until our (enemy-target
(get-enemy-location)))
NPC sees its enemy and that after pausing the game, we would (return))
pick up the right user defined Jess function: (turn-to- enemy),
and execute it in the command prompt. Afterwards we would (defmodule ACTION)
see the ordered list of rule activations in the window terminal ;Rule to pursuit and fire at the enemy he sees
by executing the (agenda) command, so that we could check if (defrule fires-and-pursuit-enemy
(declare (salience 100))
the rules script were behaving as expected. ?a <- (action)
?bot <- (bot (see-enemy TRUE)
C. The Execution Step: the interface between JAVA and JESS (enemy-target ?t&~nil))
=>
The game execution is divided in steps, but the script (retract ?a)
developer is responsible for the definition of what is a step, (assert (accao))
although there are some restrictions. The JAVA NPC (go-to-enemy ?t)
(shoot ?t)
controller will always put two special Jess modules in the (return))
focus stack: the PERCEPTION and BEHAVIOR, and will
issue a (run) command for execution of the PERCEPTION
We show in Table I an example of a toy Jess script, only for
rules followed by the BEHAVIOR ones.
illustration. The (return) command assures that control no
-57-
Special Issue on Intelligent Systems and Applications
more rules are executed inside the respective module: after a each module and so a step execution will fire 2 rules in case
(return) in a PERCEPTION rule, control is given to the they are both activated.
ACTION module, and after a (return) in an ACTION rule, At table II we present another short example of the Jess
control is given back to JAVA, putting an ending in the step. code to control the character movement in a formation
We can see several perception and action functions: (see- controlled by the group leader. As the previous example the
enemy-func) returns a boolean and (get-enemy-location) behavior is controlled by a cycle of perception/action activated
returns the enemy position coordinates; (goto-enemy) means be a message from the squad leader. This message indicates to
that the MPC goes towards a position near the enemy and the character is new position on the formation and the
(shoot) means the NPC turns towards the enemy position and direction it should be facing. When a new message is received,
shoots. the PERCEPTION module stores the information of the
Note that while in the JESS command window we can character new objectives. This information is used to activate
execute a rule after another monitoring behaviour in a thinner the module ACTION and execute the appropriated actions to
scale than a step. In the example given there is only one rule in achieve those goals.
TABLE II
AN EXEMPLE OF A PICE OF CODE THAT CONTROL THE MOVEMENT OF A CHARACTER IN A FORMATION
(defmodule PERCEPTION)
(defrule perception
?f <- (perception)
?x <- (bot) ; representation of BOT current attributes
=>
(retract ?f)
;If received a message to move in formation (id 9)
(if (and (eq (get-receiver-team-id-from-message) 9))
then (bind ?var (select-place-on-diamond-formation
(get-location-from-message)
(get-rotation-from-message)))
;setup destination
(modify ?x (nav-target ?var))
;setup bot rotation
(modify ?x (rot-target
(select-rotation-on-diamond-formation ?var)))
)
(assert (perception))
(store RuleFired perception)
(return)
)
...
(defmodule ACTION)
(defrule go-to-destination
?a <- (action)
;If there is a destination and a rotation
(bot (nav-target ?target&~nil)(rot-target ?rot))
=>
(retract ?a)
(assert (action))
;move bot
(go-to-target ?target ?rot))
(store "RuleFired" go-to-destination)
(return)
)
...
.. )
This rules and modules can be combined in more complex Although the integration of different pieces of code is not
behaviours, taking advantage of the capability of the tool entirely error free, these characteristics provide us with a
environment to make extensive tests to each component. significant enhancement over the current accessible tools.
-58-
International Journal of Artificial Intelligence and Interactive Multimedia, Vol. 1, Nº 6
-59-