Dynamic economies in games

Before reading this post on how dynamic economies can work within games, I recommend reading Soren Johnsons post on Game Economics.

The Problem
Due to the international credit crisis, stories about our worlds economics going wrong are rife. More relevantly there was a case in Eve Online. You can read more about it on the BBC website but it basically involved some viscous back stabbing on the part of some players. I bring this up for two reasons. Firstly, Eve is a game which is heavily focused around a dynamic economy. However this story demonstrates both the pros and cons of a manipulatable economy. This Sandbox environment allows for cool, real life things, to happen. This keeps the game fresh and interesting. However, this comes with its downsides. While some people may have loved this twist in the galaxy, many players will have had there experiences ruined by 2 people who they probably don't know.

While this isn't exactly synonymous with dynamic economies, particularly in single player, the problems are certainly similar. Even in a single player game, a dynamic closed economy can bottom out. A closed economy is one which everything remains inside the system and nothing can be added.

This is actually less common than you might think. Take any RPG, drops from monsters are being created when you kill them. In an otherwise closed economy, this will create hyper-inflation as you sell all the excess items you find, so you have more money to spend, so prices rise etc.

However, even if you create a completely closed economy, you will hit problems. For example, in an RTS, most resources are finite, so the system is closed. At the start of the game, this can make for interesting trading; if you are fortunate enough to start next to lots of stone, you can trade it for wood. However, as the game goes on, supply will out-pace demand as other constraints come in to play, namely managing your troops. This causes the market to drop out with everything becoming worthless.

Advantages of a dynamic economy
All this adds up to is, if you include a dynamic economy, you need to think carefully about a lot of things. Obviously, the reward is a dynamic game that features an extra layer of strategy. One of the main things that makes Civ 4 so re-playable is the different strategies that are available to you. Even the different victory conditions can all be broken down in to different ways of achieving them. A dynamic economy can become one of these ways; cripple the persons economy, then you can easily walk over them.

Sins of a Solar Empire (a game which I will be mentioning a lot on this blog as in some ways [not setting] Sins is very similar to Frozen Kangaroo and there are many lessons to be learnt from it, both in its successes and failures) features a dynamic economy involving the buying and selling of resources. It doesn't immediately suffer from the above problems, but rather another thing that you need to consider when including an economy in to your game.

Distractions can destroy economy
Unless your game is entirely focused around the economy, then it is likely to be a small part of some other strategy. The problem with Sins isn't an economic one, but a game design one. To read the economy requires careful injections and extractions of resources to raise and lower the price. You have multiple options for buying and selling. However, you simply don't have time to figure out how it works. You are expected to do this whilst managing your fleet, your empire, your technology and your diplomacy. As a result, despite the fact it is quite cool, it slips down your list of priorities as the reward is simply not worth the time investment.

What are the solutions to this? The first solution is to strip everything else out of the game, leaving only the economy. Obviously, this is not viable for Sins, the focus of the game is epic space battles.

However, that doesn't mean that an economically focused game can't work. I read an interesting post on Gamedev.net about why all our games seem to be focused around violence or fighting. Part of it is certainly down to the human need to feel like we are winning. However, that does not mean that an economy driven game can't do that. Possibilities include either having to bankrupt your enemy, or, if you want to keep the war aspect, have a "war" being fought with you only managing the economy. Cornering resources secures you battlefield advantages etc. While you don't manage the battles, they are almost entirely play out as a result of your actions (the last thing you want is for your actions the feel irrelevant)

The other solution is what I hope to implement in Frozen Kangaroo; automation. In some ways, this does not solve the problem; the fun is playing the economy and seeing the results. As a result, in Frozen Kangaroo it will be everything else that is more automated. While I describe Frozen Kangaroo as a real time strategy game, it is heavily focused on management and logistics of a war. As a result, I think that it is right to allow a greater focus on the economy. I'll be posting more about what the economic element is in Frozen Kangaroo soon.

Conclusion
Back to my original point: can dynamic economies in games work. The short answer is yes. However, you must consider a number of different things. The first one is one you should ask yourself every time you add anything to your game, does it fit with what already exists and does it improve the enjoyment? If you can't confidentially say yes to both questions, chances are you are putting it in because it sounds quite cool.

Next, you must asses whether the player will have enough time, and the reward great enough, to actually use it. If you think it passes these stages, then an economy can work in your game. Only then do you need to start working how keep the economy balanced and interesting throughout the duration of your game. Play testing is the key to this.

And finally, a "realistic" economy is not necessarily a fun economy, our economy is realistic, is unemployment or very expensive oil fun for anyone?

Go With the Flow

Sorry for the lack of posts recently, I have been busy with my review(!) copy of Dawn of War 2. You can read my review here.

Anyway, I had a game idea a while back that I think has some potential. Building on the success of many rhythm games and combining it with one of my favourite genres, I came up with: "Go with the Flow".

