Developer Quest Magazine
Space Simulations:
Above & Beyond

Issue One of Developer Quest™Magazine

 

Brought to you by our sponsors

Space Game Design Tips

by Joe Sislow, Designer Mad Opal, Inc.
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!

Copyright © 1998, 1999, Hartman Enterprises Limited. All rights reserved.
Developer Quest Magazine and DQuest are trademarks of Hartman Enterprises Limited.