Swarm General
Design Document
Nolan Lichti
Masters Thesis Project
09 April 2004
Information Design and Technology
Literature, Communication, and Culture
Committee:
Michael Mateas (chair)
Janet Murray
Sha Xin Wei
Abstract
Even as video games become more common form of entertainment for the general
public, the number of games geared toward the casual gamer remains fairly low.
While strategy games remain popular amongst more serious gamers, the genre still
has not been made available to the general public. Most strategy games either
require good dexterity to master the controls, or contain fairly mundane activity.
These qualities are not inherent in the design of strategy games. Instead, they follow
tried and true conventions that suit more serious gamers. In order to make a game
more attractive to the casual gamer, the mechanics must be simplified without
denying the player any sense of agency. By allowing the player to define rules for a
simulation engine that controls his units, the player can maintain a sense of agency
without having direct control over his units. Furthermore, defining these rules can be
simplified by using techniques from programming by example research.
Introduction
Design Goal
The primary goal of Swarm General is to create a strategy game that targets the
casual gamer. Ernest Adams separates casual gamers from core gamers:
The core gamer plays for the exhilaration of defeating the game. The core gamer is much
more tolerant of frustration, because what the core gamer wants is a sense of having
achieved something, having overcome an obstacle. The greater the obstacle, the greater
the sense of achievement. The core gamer is engaged in a competition - with himself,
1
with the game, with other gamers. A core gamer wants a sense of reward and “bragging
rights” from having beaten the game...
By contrast, the casual gamer plays for the sheer enjoyment of playing the game. If the
game stops being enjoyable or becomes frustrating, the casual gamer will stop playing.
Obviously the casual gamer enjoys a challenge and wants to win, but the old cliché
applies: life is a journey, not a destination. For the casual gamer, playing games must be
entertaining, whether it's competitive or not (Adams 2000).
Additionally, Adams points out that “The casual gamer wants to play games the
same way she watches TV or reads a book: sit down, do it for a while, then stop and
do something else,” unlike core gamers who “spend a great deal of their leisure time
playing games.”
Based on Adams's observations about the casual gamer, as well as my own casual
observations, I can create a basic profile of the casual gamer. The design focus of
this project lies in these four points about the casual gamer:

They have a low time commitment. Adams points out that casual gamers play
games the same way they watch television or read books. Therefore, games must
be able to be played in short sessions (less than an hour).

They desire simple controls. If the control scheme is too complicated, the casual
gamer will become frustrated, and stop playing. This also goes hand-in-hand with
the time commitment requirement, as more complex control scheme require the
time dedication to learn them.

They desire action and/or a compelling story. As Adams points out, “playing
games must be entertaining.” Similar to a movie, games that provide lots of
action and/or a compelling story will be more entertaining than games that only
provide a challenge to the player. Casual gamers need more than just a challenge.

