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!

Moving in an RTS

In this post I will be discussing the theory behind the code in making a unit move from one location to another. This is not meant to be a complete tutorial, nor ground breaking. In fact, it won't even cover basic path finding. However, if you are having problems making a unit move between two points (namely, they move diagonally and then straight along) read on.

Such a seemingly simple thing, moving a unit between two points in a straight line (ignoring path finding as FK will not have path finding) However,I struggled with it for quite some time.

At first, I thought it would be really simple. See if the X co-ordinate of the object is bigger or smaller than the target X co-ordinate. Then, add/subtract the desired speed depending on whether the number is bigger or smaller (with bigger numbers being down and to the right). This works fine if the destination is as much above as it is to the right. However, if the target is not, the unit moves at 45 degrees toward the thing until either the X or Y co-ordinate are in line with the destrination (which ever is sooner) at which point, it moves horizontally/vertically. Apart from looking ridiculous, it is not the quickest way between the two points and so will be incredibly frustrating for the player. But then, if you are the target audience for this post, you knew this already.

[Note: Another problem that you may encounter is that as the unit reaches it's destination, it jumps around it. This is because it is unlikely the player will click on a pixel that your units movement speed goes in to exactly. As a result, you unit will switch between being to the left and to the right of the target. I will explain my solution to this at the end of the post]

I tried a couple of other things that, in hind sight, are long winded amd complicated; I won't bore you with the the details. They ended up working to a point, except when the unit had to move either vertically or horizontally, it would accelerate to near infinite speeds.

The solution I finally settled on, at first seemed too complicated (and for all I know, there might be a better one) It relies on creating a right angled triangle with the destination point, finding the accute angle and creating proportional x/y speeds that add up to make a total (limiting the maximum speed) (See diagram)

Using trigonometry (Soh Cah Toa!) we can find the angle using xDist and yDist (which can be calculated by subtracting the larger x/y co-ordinate from the smaller of the unit and it's destination)

Tan(Angle) = yDist/xDist

Or...

Angle = atan(yDist/xDist) //atan is the inverse of tan, called atan in most programming langauges.

In most programming languages, this will actually give you the answer in radians (a way of numbering angles where pi represents 180 degrees). However, for the sake of simplicity (no PI key on my keyboard!) I will use degrees. You can either convert Angle in to degrees (*180 and then divide by PI) or when I say 90, use PI/2.

Next, we work out how steep the hypotenuse (longest side of the trianlge) needs to be. By doing the angle/90 we can work out what proportions the 2 speeds need to be. If the angle is 90, then we know we want the whole speed to be vertical, whereas 0 needs to give the whole speed as horizontal.

The way I did this was first calculate the Y speed.

ySpeed = (Angle/90)*Speed //where speed is the distance in pixels that you want your unit to cover in one frame.

In this, if the angle is 45, (ie. as far up as it is across) then you get (1/2)*speed resulting in half of your total speed to vertical.

The xSpeed is then calculated by taking the angle from 90 and putting that over 90. In the end, you will get two angles that add up to 90. Therefore, when you put them over 90 as two seperate fractions, they will add up to 1. So, when the two fractions are times by the speed, the two fractions of speed will add up to speed.

The problem with this is it will only work when both values are increasing (ie, the unit is moving right and down) To get around this (and deal with a second problem which I mentioned earlier) when the destination is selected, define two boolean variables to store whether the target is left/right and up/down. Then, when your regular function to move the unit is called, if movingRight == true, if != true, then subtract the number and so on.

I realise that this is a little confusing, so here is a quick summary of what I mean

Summary: By finding out the angle that the destination is from the current position, you can find the preportion that the two speeds need to be.

The final issue is checking when a unit is arriving. By using your movingRight boolean variable, you can simply see whether the unit has passed the X co-ordinate. If movingRight==true then if curX >= targetX then it has arrived. Likewise, if movingRight != true, then curX <= targetX for it to have arrived. And you do not need to check y, as they should happen at the same time.

Here is my C#/XNA code if it is any help: (distASec is a Vector2 which stores the speed, curPosition is a Vector2 which has the units location and currentTarget is a Vector2 which is where the unit is heading. Vector2 is a XNA data type which stores X and Y co-ordinates(as floating point numbers, if your in to that sort of thing!).

if (currentPosition != newTarget)
{
Vector2 totDist;
float refAngle;
currentTarget = newTarget;

//Calcuates total distance and direction
if (currentPosition.position.X < movingright =" true;" x =" currentTarget.position.X">

}
else
{
movingRight = false;
totDist.X = currentPosition.position.X - currentTarget.position.X;

}

if (currentPosition.position.Y < movingdown =" true;" y =" currentTarget.position.Y">

}
else
{
movingDown = false;
totDist.Y = currentPosition.position.Y - currentTarget.position.Y;
}
refAngle = (((float)(Math.Atan((totDist.Y / totDist.X))))*180)/(float)Math.PI;

distASec.Y = (refAngle / 90)*speed;
distASec.X = ((90 - refAngle)/90)*speed;

}

Finally, to check if the unit has arrived.

if((movingRight && currentPosition.position.X >= currentTarget.position.X)(!movingRight && currentPosition.position.X <= currentTarget.position.X))
{

//Code to be excuted upon arrival

}

An interesting premise?

Today I was doing some research for an annoying (read: rubbish) physics homework, why it is rubbish is another story! Basically, we had to research how theories of light had changed through time. However, it was quite interesting reading about ancient (BC times) theories of atoms.

The basic idea is that all things are made up of four atoms (indivisible things, not the modern scientific meaning of an atom, which is entirely divisible): Fire, Water, Earth and Air. Each of these has distinct shapes made up of triangles (not so indivisible then). Now obviously many games have used the idea of four elements before and it is largely just a different reality, usually one with fate, magic spells and goblins.

However, what I am suggesting is, supposing they were correct from a scientific point of view. From this base, work through the whole of Physics, Chemistry and Biology to create a world based on these scientific truths. And to make it a bit more interesting, define a few rules. First, each of these atoms have unique properties that exhibit themselves in whatever they are in. The higher the ratio of them within the molecule, the stronger the effect, but even with one, there would still be some effect. Second, where scientific questions are ones that have been raised before, you use another theory that has also been superseded by something else. For example, if you get to the question of light, take the aether to be correct.

The question is, would this create an interesting and believable alternate world to set your game in, or would it be minor differences that make no difference. Also, can interesting things come out as true, ie. can magic work?

Here are a few ideas I have come up with, I might try to expand this at some point, but working through 2500 years of science without the ability to experiment may take some time!

Earth (prthivı) -Mass: 2, Fluidity: 0, Gravity: 3, Repulsion: 5, Temperature: 3, Temperature Resistance: 5

Fire (tejas) - Mass: 0, Fluidity: 0, Gravity: 0, Repulsion: 0, Temperature: 5, Temperature Resistance: 3

Water (apas) - Mass: 1, Fluidity: 4, Gravity: 1, Repulsion: 1, Temperature: 2, Temperature Resistance: 4

Air (vayu) - Mass: 0, Fluidity: 5, Gravity: 0, Repulsion: 0, Temperature: 1, Temperature Resistance: 2

I'll quickly explain my thinking behind these labels. To find out an objects properties, you add up the figures of its containing elements and divide it by the total number of elements (except with mass, gravity and temperature). The mass of an object is how heavy to pick up. Fluidity is it's ability to stay together. If it's fluidity is greater than the repulsion of the thing surrounding it, then the excess fluidity is converted in to motion. For each point of gravity, the atom can attach to that number of atoms, (note, only requires one of the atoms to have it) Any left over draws objects near it (relative to the total size of the molecule) and a velocity equal to the amount left over. Temperature is the temperature of the object. If an object touches another object and the temperature is greater than the temperature resistance of the other object, the second object is annihilated.

I quite like base rules and working up from them. A once read a description in a game design book (Game Architecture and Design, Andrew Rollings) giving an example of emergent game play. In the example, the players are travelling somewhere (I think it is an MMO, but definitely doesn't exist yet). It is cold and they are going to freeze. All they have on them is something that burns at a very cold temperature. However, one of the players remembers that being in the centre of a flame raises the temperature by a few degrees. Still cold, but enough to keep them alive. This would be taking emergent rules to the extreme.

Sorry for the lack of posting, I have a couple of posts in the works. One on programming a unit to move from one location to another (surprisingly complicated) and the other on planning your project. FK, my current project, has had a couple of good weeks with solid progress being made. I hope to have a working province by the end of February, complete with animations and maybe even a building which actually creates the unit.

The key to good game design

Sorry for not posting much, I have much to post about, but little time in which to do it (as all the time I am feeling constructive I spend on revision!) However, I saw a clever post of GameDev.net that I thought I'd share. You can read the full thread here, not that interesting though!

Anyway, here is the post, the poster describes what he thinks are key to good game design.

1) The game needs to be (or at least *seem*) fair.

2) The player's character/avatar needs to control well and respond in a predictable fashion (this ties into the game being fair).

3) The challenge of the game needs to match the player's skill level (note: no game is going to have the perfect challenge at all times, so this isn't going to always be true until adaptive difficulty is perfected).

