Game Design Decision

My first game design problem of the new year is an interesting one, and a pretty typical one. It's a good example of the stuff I think about when making games, and maybe my still-incomplete thinking on the subject will be a good example of how I try to solve these problems.

In Aurora, players have one "building" (in RTS terms), which is called a Sun and which periodically spits out troops that can be used to attack or can be sacrificed to build or upgrade a Sun. There is a small, finite number of spots on which a player can build new Suns. When a Sun is upgraded, it starts to produce more valuable troops. Suns exist at some level from 1 to 5 and produce troops of corresponding strength. The strength of a troop matters during upgrading, so if an upgrade "costs 100", you need 100 level-1 troops or 20 level-5 troops (or some other combination that adds up correctly).

So here's the question: how much should it cost to upgrade a Sun to its next level? Upgrading is a very important mechanic, since it can make a Sun up to five times more useful than it starts. I'm considering three options right now. First, all upgrades could cost some static number, like 100. Second, all upgrades could cost some number times the current level of the Sun, so building a new Sun could cost 100, upgrading it the first time could cost 200, and then 300, etc. until the maximum. Third, the cost of upgrades for all suns could increase universally, so that the first upgrade on any Sun could cost 100, then the player's next upgrade (even on a different Sun) could cost 200, etc. Meanwhile, the cost of building new Suns would stay low and constant.

My thoughts on the pros and cons of each system:

1. Static Cost
The maximum rate of upgrading accelerates, quickening the pace of the game. The player can get as much advantage out of upgrading a Sun as building a new one. Since some Suns will be better defended than others, this encourages the player to upgrade the best-defended Suns rather than expand. Players will expand slower and upgrade more, and the game space will be marked by some very valuable Suns.

2. Increasing Cost
The maximum rate of upgrading is more stable. The player can get more advantage out of building a new Sun than upgrading any. If determined to upgrade, the player is encouraged to upgrade the weakest, lowest-level Suns first before making any especially strong ones. The strategic terrain is therefore more flat, but expansion is encouraged, and so conflict may be more common.

3. Universally Increasing Cost
The maximum rate of upgrading remains totally constant. The player can get much more advantage out of building a new Sun than upgrading any. Upgrading eventually becomes so expensive that attack is more advantageous than investment, since a new Sun can be built on the remains of the enemy's. Since the location of an upgrade doesn't affect its cost, the layout of high-level Suns will be varied, like option #1.

Option 1 incentivizes a lot of quick upgrading. Option 2 incentivizes expansion and then "flat" upgrading (where upgrading is spread evenly across Suns). Option 3 incentivizes quick early upgrades (maybe, depending on starting cost) and then attacks to conquer new territory. I still don't think I understand the "feel" of these different systems.

If any one player is quicker at the start of the game than others, Option 1 ensures that that player will dominate the game before combat even starts due to the accelerating growth. I dislike games in which the outcome is decided before you even meet your opponent; it becomes a simple race or test of mouse dexterity. And yet, Option 1 offers the intriguing possibility of being able to come back from behind after some well-timed upgrading investment.

I'm bothered by the prospect of a "flat" game terrain with Option 2. I like having some targets be more appealing than others since it introduces tactics like blitzing a poorly-defended but high-level Sun. Encouraging conflict is good, but this game might not need it if I'm going for a more cerebral feel.

Option 3 introduces an interesting player decision of determining when it is more advantageous to attack an enemy than continue upgrading. And after all, interesting player decisions are what this is all about. The big negative to this system is that it slows down the pace of upgrading over time, and I worry about what that might do to the game's interest curve. But, then, maybe a stable rate of production combined with an incentive to attack would make the game more exciting in its later stages.

And there are, of course, other considerations at play. Game performance would be better with a system that encourages fewer, stronger Suns and troops, like Option 1, and that option would also allow a constant cost and therefore a simpler UI.

Right now I'm leaning towards a static cost system (Option 1).

Aurora