They often play socially. This is something true of all gamers. However, there are
many examples of games being used as casual, social entertainment. This
includes non-digital games like pool, bowling, and softball, as well as digital
games with services like Yahoo Games.
The strategy genre is one of my favorite genres. While this did lend to my decision of
making a game within this genre, I also believe that the strategy genre is a good
place to apply this design focus. Strategy games can be competitive, which
immediately lends itself to social gameplay. Additionally, the challenge of strategy
2
games lies in the planning and adapting of the player. More importantly, the
challenge does not have to lie within the dexterity required to play the game. As we
will see, some existing strategy games also hold the properties of being actionoriented and require low time commitments. While it may not be impossible to
implement a compelling story with a strategy game, integrating a fluid story within
strategy gameplay is a challenge. For this reason, this design will focus on creating
an action-oriented game.
Critique of Current Strategy Games
For the sake of argument, I divide most digital strategy games into two categories:
real-time strategy (RTS) and turn-based strategy. These are terms used by the
game press to differentiate between two styles of similar gameplay. In RTS's, the
action is non-stop, which forces the player to make decisions while the action is
happening. The player does not have a chance to stop the action. In turn-based
games, the player is allowed much more time to contemplate decisions. This
decision-making is followed by short moments of action.
The canonical RTS games are Warcraft and Command and Conquer. Other games fall
slightly outside the conventions of these two games, such as Black and White and
Pikmin. Aspects of the RTS model can be attractive to the casual gamer. The
matches tend to be fairly short (the average game on Battle.net, the Warcraft III
online service, is less than 20 minutes). Additionally, the matches are more exciting
than that of a typical turn-based game, where there is very little action.
The problem with the RTS model lies in the micromanagement required of the
player. Micromanagement describes a granularity of control available to the player.
Two aspects factor into micromanagement. First, there is the granularity of scope.
This describes the number of entities controlled by an action. For example, individual
unit control would have a small scope, while controlling large groups of units would
have a larger scope.
Second, there is the granularity of task. This describes how specific the task is that is
assigned to the unit. For example, the player could order a unit to build a building. If
the unit knows to collect the proper resources as part of the building process, the
3
granularity of task is higher. If the player has to issue separate commands to collect
the resources and build the buildings, each of those are small tasks. The granularity
of task is strongly related to a temporal granularity. Small tasks often have to be
reevaluated by the player, and new tasks have to be issued more frequently. Larger
tasks, where the unit will make some decisions on its own, will require less frequent
intervention from the player.
Micromanagement describes any action that has a low granularity of scope and a low
granularity of task (see Figure 1). As both of these granularities increase, the control
is better described as macromanagement. However, there can be cases where one
granularity is higher, and the other is lower. In these cases, the control starts to
enter areas that could be either macro- or micromanagement. For example, a player
may be able to issue commands to groups of units instead of individual units. In this
case, the granularity of scope is a bit higher. However, if the player must issue
specific commands to the groups (maybe setting formations or commanding them to
focus their attack on a certain unit), the granularity of task is quite low. In this case,
this is best described as micromanagement. However, by increasing the task
granularity, the control could become macromanagement.
Figure 1, Micromanagement Graph
4
RTS's tend to have some amount of micromanagement. The player is required to
build every unit and building, and give orders to the units as well. This
micromanagement becomes even more difficult as some units have special abilities
that must be activated and targeted during battle. Most games have a small
granularity of scope, where the player must command individual units or small
groups of units. Task granularity is even smaller, as units do very little without
player intervention. The units are often “smart” enough to attack when an enemy
unit comes within acquisition range, but even this may not be what the player wants,
requiring the player to override a potentially dumb decision made by a unit. This
level of micromanagement requires good dexterity, and the casual gamer may find it
too big of a learning curve to overcome.
A few current RTS's are taking steps to alleviate the player control over many units.
Medieval: Total War has the player controlling unit groups instead of individual units.
Each group has around 60 units, and the player has control over the groups
movement, attack strategy, and formation. While this increases the granularity of
scope, Creative Assembly's system maintains a very low task granularity by requiring
the player to manage formations and complex troop movement. While they achieved
a great game that focuses on commanding a large number of units, they still do not
serve the casual gamer.
Relic Entertainment has also been exploring different control schemes. With
Homeworld, they introduced a fully three-dimensional space RTS. With basic RTS
controls, the player could command space fleets in three-dimensions. The result was
spectacular space battles without much of a learning curve for those accustomed to
the RTS genre. Again, this did not serve the casual gamer, as granularity of scope
and task granularity remained low, but it was a step to provide more complex action
using standard RTS controls. Their newest game (unreleased at the time of this
writing), Warhammer 40,000: Dawn of War appears to be taking another step to
simplify the genre. It is not clear how the control scheme works, but the units will
have more complex actions that they perform autonomously. This includes being “in
cover,” where troops will move more slowly but attack with higher accuracy, and
“routing,” where a unit will flee when its morale breaks. This is an increase in task
granularity, which may decrease micromanagement. Additionally, the resource
5
system will go hand-in-hand with the battle, as controlling more command points
(special locations) earns the player more resources. No resource gathering is
required (Smith 2004). This is one less task the player has to worry about,
decreasing further the task granularity. In this way, Relic allows the player to
concentrate on micromanagement of only his units in battle, which also decreases
the granularity of scope slightly. However, the casual gamer may still find the
amount of micromanagement overwhelming.
Turn-based strategy games vary a little more than RTS's, but Civilization III and
Warlords IV stand out as two popular titles. The turn-based strategy model
overcomes problems of micromanagement by allowing the player to micromanage
outside of the action. The player can take their time in building units and buildings
without having to worry about the other player doing it faster (or worse, the other
player attacking while he is making a decision). Additionally, there is generally less
micromanagement as the player usually has little or no control over a battle once it
has started. This is a significant decrease in task granularity and granularity of scope
compared to an RTS, where successfully micromanaging individual units to attack
and retreat can win or lose a battle. All this allows a player with less dexterity to play
on an equal level with a player that might be more dexterous.
The turn-based model has its problems as well. Due to these decision periods,
usually of indeterminate length, the games are often very long. Some players opt to
play a single match of Civilization over several days or one very long day. This does
not suit the lifestyle of a player who may want to just play a quick game in his spare
time. Additionally, because the action periods are short (and usually include very
little visual action), turn-based games tend to be less exciting than RTS's.
Influences
The concept of Swarm General came from two primary influences. First, I find
strategy games interesting. When I first tried to play real-time strategy games, I was
overwhelmed with the amount of micromanagement required to control all of my
units and my base without the action stopping. Being a more serious gamer, I was
willing to overcome the learning curve, and I have adapted to the RTS style of play.
However, in the back of my mind, I’ve always been interested in the design problem
6
of creating a simple control scheme for an RTS that maintains the action that makes
RTS's exciting.
My second influence was Steven Johnson’s book Emergence. In the book he
discusses how larger behaviors emerge from smaller behaviors. The book covers
everything from cities to slime molds to the World Wide Web. He also writes about
the behaviors of ant colonies, and how ant colonies can survive for years without any
central control over the colony. Instead, each ant evaluates its current surroundings,
and makes its decisions based on the local situation. Each of these local decision
supports the survival of the colony, and in the end, the colony survives like a living
organism without any central control.
Additionally, the ants survive because their stimulus-response decisions are
automatic:
Animals, [ethologists] realized, survive by responding swiftly and precisely to the fastmoving environment, hence the reliance on simple pieces of their sensory world. The
responses in turn must often be complex, unlike the sign stimuli, and delivered in exactly
the right manner. Animals are rarely given a second chance (Hölldobler 1994).
The key here is that the ants respond to simple stimuli without deep analysis. They
have a set of rules that they follow without question. While the decision may not be
the most beneficial to the individual ant, it promotes the survival of the entire
colony. RTS players make their decisions for this same purpose. However, they make
their decisions carefully, and their decisions are usually based on their evaluation of
the army as whole.
How could a local stimulus-response model be used within the context of an RTS?
The player control could potentially reside in one of three places. First, the player can
control each response individually. Basically, this is the current RTS model, where
the player evaluates the situation and responds appropriately.
Second, the player could control the environment (stimulus) to which the units
respond. One could imagine a paint-like interface where the units respond to
different “paints” (stimuli), and the player paints the playing field based on how he
wants the units to react to that area. SimCity 4 acts in this manner, where the player
paints zoning areas, and the city grows based on the rules of the simulation engine.
7
This model may work for an RTS. However, while it does lessen the amount of
micromanagement, it still places the unit control on the player.
Finally, the player could control the rules of the simulation engine itself. Instead of
manually responding to situations, the player can give the units fundamental rules
that define how they respond to local stimuli. Swarm General aims to allow the
player to actually define the stimulus-response rules for his units. In this way, the
units make local decisions similar to how ants do, but the player maintains control
over these units by defining how the units will respond.
Design Approach
Meeting Design Criteria
As stated earlier, one of the design goals is to maintain a relatively short game
experience. To me, this means that the average match should last around 30
minutes, and should rarely last an hour (approximately the amount of time someone
might spend watching television in an evening). First, to get around the time
problem of turn-based games, it is evident that the periods of “no action” should be
limited. RTS's limit it by eliminating them completely. Another alternative would be
to limit how often they occur, and how long they last. Limiting times of “no action”
also creates non-stop action that provides the player with an exciting experience.
Another important difference that affects the length of a match is the scale of the
game. Most turn-based games have a large scale, while RTS's tend to be small scale.
A large-scale RTS would be difficult to play. This is a design problem that would have
to be solved by creating a control scheme with a large granularity of scope. However,
a small-scale turn-based game would not be impossible. Board games such as chess
and Stratego show that this is possible. Even so, without limiting the amount of “no
action” periods, these games could take a long time to play. Currently, developers
probably choose to create only large-scale turn-based games as they are able to do
this easily in the digital environment. Creating the larger arena does not cost the
developer any more than if they were to create a smaller arena, so they go ahead
and make it large.
8
The solution to the micromanagement problem is a little trickier. One solution would
be to increase the granularity of scope by requiring the player to control only one
unit. In this way, the player is controlling all units under his control (the one unit)
every time he performs an action. In SimAnt, the player has control over one ant at
a time, and he can define general rules for the entire colony. The simulation engine
takes care of the rest. While this is an implementation of a large granularity of
scope, it leaves the player with a very unsatisfying feeling of not really doing
anything. What I propose is that the player does not need direct control over the
units, but instead should have some control over the simulation engine itself. For
every unit type, the player can develop some high level rules. The simulation engine
controls the units based on the rules the player has established. This allows the
player fairly high granularity of scope because he can define rules for entire sets of
units instead of individual units. However, he is not relinquishing control so much
that he loses a sense of control over the outcome of the game.
Additionally, it is important to limit or eliminate base management. Many strategy
games have some amount of base management. Base management consists of
constructing buildings, researching upgrades, or building units. Buildings are used to
create units or to allow researching. Each building type will be able to produce
specific unit types or have specific upgrades that can be researched. Researching
upgrades either makes units more powerful, provides new abilities for units, or
allows for new buildings to be built. Unit production is often the only method of
obtaining more units for battle. Games like chess and Stratego do eliminate base
management by providing the player with preset units. However, this reduces the
combinatoric depth of the game. Myth allows the player to select all their units from
a set of units before a match, allowing for each player to have a different set of
units. I see this as a possible design strategy. Another option would be to limit base
management. An important way to do this is make unit construction easy. However,
this is not as vital as the player can concentrate on these actions because unit
control is easier.
Player Defined Rules
As stated above, micromanagement problem can be approached from the
perspective that the player does not need direct control over his units. In fact, there
9
is an entire genre of digital games that allow the player to define some set of rules
for their agent or agents. While the exact implementations of these programming
games vary, the basic set up is the same. The player has an agent (or agents) that
he controls. His agent goes into an arena with other agents to battle each other.
Before the match, the player programs his agent's intelligence. In doing so, the
player defines how the agent should act in a variety of situations. The player then
sends the agent into battle. At this point, the player has no control over the agent
through the rest of the match. The last agent still alive wins. These games provide
the benefit of the hands-off approach to player control, but at great cost. Core Wars,
AI Wars, and Robocode all require the player to use some complicated programming
language. The learning curve for this language is at least a high as the dexterity
required to play many RTS's. They are more of a way to show off the player's
programming skills than a way to show off the player's ability to plan and adapt. An
interesting exception to this is the board game Robo Rally. Robo Rally allows the
player to issue five commands to his robot each turn. These commands are simplified
into things like “turn left” or “move two.” This exemplifies a simple programming
interface, but doesn't really give the robot intelligence. Instead, they just follow the
simple instructions without adapting to their environment. Additionally, because it is
turn-based, Robo Rally can take a long time to play.
Figure 2, Robocode agents in the arena
10
Figure 3, A snippet of code for a Robocode agent.
The player must use Java to program their agent.
However, we can approach unit control with the programming model as long as we
can provide a simple interface for programming the units. To do this, it is important
to look at the programming by example literature. The theory of programming by
example is that the player shows the program what to do, and the program can
abstract the proper coding from the examples (Cypher 1993). Cypher's Stagecast
demonstrates a system that functions on programming by example techniques. The
Stagecast system allows users to create rules to define how specific props interact
with each other in a scene. The rules established are very literal, and are not
abstracted much. For example, a rule might say that when a chair is to the left of the
boy, the boy will sit in the chair. On the stage, the boy will sit on any chair that is to
his left. However, if there is a chair to his right, he will not sit in it (unless another
rule is created to define that situation). This system works because there is enough
abstraction so that, as in our example, the boy will sit in any chair. Additionally, it is
literal enough that there are very few unexpected results. This way, users can
successfully script a scene by properly placing props and defining the correct rules.
11
Using similar techniques, we can establish the rules for our unit types. Because our
units exist in a universe where most of the values are known, such as the different
unit types, we can create a system similar to Cypher's Stagecast that would allow
the player to easily program his unit types. The player can establish conditionals by
setting up a local scenario for that unit type. Based on that scenario, the player then
establishes the unit's response. This interface is easier to work with than the modal
interfaces of other programming games that force the player to switch between a
text editor and the actual game world.
Project Scope
The focus of this project is heavily on the rule system, from rule creation to proper
execution of the rules. Because of this, I chose not to pursue any other innovation in
the real-time strategy genre. For the most part, I followed the traditional RTS model
established by games like Warcraft and Command and Conquer. Additionally, I did
not develop a full game, but enough to understand how this system would work
within a full-scale RTS.
Finally, I have also borrowed balancing numbers from Warcraft III in order to solve
any balance issues. Balancing is one of the most difficult aspects of strategy game
design. Most strategy games have various numeric factors that allow for a variety of
strategies. For example, in Warcraft III, every unit has base damage, damage dice,
attack type, armor type, and armor. All of these attributes factor into how much
damage is dealt in an attack. Units have hit points, which determines how much
damage they can sustain. Units have mana points which are used to cast spells.
They also have mana and hit point regeneration rates. They also have numbers that
determine how fast they can move and attack. Each unit builds at a different rate
(some take longer to build than others), and cost different amounts of resources. All
of these values must be balanced to ensure that one unit type isn't so powerful that
other unit types are obsolete. When properly balanced, a strategy game will allow for
players to choose from a variety of play strategies, none of which are guaranteed to
win. As this is a very time-consuming process, balancing new numbers was not in
the scope of this project.
12
Positioning in Design Space
Swarm General finds itself in a unique design space among strategy games. Figure 4
shows the different areas filled by existing games with logos from various games.
Empty design spaces are indicated by the null symbol. Swarm General is indicated in
a space that is currently unoccupied by other games.
Figure 4, Position of Swarm General in design space.
The games that do not require programming are the most common. Real-time
games such as Warcraft III fit in the small-scale, no programming space. The largescale space for all real-time games (both those that do and do not require
programming) remains empty at this time, most likely for design reasons. As difficult
as it can be to control many units and structures in a small-scale game, that
difficulty is multiplied when creating a large-scale game. Turn-based games that do
not require programming include Civilization (large-scale) and chess (small-scale).
13
Games that do require some amount of programming only fill one space: small-scale
turn-based. By turn-based, I am referring to the fact that most either require turns
to rewrite a program (Robo Rally), or there is one setup period during which the
programs are written, followed by action that is not controllable by the player
(Robocode, AI Wars). The large-scale space has not been filled either, most likely as
a result of the complicated programming required. In order to fully tweak the
complex routines that the agent performs, the player must be able to concentrate on
one agent. A large-scale game requires programming many agents.
Swarm General fits in a space that requires some programming, is small-scale, and
is in real-time. In this space, it meets the goal established earlier:

