Space games have always been a part of the computer game
industry. From the early days of Space War and X-Trek to the
current hits such as Wing Commander and Master of Orion, players
have embraced the galactic themes. In keeping with the popular
opinion, this article will discuss some of the major design
issues that exist in the space games that have been made so far.
Of course, we can only hope to hit some of the major issues
within the genre. But before the meal, we must have the
appetizers.
Space Game Types
I had a bit of a hard time figuring out what topics to cover.
With a bit of closer examination, I was able to narrow the
choices by identifying what I saw as the three major types of
space games. I categorize them by the focus of the player's
actions. First, we have action flight-sims. Second, we have
galactic empire games. And third, we have
exploration/development games. Each game type is what I see as
a major force within the space game genre.
Action flight-sims are known by the arcade flight combat nature
of the games. These titles are centered on space combat,
usually with ships of some sort. I combine the terms "action"
and "sim" because the flight model is usually an interesting mix
of flight simulator and arcade play. Due to the fact that we
know so little about actual space flight, it's difficult to do
an accurate simulation. Also, it's just more fun to play with a
more forgiving ship! Typical titles in this genre are Wing
Commander, X-Wing, and Privateer.
Galactic empire games are centered more around resource
management and tactical combat. The player has the ability to
create an empire with all of the complications involved.
Managing production, expansion, and even large-scale combat are
all covered. The combat tends to be at the fleet level, and the
pace is usually turn based. Typical titles in this style are
Master of Orion, Deadlock, and Ascendancy.
Exploration/development games are generally the equivalent of
sci-fi role playing games. The action centers on exploring the
galaxy/universe. The development of the player (or the player's
ship) is usually of prime importance. Any combat in these games
is usually very simple. Some sample titles of this style
include Starflight, Star Control 2, and Star Command.
Action Flight Sim Design Tips
Mission, Mission,
Who's Got
the Mission?
Most of these game styles are based around a mission structure.
The player starts out at some location and is then assigned a
mission. The mission can have multiple objectives, but usually
the missions tend to run along the following types: destroy,
protect, scan, and escort. These missions, over a long game,
can seem quite repetitive. However, without some additional
programming, those mission options are all you have to work
with. In order to preserve some sense of originality, the
player's perception must be altered.
Combining the mission goals in single missions, patterning the
missions to not repeat types too closely together, or merely
watching the language that you use in the mission briefings can
create fresh approaches to the standard mission formulae. Often
times, we are stuck with the lack of variety in design (after
all, it is just a game!), but we must realize that in order to
see patterns, players have to be exposed to repetition. It is
through the learning of these patterns that the players will
experience the joy of mastering your game.
I'm Flying!
The flight model is the single most important game play aspect
of this style of game. The player interacts with the game
through the flight model. Certain expectations exist in games
of this sort. Care must be given to establishing a balance
between so-called "realism" and arcade controls. Since space
flight is such an unknown, it is difficult to determine what is
"real." In other words, be sure to avoid throwing in obstacles
to the player's control under the guise of "realism." The
player will most probably have a much more enjoyable experience
if they don't have to spend three weeks learning to control
their craft.
Another aspect of the flight model is figuring out how to cover
distances. Many action flight-sims merely let the player fly
aimlessly through space to get from point A to point B.
Personally, I'm not in favor of this method. Too many hours of
my life have been taken up merely waiting to get within 2000
kilometers of a capital ship. To solve this, we have two
options: start the players within range (unless you plan to have
something happen during the voyage), or allow them the ability
to speed up time. The latter seems to please more people, but
the former makes more sense from a logical standpoint. Why
create large open spaces only to let the player speed through
them?
Contemplate this
on the
Tree of Woe
The mission tree is another widely debated design function. The
mission tree consists of the effects of the player's performance
in a mission. For example, the player may be called upon to
destroy a certain enemy ship. If the player succeeds, the next
mission may be X, whereas if the mission is a failure, the next
mission is Y.
The problem with this structure is that all too often designers
work with a simple success/failure combination to determine the
tree. With the ability to save, players will hardly let a
mission go by without succeeding. Therefore, the designer must
present the player with choices during missions in order to
increase play with tree branching. If the player knows that a
certain choice is "bad," that player will not choose that
choice. If the choices are more ambiguous (and even
intentionally not right or wrong), then the player will be more
likely to explore the entire mission tree. For example, the
mission calls for destroying a certain enemy. However, upon
encountering said enemy, the player is offered a large bribe not
to destroy the enemy. The player then has the option of
pursuing the bribe option to see where the story goes.
Galactic Empire Design Tips
Focus, Daniel-san
When making a game of such a broad scope as the Galactic Empire
Type, the designer must exercise a certain restriction. The
tendency will be to include every possible ability. This
tendency can lead to a confused game. The player will either a)
become confused as to what the game is about, or b) become
frustrated at the length of the learning curve necessary to
learn all of the different parts of the game. In order to avoid
such problems, the game should be focused. Initially, it should
be decided whether the game is centered on resource management,
tactical combat, or planetary/galactic management. Most of the
design time should be put into the central aspect of the game.
The other concepts can be included in the game, but the play
engines used should be much less intensive than the primary
focus. If possible, they should support the primary focus
rather than detract time/effort from it.
For example, if conquering the universe is the focus of your
game, most of the game development should be spent on the combat
engine. If the player spends most of their time micro-managing
the output of their empire, then it would be a shame to see a
well-developed combat engine be under-played. I'm not saying
that a game can't be multi-faceted, but the experienced
developer (as with other arts) learns that form is ultimately
freeing. Kitchen sink designs seldom turn out as expected.
The Art of Galactic Combat
Ok, given what I've just been saying, I feel that usually
galactic empire types are trying to be multi-faceted. Knowing
that, we can address the issue of combat design. Combat usually
ends up being strategic in nature, and usually turn-based. The
reason for this tends to back up my beliefs about focus. Due to
the fact that running an empire tends to be a tricky thing,
combat shouldn't be made too hectic. Thus, turn-based combat
allows for the maximum strategy while at the same time affording
the player time to consider their actions. But what should the
designer consider when determining a combat engine for such a
complex game? I'm glad you asked.
Basically, combat should stress the mode of success that you
favor. If you are keying on production, then numbers should be
the key to combat, and combat should be formed around fighting
with large fleets. If peace and diplomacy are your goal, then
combat should be a difficult process that should discourage the
player from fighting as anything but a last resort. Just
remember what your focus is and the rest should logically
follow.
Galactic Race Relations
Most galactic empire games allow the player to start as some
race. These races often have advantages that make the game
different for each race played. Unfortunately, these races are
usually imbalanced with a few races being played while others
languishing in obscurity. Most of these disparities can be
fixed by remembering the initial assumptions that went into the
design in the first place. Many times, the original designers
realized that food was a critical issue, and they capped food
production for a reason. If a race comes along that produces
food more than the previous cap, then the delicate play balance
has been ruined. The easiest way to solve this problem is to
allow for adequate test programming. Many of the extreme cases
can be determined by creating small programs to hammer on the
variables. Sometimes the problems can only be seen in the
extreme cases.
If the project has multiple designers, then a design bible might
be a good idea. That way, critical assumptions are documented
(along with the repercussions of breaking them). A little
documentation can save many bad reviews in the future. Besides,
you can always show your programmers how good your documentation
is, and it might inspire them to do the same!
Exploration/Development Design Tips
What shall we
use to fill the
empty spaces...
In a game that centers on exploration, it can be hard to keep
the player exploring. Many games, especially space games, tend
to rely too heavily on vast expanses of nothing (well, it is
space, isn't it?) to fill time during exploration. Granted,
space is a big place, but if we should to pay attention to one
of the major influences on all space games: Star Trek.
On Star Trek, his holiness Gene Roddenberry came up with two
devices to keep the plot moving: warp travel and the
transporter. Warp travel allows the Enterprise to travel
incalculable distances in roughly the span of a commercial
break. The transporter allows transit to planets instantly.
Both of these methods prevent the viewer from watching the
boring day-to-day events on a starship (a relative boring, I
realize). Game designers should learn from such methods.
Rather then lengthen game play by allowing autopilot and space
travel, we designers should come up with active events for the
players to cope with. Sure, there may be some relatively
mundane tasks to perform, but the more we can color up the
actions, the better the game. Wormholes, teleporters, and
special planetary/solar system events will keep the players
interested.
Speeding
Round the
Development
Curve
In the development part of the exploration/development style,
there is a curve that can describe how fast a player develops.
Many times, this curve is wacky. For example, in Privateer (I
know, it's not really an exploration/development game, but bear
with me) the player starts off with one type of ship, and other
ships can be bought. The other ships are gradually more
expensive, leading the player to believe that each ship is on a
development curve. However, if the player buys the next best
ship to the starting one, they're worse off than if they had
stayed with the original ship! The curve takes an unexpected
downturn right off the bat. There isn't enough information for
the player to figure this out. Designers should be careful to
make the curve a) relatively steady, and b) relatively
pitfall-free. If the designer is a sadist and chooses to trap
the player, enough information should be made available to the
player to figure out that the trap is set.
Also, money can be a key element in the development curve. Most
games reach a point where money is flowing like water. It's a
safe assumption, but care should be taken so that this
"millionaire" phase isn't reached too soon. Gambling may seem
like a fine idea for the game, but it can be the first route to
early destruction of the development curve. Remember, players
probably have rather limitless time and patience, so anything
that can be exploited, will be.
Plot vs. Freedom
The balance between leading the player through a careful plot
and complete freedom is a difficult one. By the term
"exploration" in exploration/development, we assume that there
will be some amount of freedom in the game. However, as is
learned in many 3D games, too much freedom can be a bad thing.
The player should never feel completely lost as to what to do
next. Several guides should be present to point the player
along the path. If the player chooses to smell the flowers
after being directed, there are two reasons: they don't want to
follow, or they didn't get your hint. Be sure that your
signposts are clear and precise.
Too much plot can be a bad thing as well. Sometimes designers
compose intricate plots and cutscenes and force them on the
player. The player may not actually care about the plot, so it
should never be forced on anyone. Cutscenes should always be
able to be cancelled, and the player shouldn't have to read
pages of story text at any one time. Sometimes, your game play
is enough to entice the player, and they should only be
reminded, never disturbed.
How do you know how to balance plot and freedom? Well, ask
yourself some simple questions: - If I'm enjoying the play, do I
want to be disturbed with lengthy plot elements? - If I'm
lost/bored, how do I know where to go to get back on track? Find
non-intrusive ways of incorporating the plot. That way, the
player can know what's going on. Keep it brief, but be obvious.
Well, I hope you've gotten something from these tips. These
concepts are just the tip of the iceberg when it comes to space
game design, and other questions will undoubtedly come up in the
process. Remember, each game is unique, and it situation should
be treated accordingly. There are no formulae for a good game,
just concepts to be remembered while creating. Sometimes the
game calls for breaking the norm and sometimes it doesn't. As
with any rule, just make sure you know why you're breaking a
rule before you break it. Good designing!