It's about time for an official introduction to this game.

First of all, it's very much inspired by Dyson (which was evidently renamed Eufloria). Dyson is (was?) a slow, relaxing RTS that boiled the genre down to some essential elements. Your troops are your spending resources. You can spend troops to either add static defenses or increase troop production. Certain locations in the game were more valuable than others for production. These are really basic elements that combine into tactically interesting choices. Elegant complexity from simple parts. An ideal of game design!

In Aurora, I'm trying to strip down the genre even more. Defensive upgrades are gone. All locations produce troops of the same strength before upgrades. Combat is a simple matter of mutual annihilation. I'm also trying to see if I can make it work without an exploration element, i.e. all enemies in Aurora are visible from the start. It may be impossible to include this and still keep it a game of strategy rather than memorization and mouse dexterity. We'll see.

I wanted to recapture the feeling of moving large bodies of troops across the field of battle. In Dyson, your troops moved from point to point in an orderly line. I like seeing my soldiers clashing in a wider battle, or moving out to intercept the enemy. Aurora encloses the battlefield, but your troops can move anywhere within that space.

The visual style is far from complete, but I'm trying to use abstract space-imagery. Troop production buildings look like suns. Troops look like tiny stars: points of light floating on a black background. I'd like everything to move smoothly, even gracefully, until the climactic moment of destruction. I'm also trying to add a synchronized-music aspect to the game, where the soundtrack and game actions compromise just enough to sync up in an entertaining way. Hopefully it will make music out of the game's events.

Right now I'm adding in the first bits of AI. The game will be playable after that. Hooray alpha!

Here's what it looks like right now. No laughing.

Aaaaand I'm Back

Just got back from a trip to Spain, Morocco, Ghana, South Africa, Mauritius, India, Vietnam, China, Japan, and Hawaii. It was pretty crazy. I'm also pretty sure it will make me a better game developer, if only because I learned and saw a lot of interesting stuff.

I had a lot of time on the ship in between ports and made good progress on Aurora, the stripped-down RTS I wrote about earlier. All the basic systems are complete, except for a decent AI. The code (which was wholly rewritten at one point) is clean and in good shape to expand. At one point I was really worried about performance issues. I think I've got it in a good spot now, though. Each army can have a lot of troops floating around, and it's only when several hundred converge in battle that things get choppy. We'll see if that ever becomes a problem.

I'm also seriously planning to spend a weekend revising Azure. The text idea didn't turn out as well as I'd hoped, and the game gets boring pretty quickly. I'm thinking that if I add another handful of patterns of movement for the player to follow, the game might remain as engaging and hypnotizing as I want it to be. The game could switch between them in random order after every minute or so of success.

I also really want to get MUTE up to speed... sigh. So much to do!

World Travel

In an attempt to make myself into a more interesting person, I've embarked on a journey around the world. I'm spending this fall in the Semester at Sea study abroad program, so please forgive the lack of posts on this blog until early next year. Right now, I'm typing from Cadiz, Spain.

I'm equipped with an underpowered netbook for the voyage, but that's enough for me to continue programming in-between the ports. I ultimately passed over the revisions I ought to make in favor of building a new game. The working title is Aurora; it's an RTS stripped down to its essential elements, inspired by the indie RTS Dyson. I'm hoping to have it totally finished by the time I get home.

2nd Place

I'm the first loser of the 2009 Imagine Cup Game Development competition!

But seriously, I'm very excited and proud. This is a thrilling victory.

More about the IC.

Now I'm trying to figure out my next project. I still need to start getting my hands on some commercial game engines, but there are a lot of other things I want to do. For a school project last term I built the prototype of MUTE, and it would be nice to flesh that out and write some significant content for it. I'm also considering revising Alternex (I got a lot of good suggestions at the Imagine Cup) and maybe submitting it to the IGF. Plus, I really want to iterate on Azure; I think it could do better if I had multiple levels and dropped the text.

Decisions, decisions...