Low time commitment. RTS games tend to be fairly short because of the small
scale and the constant action.

Simple controls. By using the programming model, the players do not have to
control each of their units. The programming is made easy by using programming
by example techniques.

Action and/or a compelling story. RTS games have lots of action because of the
non-stop nature of the genre. I'm not pursuing the option of creating a compelling
story.

Social play. Strategy games are generally competitive, and competition is social in
nature. While this implementation will not feature multiplayer capabilities, this
could be implemented in the future.
Implementation
Limiting the RTS Model
Due mostly to time constraints, I was forced to leave out a few typical RTS elements.
However, I have implemented the heart of the model to the point where the
effectiveness of this system can be judged appropriately. The system should be
scalable to a full RTS game.
First, I'm limiting the game to one player against a computer opponent controlled by
14
a simple artificial intelligence. While the computer may be an easy opponent, we
should be able to effectively evaluate how the control scheme works based on the
player's ability to make his units act in the desired fashion. We can imagine that this
would translate easily to a networked, multiplayer game between two opponents,
and further implementation could extend it to multiple opposing and allied players.
Currently, each team has only three unit types: the worker (for gathering resources),
the soldier (melee combat), and the archer (ranged combat). Again, the system is
not customized to these unit types, and is fully scalable to more unit types. Further
implementation would be necessary to compensate for special abilities performed by
units, which have not be implemented in this project. What is not being captured in
this implementation is the scale of the rule sets necessary to control many unit
types. While this should be a concern, default rule sets should also be included with
any implementation, mitigating the problem.
The player can only build barracks and farms. The barracks produce the units, and
the farms allow you to have more units. There is no “tech tree”. Most strategy games
utilize a tech tree, which defines a hierarchy of units, buildings, and upgrades. At
first, players can only build certain buildings and units. Each of these buildings
serves the purpose of allowing the player to upgrade units or build specific units. By
constructing certain buildings or making certain upgrades, new buildings, upgrades,
and units are available to the player. Swarm General does not have a tech tree as all
buildings and units are available to the player at all times (assuming they have the
proper resources). There are no upgrades to research.
The buildings are constructed instantly. Many games have buildings be built over
time, where more functional buildings might take longer to build. Additionally, some
games require that a worker be present to build the building. Swarm General does
not place any requirements on building construction as long as the proper resources
are available. This also allows the player to build anywhere on the map. If it took
time to construct a building, enemy units could easily destroy a building before it
was completed. This would make it impractical to try to build buildings too close to
the enemy. In Swarm General, this impracticality is possible (but is still not a very
good strategy).
15
The entire map is visible to the player. Many games have “fog of war.” This is the
concept that the player's view of the map is limited to areas that contain the player's
units. In this way, the player can only see what his units can “see.” Swarm General
does not place this restriction on the player's view.
All of these issues do not affect the aspect of gameplay that this project focuses on:
the control of the units. These elements could easily be implemented alongside the
rule system in a full-scale RTS.
Player's In-game Actions
As it is the goal of the project to create a more accessible interface, the in-game
actions of the player are appropriately limited. The player has control over basic base
management. He can construct new buildings and train new units. Additionally, the
tag system allows the player to tag resources that workers should gather. The tag
system also allows the player to provide units with a destination if none of their local
rules fire. The player must strategically use the tag system to dictate the movement
of his armies.
The player can also adjust rules in-game. The player can update his rules on-the-fly,
and the units will start using the new rules as soon as the player updates them.
Currently, the game allows the player to pause the game, during which he can adjust
his rules without worry about what is happening in the game. In a multiplayer
situation, this is not ideal. Instead, the player may be allotted a certain number of
“time outs.” A time out would last a short period of time, and the game would
resume whether the player was ready or not after the time out expires.
Rule Engine
The rule engine utilizes the Java Expert System Shell (JESS). JESS is a rule-engine
developed by Ernest Friedman-Hill at the Sandia National Laboratories. The JESS
system utilizes a Rete network to do extremely fast pattern matching. The left-hand
side (LHS) of rules match themselves against asserted facts, and if there is a match,
the right-hand side (RHS) executes. Consider the following rule:
16
(defrule SoldierTagRule
?fact <- (tag (this-unit-type "Soldier") (type "attack"))
=>
(call (fetch action) add "tag")
(bind ?x (call ?fact getSlotValue x))
(bind ?y (call ?fact getSlotValue y))
(bind ?hyp (sqrt (+ (** ?x 2) (** ?y 2))))
(bind ?mag (- (call ?fact getSlotValue power) ?hyp))
(if (< ?mag 0) then (bind ?mag 0))
(if (< ?x 0) then
(if (< ?y 0) then
(bind ?theta (+ (pi) (call Math asin (/ (abs ?y) ?hyp))))
else
(bind ?theta (- (pi) (call Math asin (/ (abs ?y) ?hyp))))
) else
(if (< ?y 0) then
(bind ?theta (- (* 2 (pi)) (call Math asin (/ (abs ?y) ?hyp))))
else
(bind ?theta (call Math asin (/ (abs ?y) ?hyp))))
)
(call (fetch x) add (* 1 (* ?mag (call Math cos ?theta))))
(call (fetch y) add (* 1 (* ?mag (call Math sin ?theta))))
)
The LHS is everything above (to the left of) the arrow “=>”. In this case, we are
looking for a fact that uses the “tag” template (defined earlier) where the value of
the “this-unit-type” slot is “Soldier” and the value of the “type” slot is “attack”. This
fact is being stored in a variable called “?fact” for use on the RHS. The RHS is a
series of function calls that eventually stores three values: the type of action to
perform (in this case, a “tag” action), and the x and y coordinates of a vector that
defines how the unit should move. Most programming games would require the user
to actually use the JESS language to create a rule like the one above. As we will see,
Swarm General allows players to use a graphical interface to create these rules
without writing any code.
Each player has a rule set that is entered into a Rete network. The naïve method of
pattern matching would require the program to iterate over every LHS of ever rule
on every decision cycle. As more rules are added to the set, the performance of the
system decreases linearly. A Rete network, on the other hand, compiles all of rules
into a network in a way that allows for pattern-matching without iterating over every
LHS. A network could contain thousands of rules and perform at the same level of a
network with only a handful of rules.
There are three types of rules: attack rules, move rules, and tag rules. The LHS of
the attack and move rules represent the surroundings of a given unit. Each attack or
move rule has the following parameters:
17