You start off with a simple platformer. In this platformer, the map is constantly moving and you must use your 4 commands to avoid obstacles. These four commands are jump, duck (slide if you keep it held down) spin and moues grind (I'll explain in a second). Once you have built this, speed up the movement of the map so it is unplayable without lengthy memorization of the entire course, sounds terrible doesn't it?

Then, you add the music. In theory it should work for any song. You craft the map around the song. The map is moving to fast for the players to play it blind, or deaf in this case. Instead, they must get in to the rhythm of the music and predict what they are going to have to do.

This is probably the tripping point of the game. It is all very well if the programmer knows why he put such a block in, but the game will become very frustrating if you have to keep repeating the level to learn its foibles.

The solution, at least in theory, is to stick to a logical implementation. If the note goes up, jump, if it is a low note, use down. Spin on beats .

However, the second problem comes in two forms. Firstly, if you picture a jump animation, can you see the character landing before the next beat? And what if it is more extreme, with continuous variation?

That is where the mouse grinding comes in. With continuous change in pitch, such as during a guitar solo, the user would use the mouse to keep the character in a broad path (that would rise and fall with pitch)

Obviously, the best way to see if this idea would work (and be fun) is to implement a level. This is what I aim to do if I get time during the next month. The problem is, the platformer element needs to be really smooth. Having played Guitar Hero, there is nothing more frustrating that when the game lets you down. The last thing you want is some dodgy hit testing!

In the mean time, I will post this idea on Gamedev.net and see what they think about it. Feel free to post your thoughts in the comments below.

London Global Game Jam 2009

Last weekend, I took part in an event called the "Global Game Jam" in London. As the name suggests, it was part of a much wider, global event. Basically, you go along, teamed up with some people and then have 48 hours to make a game. This time includes time for sleeping (heh! like anyone did any of that) eating etc. Despite this, the quality of the games produced was incredible. It was a truly fantastic event and I am so pleased I went along, everyone was nice and incredibly talented.

Here is how it went:

Day 1 (Friday)
We arrive and meet up. There is a lot of expensive equipment just lying about, it was stunning. There were TVs, 360's, piano/keyboards and obviously hundreds of laptops. I have no idea how these people got this stuff here on the tube. We then received a couple of interesting key note speeches. The key message: Keep it simple! I have (some what embarrassingly) forgotten the names of both the speakers. One worked in a game development company where he programs console games. The second speaker talked about quick turn arounds and then admitted that "quick" normally meant three weeks rather than 48 hours!

Then we got a third keynote speech delivered by the wonders of Youtube. The speaker was Kyle Gabler who created the successful indie game World of Goo.


Then, we were given the restrictions and theme for our game. These were:

1. A complete round must last no longer than 5 minutes
2. Your game should use this theme: "While we were together, there shall always be problems"
3. Your game should use on of these three adjectives: "Grow", "Hurry" or "In-between".
   

Then it was discussing ideas. This was possibly my favourite part as it really was just a crazy brainstorm. Looking back at out post-stick notes later, it was difficult to believe that we didn't have a completely disjointed conversation.
In the end we settled on a fish based game. I would like to point out, for my egos sake, that it was me that originally, right at the start, suggested the idea of a chain linking two things together. None the less, most of the credit for our idea goes to Yanhua, an undergraduate at Metropolitan University of London. From there, Jon, our genius programmer, showed us some actionscript physics type thing which was awesome, and we went from there.

Day 2 (Saturday)
Day two was largely spent programming away. Or in Chris's case, our musician, coming up with the amazing sound you find in our game. His trust worthy bucket and him spent many an hour recording sound effects to give the impression of the tranquil underwater. We also prototyped some of our sea creatures - in plasticine!


Day 3(Sunday)
Crunch day. What was really frustrating was at about 2 o'clock, Jon had got the game pretty much working. Then, in an attempt to do some minor change, he some how managed to break some other, unrelated, thing (so often the way with programming). In the end, the three o'clock deadline was a bit of an anti-climax. The upload failed (and did for a number of people) So, we carried on working on it till about 4. Then we watched, demonstrated and played the games. I videoed the demonstrations of all the games (except one - I ran out of memory) My personal favourite was a game called "MA", built in Unity (a 3D game making bit of software costing £A,Lot). In essence, it was a maze game. The clever part was, you couldn't actually see the walls of the maze at all. Instead, you had little particles which you could send out which would bounce off the walls. I liked it because it was a neat mechanic and it just worked really well. Anyway, here are the videos:


I strongly recommend that you check out these games (especially ours - the Deep) If you can't be bothered to download the zip, you can also view it here. You may want to restore your web browser, it can be quite processor intensive (there is a lot of physics going on!)

Finally, just want to say a huge thank you to all my team, you guys were awesome! It was amazing to be in such a talented and nice team, thanks for letting me get involved. I hope all of you do it next year. If you didn't do the Global Game Jam this year, make sure to do it next year. It doesn't matter what you do or even how good you are, come along it is great fun and you will meet some really cool people!

Until next time Game Jammers!