4) The player's goals (both long-term and, more importantly, short-term) need to be obvious at all times.

5) The player needs to have clear feedback that allows the player to know at all times how well he is performing at the current task in the game. It's important to note that any negative feedback/punishment that is given to the player should be treated as information and not as mockery. A game with good design never concentrates too much on a player's mistakes. It's best to make the mistake obvious without badgering the player. Games like Bioshock that just automatically restart you without even having a death animation or text that essentially says, "Hey, even though it's completely obvious to you that you just died, I'm going to say it anyway... GAME OVER, LOSER!" have good game design in this respect.

6) The rewards and punishments need to be structured properly. I.e. the player shouldn't be given a huge reward for a trivial task, and the player shouldn't be punished too much for a small mistake (one example of bad design in this regard that I constantly encounter is in platform games where you're in a vertical level traveling upwards, make one bad jump, fall for what seems like 5 minutes, and then start at the very bottom of the level all over again).

Number 5 is quite clever and something I hadn't really thought of. Game Over screens are basically just rubbing something you already knew in your face.

I would add to number four that it also needs to be made clear to the player why they are failing (if they are). For example, in Gear of War 2 in that sequence on the back of the cargo truck type things - I didn't know why I kept failing (I wasn't shooting the mortar fire) It was an incredibly frustrating experience and definitely not fun.

