The general design of Solar Realms Elite (SRE) isn’t something I came up with. At an early age I had played with David Ahl’s Computer Basic Games[1], which taught me simple game design, tradeoffs, feedback loops, economics, and combat calculations. Of those games, King[2] and its simpler version Hammurabi[3] were my favorites: games about managing a kingdom, in which you manage the budget, food, immigration, tourism, mining, and pollution. Hammurabi was based on an earlier game called The Sumerian Game[4] from 1964. Hammurabi had some surprising strategies[5], most of which I never discovered. You can now play these games in your browser[6].
Years later there was a game my brother played on the Atari ST machines, called “Space Empire Elite[7]”, that followed the same pattern as Hammurabi and King, but was set in space, with many more game options, and multiple players. SRE started out as a clone of Jon Radoff’s SEE, using space and planets, except SRE ran on IBM PC systems, and the gameplay was heavily influenced by my experiences with Hammurabi and King, as well as Fur Trader[8] (economics, trading), Civil War[9] (combat calculations, Lanchester equations), Combat[10] (multi-round combat calculations), and other games I had played. After that, SRE grew in its own direction. After I wrote SRE, my brother Mehul wrote an SRE-like game called Alpha Colony IV (AC6), then BRE, Falcon’s Eye, The Arcadian Legends, and Earth:2025, which led to Utopia[11].
I have collected some design notes that are from email I’ve exchanged with SRE fans over the years. This may be useful if you want to write an SRE clone.
Planet Design
In Space Empire Elite (one of the inspirations for SRE), there were three planet types that I remember: Ore planets gave you money, Food planets gave you food, and Soldier planets gave you soldiers. With money you paid for planets and soldiers, with food you fed your soldiers and population, and with soldiers you could conquer neighboring planets and also defend against attacks. I wanted to play with feedback loops so I designed a different set of planets:
- Ore planets produced a steady amount of money. A good, safe bet. A boring strategy.
- Tourism planets produced money, but it varied over time. Not only was there variation every turn, but there was also variation based on the state of your empire. In good times they produced lots more money than Ore planets, but in bad times they produced a lot less than Ore. This led to an interesting tradeoff. Tourism would allow you to grow more quickly but there was a high risk of failure. After you were attacked, not only was your money supply raided, but tourists wouldn’t visit you for some time, so your means of earning money was also damaged. With Ore planets, you’d grow more slowly, but you’d be able to better recover from an attack, because you’d earn the full amount per turn. When a new game starts, it’s a race to grow faster than everyone else, so Tourism was the best bet, but later, when you had more you had to lose, it’s useful to have Ore as an insurance policy.
- Petroleum planets produced money, but it varied based on how many other people were pursuing this strategy. If there were lots of Petroleum planets, the price of petroleum would drop, and this strategy would be less useful. If nobody pursued the strategy, the price would be high, and thus people would want to get Petroleum planets. If you found someone whose income derived largely from Petroleum planets, you could hurt them by buying up lots of your own Petroleum planets, and drive their income down. This meant Petroleum planets were more risky, and as a result the income from them was often higher than for Tourism.
- Urban and Education planets increased population. Taxing the population produced money. Since you have to wait for people to arrive, this source of money is delayed compared to other planet types. Urban planets increased population in proportion to the current population. This would lead to exponential growth (deaths and emigration kept it in check). Education planets increased population in proportion to how many Education planets you had. This would lead to linear growth. When your population is small, Education works better; as the population grows you want to switch to Urban. There’s also some fun with tax rates: you can lower the tax rates, get lots of people to come to your empire, then raise the tax rates again.
These four approaches to making money, based on risk/reward, supply/demand, and delayed linear/exponential feedback, led to a good mix of strategies in use, both within a player’s empire and across empires. Each strategy also had a weakness. Ore is easy to outproduce; tourism is sensitive to attacks; petroleum is sensitive to the number of planets out there; population needs food, which can be poisoned through covert attacks; in a diversified portfolio your population and tourism are hurt by the pollution from petroleum. To get to this point though took a year of simulation, feedback from players, and lots of observations of what people actually do while playing. Feedback systems are complex and hard to balance.
Inflationary Mode and Markets
SRE has two different ways of computing prices. In “inflationary mode” (which was the original way it was written), prices go up depending on your net worth, and also somewhat depending on how much of that item you already own. There were several gameplay problems with this approach:
- Lump Purchases
If you bought a whole lot at the same time, you could buy more than if you bought some each turn.
This would lead to people saving up money for days or weeks, and then buying a lot at once. BRE “solved” this problem by not giving you a price on planets (regions) until you specified how many you wanted. If you bought a lot, then the price of the last one would be higher than the price of the first one. BRE didn’t have a solution for non-planets, and SRE didn’t have a solution for any of them.
- Influencing the Market
If you had a LOT of money you could play with the prices. For example, you could buy 1,000,000 soldiers, and then the next turn the prices would go up. You could then sell those soldiers for more than what you paid for them! (You could also do this with the food market in early versions of SRE, but I changed the food pricing system later.)
- Financing Partners
A large empire and a small empire could team up. The small empire would buy things and trade them with the large empire. The large empire ended up getting things for a very low price, defeating the entire pricing system.
One thing that could reduce this problem is to tax trading. I think BRE did this, and SRE might have as well, by having some cost of shipping.
I then introduced a “non-inflationary” pricing system, which wasn’t too popular. In it, prices stayed fairly constant, but maintenance went up as your net worth went up. (I believe I multiplied by some constant plus the logarithm of the empire net worth.) The result was that you could keep buying things but you couldn’t afford to keep them. The strategies with this approach were quite different than with the inflationary pricing. Instead of trying to buy things for low prices (either all at once, or through another empire), you needed to keep defenses but no offenses, until the time you wanted to attack. I think many players who had developed strategies for the inflationary prices were unhappy that their strategies didn’t work anymore, but many newer players were able to find good strategies in the non-inflationary system.
One thing Mehul and I thought about was having prices determined by a market similar to the food market, instead of setting prices depending on your ability to pay. I think he might have experimented with this in BRE.
Food prices were determined originally by looking at how much was in the food market, and setting a high price if there was very little and a low price if there was a lot. Later on I made the food price depend on the sum of the food in the market and the food held by the player. Without this change, you could buy all the food in the market, drive the prices up, then sell it all back, driving prices down, buy it again, sell again, and so on.
Turn Based Systems
Turns are tricky. If you’re thinking about an Internet based game where people from all different time zones play, you might want to rethink the turn system. A “day” in local time no longer makes sense. Also, when you have many users online at once, you have to address at least two issues:
- What if all or most of the users have taken their turns for the “day”? Should you let them advance to the next day? If so, how many people have to have taken their turn before you’ll let the entire game proceed?
- What happens if you’re using some resource, and someone attacks you and takes them away from you? For example, what if you’re typing in the command to sell 5000 soldiers, and at the same time you’re being attacked, and you lose 4000 of those soldiers?
Think about how the balance between users who take their turn every 60 minutes (24 turns a day) and users who take their turns every day (5 turns a day) will be. One possibility that will even things out is to award income/production throughout the day. So even if the player isn’t logged on, they continue to build up wealth and other resources (mostly military). In addition, feeding and paying the population would be automatic, throughout the day. And then their turns do NOT involve earning money, but instead they are just performing offensive actions. So you might receive one turn every 60 minutes, with a limit of 10, and then you can perform that many actions (covert operation, attack, etc.). You’d be able to buy/sell items at any time, whether you have turns or not. It’s quite a change from the turn based SRE, but it may be more appropriate when you have multiple users playing during the day.
For attacks, you may want to have each offensive action take some time to complete. In SRE, when you attacked someone, that attack was immediate, and you could use the gained resources in your next turn. But perhaps the attack takes 60 minutes to perform (preparation and transit time). So you’d launch an attack, and you’d log on the next day (or perhaps in just 60 minutes) to see the results. One advantage of this scheme is that you get into a big tradeoff—do you send ALL your troops out to battle? Certainly not! During those 60 minutes, your home planets would be defenseless. So you have to carefully decide how much of your forces you want to send out. The disadvantage is that sending out attacks is less fun because the reward is not immediate, and you cannot effectively use all 5 turns to perform the same action. (You instead want to perform several different actions.)
Costs and Production
The price for the Petroleum planets depended on the ratio of all petroleum planets to all planets in the galaxy; when the ratio was 1:10, the petroleum planets were roughly equivalent to Ore planets.
(Contributed by Jeramie H) Soldiers eat 1 megaton per 33 soldiers, and their maintenance cost is 5 credits per soldier. Fighters maintenance cost is 8, stations are 8, and cruisers are 12; they don’t eat either. Everything else in the army doesn’t have a maintenance cost, nor eat.
Amit notes that these figures depend on the mode of the game (inflationary/non-inflationary) and the size of your empire, but they can serve as a rough guide.
(Contributed by Jeramie H) Maintenance starts at 980 credits per planet and builds 1 credit per planet per turn.
Amit notes that these also depend on the mode of the game and the size of your empire. In the “inflationary” mode of SRE, the maintenance cost was fixed at 1000 credits/planet, and then it was affected by random variations. In the “non-inflationary” version of the game, the maintenance cost started out low and went up as you got more planets. For the purchase prices, in the “inflationary” version, the prices would go up depending on your net worth and how much you already owned of an item. For the “non-inflationary” version, the prices would stay relatively constant, I think.
In general, the “inflationary” version would increase the prices to buy new things, and the “non-inflationary” version would increase the maintenance cost. I think for game balance, the non-inflationary version was better, since it made it harder on large empires, no matter whether they bought their army / planets or conquered them from others. (There are many games that give you harder levels as you progress. For example, in DOOM, you have to fight stronger monsters in higher levels. If the game didn’t get harder, it wouldn’t be so much fun! :-) )
(Contributed by Jeramie H) Food planets produce 46-54 megatons/turn, with a standard gaussian distribution.
Amit confirms that the food distribution is gaussian, and notes that production can be increased by Research and decreased by civil unrest.
Each planet type had two numbers associated with it that controlled “production”. For ore and tourism planets it was credits/year; for food planets it was megatons/year; for anti-pollution planets it was pollution reduction/year. Urban and education planets had as their “production” a constant that was used in the formula for immigration and births. Research production was the number of research points per turn, and supply planets had soldiers/turn. For some planet types, like government and petroleum, there was no effect.
The first number was the long-term amount. For example, with food planets, you might set the long term amount to 50 megatons/turn. The second number was the short-term amount. At first, it would also be set to the same value. However, some research discoveries would temporarily boost your production, and that would merely alter the short-term amount. Some discoveries would permanently boost your production, and that would affect the long-term amount. (There’s a text file somewhere in the distribution that lists some of the research effects, and whether they are permanent or temporary.)
The production each turn would be determined solely by the short-term value. Each turn, the short-term value would be moved slightly closer to the long-term value. I think it was changed by 10% of the difference, rounded up, so if the long-term food production was 50 and the short-term production was 30 (due to drought, perhaps), then the difference is 20, so the short-term would be adjusted by 10% of that, or 2. The next turn it’d be adjusted by 10% of 18 (rounded up to 2), then 10% of 16 (or 2), then 10% of 14 (or 2), ..., 10% of 8 (or 1), etc.
I tried to avoid giving permanent boosts, and I also tended to give either small permanent boosts or large temporary changes.
I have found a posting I made many years ago about game balance and the finances of small vs. large empires.
Warfare
BRE’s warfare formulas are somewhat different from SRE’s. SRE was built to support long-term game play, while BRE was designed to be a faster paced game.
SRE did something pretty simple, but it seemed to work okay. There were a number of rounds of battle, and in each round, each of the two sides attacked each of the three groups (soldiers, defense stations, cruisers) of the opponent. The effectiveness of each combination was different. It was something like this:
attack strength = 3*soldiers + 1*fighters + 2*cruisers
defense strength = 10*soldiers
... attack soldiers ...
attack strength = 1*soldiers + 4*fighters + 2*cruisers
defense strength = 25*defense stations
... attack defense stations ...
attack strength = 1*soldiers + 1*fighters + 10*cruisers
defense strength = 15*cruisers
... attack heavy cruisers ...
(I made up those numbers; I haven’t seen the source code for many years so I don’t really remember the details.)
The soldiers were best against soldiers; fighters were best against defense stations; and heavy cruisers were best against heavy cruisers. The idea was that there was no one “best” type—you had to study your opponent (with spies) to determine how best to attack him.
I think the general idea that no one military type was “best” is good for game balance, but I don’t think the way I did battles was the best way.
I was influenced somewhat by Lanchester’s Equations. These were developed in World War I to model battles. The result is that strong empires are stronger than their numbers suggest. Lanchester’s Square Law stated that the effectiveness of the army was proportional to the square of the army size. This is bad for game balance.
I created Guerilla attacks to address this problem. In the Conventional attacks, your damage is proportional to the size of your army. In the Guerilla attacks, your damage is proportional to the size of their army. The small empire’s strategy therefore is to use Guerilla attacks to weaken the enemy; the large empire’s strategy is to use Conventional attacks to defeat and loot the small empire.
The rewards from Conventional attacks were also an equalizing force. The large empire will win more battles, but the rewards are smaller (relative to the size of the empire). The small empire rarely wins, but the rewards are large.
Nuclear and Chemical attacks were more alternatives to Conventional. However, if you used them too many times, the Galactic Coordinator would be unhappy with you. (I think in practice that meant you would receive fewer funds from it.)
Population
There was a lot of randomness in how may people came to, left, were born in, and died in your empire. The two biggest factors were:
More Urban planets ==> more people are born
More Education planets ==> more people immigrate
The Urban planets generated births/deaths dependent on the total population, and the Education planets generated immigrants/emmigrants independent of the total population. I think emmigration also depended on what your people thought of you. As a result, if your population was small, Education was better, but if your population was large, Urban was better. (I don’t, however, remember the numbers that made those formulas work out well—it’ll take trial and error to come up with them again.)
Lottery
There were several lottery scheme I played with over the years. The one I remember most is that there’s a fixed amount of money placed in the jackpot at the start. Every ticket you buy would increase the jackpot by an amount smaller than the cost of the ticket. So for example, if you bought a ticket for 5000 credits, 4500 of it might go into the jackpot. (I don’t remember the exact numbers.) The next day the system would pick a random ticket out of all the tickets bought, and it would award the jackpot to that player.
I put in an initial jackpot because it’s an incentive to the first player to play the lottery. Otherwise, that first player would see the jackpot is zero and would not play. You need something to get the game going. Then, I did not add the full ticket price to the jackpot, because if the lottery is really popular, I wanted the “house” (Galactic Coordinator) to profit from it.
So you see there’s a form of negative feedback here. (I use negative feedback a lot in SRE.) When the number of lottery tickets is low, the expected payout is high. The first player sees a jackpot of 3,000,000 credits and pays 5,000 credits for a ticket. Unless more players join, that first player wins a lot. This high prize is an incentive for players to buy lottery tickets. When the number of lottery tickets is high, the expected payoff is low (because each additional lottery ticket increases the jackpot by less than the cost of the ticket). So the low payoff is an incentive for players to stop buying lottery tickets. The end result is that you end up with some balance in between the extremes.
The other fun part about the lottery (and petroleum planets) is that you have to take in account local vs. global payoff. Each player may benefit by buying one more lottery ticket (or one more petroleum planet), but the overall payoff goes down. The balance for the individual player may be at a different point than the global balance. As a result, the game is more interesting. :-)
Bank
The Solar Bank was one of the few parts of the game that gained features when you registered the game. I believe the interest rate for loans depended on how many people had taken loans. If lots of people took loans, then loans must be valuable, so the interest rate would go up.
One trick that people used was to store their money in Galactic Bonds. That way, there was no money in your account, and anyone who attacked you couldn’t get your money. The Covert “Take Hostages” option also wasn’t terribly useful against an empire that had hidden its money in bonds.
Implementation
It took about two months to create the initial version (0.23). The rest was created over a period of four years, but I was not working on it full time. Of the original core, I think half was interfacing with BBS software and the modem, and the other half was the game. I released the source code to the first half, but not to the game itself. As time went on, the game got bigger and bigger, and the core door game code was a smaller portion. :-) The final source code was around 35,000 lines, and of that I think under 10,000 was the core modem/BBS code. However, the core also included some things like a fancy I/O (including support for ANSI color, text and numeric input).
I don’t remember particular numbers I used, partly because it’s been so long, and also partly because I adjusted them from version to version. What I would do is watch what people would do. If soldiers weren’t being used, then I figured that they were too expensive in some way, so I would lower their cost, increase their effectiveness, or reduce the maintenance. That way, the next version would be more “balanced”.