The unit type that this rule applies to. This can be set so that the rule applies to
all unit types.

The health state of the unit.

The type of entity within the unit's surroundings. This could be a friendly units,
and enemy units, or even a neutral object.

The health state of the entity

The distance from the unit to the entity
The RHS defines how the unit responds in the given situation. If it is a move rule, the
player defines a vector that is used to calculate the entities final movement. For
every move rule that fires, the vectors are summed to determine the unit's final
movement vector. If it is an attack rule, it is assumed that the unit is attacking the
entity specified in the rule.
Tag rules have only one parameter: how strongly will the unit respond to the current
set of tags. When the player places a tag, he chooses from one of three power
settings for that tag. Each tag has this attraction power, and the power diminishes at
farther distances. The unit's movement vectors are determined by the power of
attraction to each of the tags. The sum of those vectors multiplied by how strongly
the unit will react determines the final movement vector.
In the current implementation, the rules have a hardcoded precedence. The unit will
always follow the first attack rule that fires. If no attack rules fire, it will sum all the
vectors from all the move rules that fire, and use the sum of the vectors to
determine the final movement vector. If no move rules fire, it will calculate the
movement vector from the tag rules. The tag rules will always fire when there are
tags present, but the unit may not move in the situation where there are no tags or
all the tags are far away from the unit.
As the move rule is the most complex rule, we will look at an example of one in
order to clarify the entire process. First, let's look at the move rule interface.
18
Figure 5, Move Rule Example 1.
Various parameters are being set here. The rule is named based on the text field at
the top. The dropdown displaying the white archer icon defines what type of unit this
is being defined for (“thisUnitType”). The white cross next to that icon indicates the
unit's health (“thisUnitHealth”). The white indicates any health state; red indicates
low health; yellow, medium; green; high. The dropdown displaying the dark unit is
the entity seen in the surroundings of the other unit (“entityType”). The dark units
indicate an enemy unit, while white units indicate friendly units (“entityOwner”). This
particular icon indicates any enemy unit. The dropdown next to the entity dropdown
is the entity's health (“entityHealth”).
The concentric rings show various ranges from the unit. The range tool is next to the
entity dropdown, and looks like concentric circles with a yellow ring. When using the
range tool, the player can click on a range ring to define the range parameter
(“range”). The vector tool is next to the unit dropdown, and is indicated by a
crosshair. When using the vector tool, the player can click anywhere on the
concentric circles to define the vector on which the unit will move relative to the
19
entity (“moveX”, “moveY”). The direction of the vector reflects the direction that the
unit should move, and the magnitude (length) of the vector indicates how strongly
the unit will want to move in that direction.
Swarm General translates the rule from that interface into JESS code. Every rule
type has a template of JESS code. The move template is below. The parameters are
indicated [parameter], and match the descriptions found in the above paragraph in
parentheses. The “action” parameter defaults to “move” for move rules.
(defrule [name]
?fact <- (single-entity
(this-unit-type "[thisUnitType]")
(this-unit-health "[thisUnitHealth]")
(entity-type "[entityType]")
(entity-health "[entityHealth]")
(entity-owner "[entityOwner]")
(range [range]))
=>
(call (fetch action) add "[action]")
(bind ?x (call ?fact getSlotValue x))
(bind ?y (call ?fact getSlotValue y))
(bind ?hyp (sqrt (+ (** ?x 2) (** ?y 2))))
(if (< ?x 0) then
(if (< ?y 0) then
(bind ?theta (+ (pi) (call Math asin (/ (abs ?y) ?hyp))))
else
(bind ?theta (- (pi) (call Math asin (/ (abs ?y) ?hyp))))
) else
(if (< ?y 0) then
(bind ?theta (- (* 2 (pi)) (call Math asin (/ (abs ?y) ?hyp))))
else
(bind ?theta (call Math asin (/ (abs ?y) ?hyp))))
)
(call (fetch x) add
(- (* [moveX] (call Math cos ?theta))
(* [moveY] (call Math sin ?theta))))
(call (fetch y) add
(+ (* [moveY] (call Math cos ?theta))
(* [moveX] (call Math sin ?theta)))))
The LHS of the rule is defined by everything except the vector. The vector is used in
the RHS to return the final coordinate that is relative to the unit asserting the fact.
The move rule has this corresponding fact:
(assert (single-entity
(this-unit-type "[thisUnitType]")
(this-unit-health "[thisUnitHealth]")
(entity-type "[entityType]")
(entity-health "[entityHealth]")
20
(entity-owner "[entityOwner]")
(range [range])
(x [x])
(y [y])))
At every decision cycle, every unit reevaluates its surroundings. For every entity
within its sight range, the engine asserts a fact like the one above. Except for “x”
and “y”, the fact matches the LHS of both move and attack rules. The “x” and “y” are
the coordinates of the entity relative to the unit (with the unit being the origin), and
are used in the RHS to calculate the final vector of move rules, or to identify the
entity that should be attacked in an attack rule. The engine also asserts tag facts for
every tag the player has placed. The effectiveness of every tag is based on the size
of the tag and the distance between the tag and the current unit.
When the facts asserted match multiple rules, multiple rules fire. In this case, the
precedence discussed earlier is used to determine what action the unit will take. If an
attack rule fires, the unit will attack the entity in the matching fact. If multiple attack
rules fire, the unit will use the first rule that fired to determine what entity to attack.
If no attack rules fire, the system looks for any move rules that fire. If multiple move
rules fire, all of the vectors determined by the firing rules will be used to determine
the final movement vector, as described below. If no move rules fire, the system will
look for tag rules that fire. Again, for multiple tag rules firing, the system will use a
vector sum in the same way it uses it for move rules. If no tag rules fire, or if the
existing tags are ineffective on the unit, the unit will take no action.
As stated earlier, move rules will sum these vectors in the case where multiple rules
fire. For an example, let's consider a second rule:
21
Figure 6, Move Rule Example 2.
Now consider the situation where both Move Rule Example 1 (Figure 5) and Move
Rule Example 2 (Figure 6) match the current surroundings:
Figure 7, Current Surroundings
22
Based on these surroundings, both rules will fire. The vectors from each of the rules
are shown in the dark green. The vectors are summed, and produce the final vector
that the unit will move on, shown in the light green.
Figure 8, Final vector after the vector sum
The rule editor allows players to create new rules, edit existing ones, or delete rules
they do not want to run anymore. Additionally, the players can save and load entire
rule sets, allowing players to preserve their rules, and even share them. See
Appendix B, Using the Rule Editor for more information.
Deficiencies
While the rule system is functional, and could be successfully implemented in a fullscale RTS, it has certain deficiencies. Some of these are easily solvable, and could be
corrected given enough time. Others are more difficult, and would require further
design research. When determining what rules the player should be able to define,
the problem is actually two-fold. First, there is the problem of defining the rule itself.
What should the JESS rule look like? How can we abstract the rule from an
appropriate user interface? Second, there is the problem of generating the
appropriate facts during the game. How can we construct the appropriate fact based
on the unit's surroundings? How can we gather the minimum number of facts while
covering all possible rule matches?
These questions are at the heart of the problem of creating rules with multiple
entities. Currently, each rule is based on the presence of one other entity. However,
23
the player may wish to respond to specific situations where more than one entity is
present. For example, in Figure 9, the player may define a situation where a unit is
being approached by a pincer attack. In this case, the unit should respond as
indicated by retreating. However, in Figure 10, there is a second, similar situation.
Again, there are two units that are equidistant from the player's unit. In this case,
however, the unit may find it more beneficial to approach one of the units to attack
it, as demonstrated in the diagram. The problem lies in determining how we can
abstract these two similar rules in JESS so that when the appropriate facts are
assert, the correct rule fires.
Figure 9. Pincer Attack
Figure 10. Similar to the Pincer Attack,
but different response.
Another problem lies within the fact that the units have no memory. For example,
imagine a unit that may wish to chase another unit. If the unit being chased is able
to duck behind an object, and therefore leave the sight of the chasing unit, the
chasing unit will “forget” about the chased unit and reevaluate its current
surroundings. Ideally, units would not be so easily tricked. One possible solution
would be to allow units to acquire targets that are not in range. As long as nothing
else in its surroundings changes the unit's goal, it would continue to pursue the unit.
Exact implement of this solution would be tricky in terms of balancing when to
continue to pursue a target and when to let it go.
The final deficiency worth mentioning is that the units do not path properly. If a
proper pathing system were implemented, the units would be able to move around
obstacles to reach their destination. Unfortunately, I did not have the time to
24
implement a sophisticated pathing system. A simple, but not very satisfactory,
solution has been implemented to allow units to work their way around obstacles.
The units do not move perfectly along their intended vector. Instead, a little bit of
noise has been added to their intended vector. Additionally, when they collide with
an object, they move perpendicular to their intended vector. A combination of this
perpendicular movement and the vector noise allows the units to work their way
around obstacles. However, they still, more or less, make a beeline for their
destination. If time permitted, the units would use proper pathing techniques to
navigate obstacles.
Lessons Learned, and the Future
First and foremost, far too much time on this project was spent creating the very
basic RTS framework to work within. Future implementations of this project would be
best served on an existing RTS framework, allowing for quick prototyping of some
design concepts. However, I am satisfied with what was accomplished despite this
setback.
The multiple-entity problem is extremely important to further this system. One
possible solution would involve exploring diagram analysis techniques. Time
constraints did not allow me to research the possibilities of this route, but it should
be recognized as a possible solution.
Currently, the game allows for little macro-control over the units. The tag system is
a satisfactory solution, but a more robust system may be desired by players. For
example, the players may choose to draw paths that they want their units to follow.
Another possibility would be to allow players to override the rule system momentarily
and use standard RTS control schemes. This would have to be implemented with
care to guarantee that the player that can use standard RTS control schemes does
not hold some advantage over a player relying on the rules.
Play-testing revealed that the interface is not immediately clear, and requires
explanation. Some of this could be mitigated by adding tool tips to the buttons.
However, ideally, an in-game tutorial should be implemented to guide the player
through the basic controls. Once the interface was explained, most people found it
25
easy to use. Some people expressed interest in being able to fine-tune rules during
game play. One possible solution would be to group rules together. The heads-up
display would then have knobs or sliders that would allow the player to tweak the
parameters of a group of rules. Another option would be to allow the player to have
multiple groups of rules in a rule set that he could quickly enable and disable. So,
when wanting to have an all-out attack, the player could trigger his “all-out attack”
group. If he decides he needs to play conservatively, he could trigger his “defend”
group.
A more robust rule editor should be available outside the game. I envision that the
player would be able to browse through his rules using a filter, to allow him to find
specific rules more quickly. Additionally, the player should be able to set up
situations to test how his rules work in those situations. These advanced features
would allow the player to manage his rule set more easily.
The default rule set I have created is not very robust. The difficulty is determining
how many rules should be defined in the default rule set. If there are too many
rules, the player's creativity may be hindered, and they may be less likely to try to
create their own rule set. If there are not enough rules, the player may have
problems trying to play with an incomplete rule set, or may feel like they have to
create too many rules to have a meaningful rule set. This becomes an even more
difficult issue as the number of unit types increase. The proper balancing of this
would take quite a bit of user testing.
Finally, all the missing features described in the “Limiting the RTS Model” section
should be implemented to get a true feeling of how this system would work with
current RTS expectations. Implementing this system on an existing RTS framework
would be even more telling of the success of the system. I truly believe that if this
system were to be implemented on an established RTS framework, the result would
be a game that would attract both casual and serious gamers.Appendix A.
Screenshots
26
Move Rule Editor
27
Attack Rule Editor
28
Tag Rule
Editor
In Game ScreenshotAppendix B. Using the Rule Editor
Creation of a Move or Attack rule
1. Select “Move” or “Attack” from the new rule drop down box. Click “New Rule”.
29
2. A default rule will load. First, rename this rule. The rule name is limited by JESS
restrictions. It must start with a letter, and contain only letters, numbers,
hyphens (-), and underscores (_).
3. Select the type of unit that this rule applies to. The “generic” icon will apply to all
unit types.
4. Select the health state of the unit. The “any” icon will apply to all health states.
5. Select the type of entity that is in the surroundings. The dark icons indicate
enemy units, while the white icons indicate friendly units.
6. Select the health state of the entity in the surroundings.
7. If this is a move rule, select the vector tool, and draw the vector that the unit
should follow relative to the entity.
8. Select the distance tool and click in the appropriate range that the entity should
be in.
9. Click the “Update Rule” button.
Creation of a Tag Rule
1. Select “Tag” from the new rule drop down box. Click “New Rule”.
2. A default rule will load. Rename the rule as described above.
3. Select the type of unit that this rule applies to.
4. Select the health state of the the unit.
5. Adjust the power slider to indicate how strongly the unit will respond to tags.
6. Click the “Update Rule” button.
Editing an Existing Rule
1. Select the rule from the rule list drop down box.
2. Edit the rule in the same way that the rule was created.
3. Click the “Update Rule” button.
Deleting an Existing Rule
1. Select the rule from the rule list drop down box.
2. Click the “Delete Rule” button.
Saving a Rule Set
1. Click the “Save Rules” button.
2. Choose an appropriate location and name for the file.
30
3. Click “OK”.
Loading a Rule Set
1. Click the “Load Rules” button.
2. Choose a rule set file. By default, it should have the .SGR extension.
Click “OK”.Bibliography
Adams, Ernest. “Designer's Notebook: Casual Versus Core.” Gamasutra. August 1,
2000. http://www.gamasutra.com/features/20000801/adams_01.htm
Cypher, Allen. Watch What I Do: Programming by Demonstration. Cambridge, MA:
MIT Press, 1993.
Holldobler, Bert and Edward O. Wilson. Journey to the Ant: A Story of Scientific
Exploration. Cambridge, MA: Harvard University Press, 1994.
Johnson, Stephen. Emergence. New York: Simon and Schuster, 2001.
Java Expert System Shell (JESS). http://herzberg.ca.sandia.gov/jess/
A.I. Wars. Tactical Neutronics.
Black and White. Lionhead Studios. Electronic Arts, 2001.
Civilization III. Firaxis. Infogrames, 2001.
Command and Conquer. Westwood Studios. Virgin Interactive Entertainment, 1995.
Core Wars.
Homeworld. Relic Entertainment. Sierra Studios, 1999.
Pikmin. Nintendo. Nintendo, 2001.
Robo Rally. Wizards of the Coast, 1994.
Robocode. IBM.
Medieval: Total War. Creative Assembly. Activision, 2002.
Myth: The Fallen Lords. Bungie Studios. Bungie Studios, 1997.
The Sims. Maxis. Electronic Arts, 2000.
SimAnt. Maxis. Maxis, 1991.
SimCity 4. Maxis. Electronic Arts, 2002.
Stratego. Milton Bradley, 1961.
31
Stagecast. Cypher, Allen and David C. Smith, 1994. aka KidSim and Cocoa.
Warcraft III. Blizzard. Blizzard, 2002.
Warhammer 40,000: Dawn of War. Relic Entertainment. THQ, unreleased.
Warlords IV. Infinite Interactive. Ubi Soft, 2003.
32