The final thing I would add is that if puzzles/challenges use a new mechanic, should fit with everything that has gone before. Good games lay down the basic rules early and then just interpret them differently. If at the start, the player can't run, this should remain the case and not just be changed when it suits the puzzle.

An Interesting Survey

Recently, a guy posted in the GameDev forums about a survey he was undertaking. He recently posted his results, you can view them here

The findings are very interesting and I highly recommend having a look, some of the results are quite surprising. The survey covered 7 key forum types and, while is by no means a complete demographic of everyone (2 different sections are to do with game content creation and they are all video game related), this is pretty much the target audience of any game that I will make in the next 5 years, so it is highly relevant for me. The survey recived a fairly impressive 1540 responses.

There are a couple of things which are particularly intriguing. Firstly, I am pleased to announce that RTS's are still near the top in popularity (unsurprisingly FPS is the no. 1, especially considering one of the forums is a HL2 one!)

Another result was that most people, unless they play for more than 24hrs, don't play more than for 12. Whether this is because games fail to hold their attention or because that after about 12 hours something else comes along is not clear. Should, as a developer, I use this as a guideline for how long the main portion of my game take to complete, or should I use this as a target? Ie. does it need to be about 12 hours or at least 12 hours.

Another key area of the survey is the "Key Aspects" which is what people want from a game. Unsuprisingly, looking at the list of forums, gameplay is at the top. However, people will inevitably put this, because when you are not playing a game, it is clear that this is what SHOULD matter. I found what came second and third to be more insightful. High up is depth and story. The thing that I personally find imporant, game customisation, was not voted that important. Given the forums, I find this suprising. The story is something I hadn't really considered, as I find that the best stories are player created. Whether people who voted story meant a system that would allow the player to experience their story I don't know, but the implication is not.

As for depth, I think this means things like back story continuity and things to do hours in to the game that you have only just found out about. Depth is somewhat of a buzz word, but ceartinaly something worth considering, as it came so high.

The survey did ask what price would people be prepared to pay for a decent game. The implied meaning of decent is one in which there is reliable evidence that the game will be good and to their taste. A question I would like to see answered is how much would people be prepared to pay for a game which has a less proven record. Not that people said it is bad, as no one wants to pay for something rubbish, but as an Indie developer, what would people be prepared to pay for a game which looks potentially good, but is very much a gamble.

See the results in full