Continuing Iranon's Quest

Memorable Game Experiences

2010-12-22T21:20:00.002-07:00

Fair warning, this post is kind of long and rambly.

I’ve been doing some thinking about procedurally generated content of late. There are some things about it that make me a little uneasy, things I haven’t really been able to put my finger on, but I think I figured out at least a part of it. It has to do with whether or not the game play experience is memorable.

One of the big selling points of procedurally generated games is that they give you limitless variety to play with. You can play the game dozens of times and it will play out differently every single time. There are quite a few games that do this: Tetris, Diablo, Steam Birds, Civilization, Minecraft, and my personal favorite Starfighter Eternal. Each of these games generates the content as you play the game, or before you start, giving a different experience each time.

The funny thing about these games though, is that typically I can only manage a single play through, or I’ll spend a few hours with it before losing interest, even though I think they are excellent games. Tetris and Steam Birds and Starfighter Eternal are great fun, and they play different every time, conceivable you could play these games for hundreds of hours, and enjoy every minute of it. Diablo, Civilization and Minecraft generate new maps for you, giving you new areas to explore and conquer, meaning that you never run out of places to play.

Many of these games will easily suck me in for hours if I get started, but after a while I find that I have little desire to go back. “So what?” you’re thinking, “You just get sick of the game, right?” No, I don’t think that’s it, I’ll often stay interested in games with non-procedurally generated content longer, even if they have less satisfying gameplay. That seems particularly strange to me, but the answer came to me one morning when I was trying to remember if I had already brushed my teeth.

Think about it, how much of your morning routine do you typically remember? Enough to differentiate between one day and the next? I often don’t, I’ll remember brushing my teeth, but I can’t remember if it was today, yesterday, or the day before that. The days all run together. That happens because the mind only stores new patterns. I go through the exact same motions every morning, so my brain barely bothers storing any specific information about the latest iteration of the morning routine. I believe that the same thing haunts procedural games, and is what makes me get bored of them quicker.

Do you remember each hour that you’ve sunk into Tetris? If you went and played for an hour right now, would you remember any of that hour, except that you had spent it playing Tetris? Each hour spent playing Tetris, while different enough to stay interesting, and keep you engaged, isn’t different enough for your brain to bother storing it. I see the same thing with Civilization, Steam Birds, Diablo, and all of those other games. I remember the games of Civilization 2 I played fourteen years ago better than I remember the ones I played last week. Because at that point it was still very new and different, the patterns were unique, and my mind eagerly memorized everything it could about the game. At this point, I’ve played so many games of Civilization that it’s like my morning routine, my brain sees no need to bother remembering it.
And that’s why I lose interest. I think this may be just me, but I really prefer to remember where my time went. If I’m going to spend a couple of hours with a game, I want to remember spending that time, I want to remember the game. By this point, I’ve remembered everything I’m going to remember about Civilization, so even though it’s a very compelling game, I don’t want to spend time with it. I know that I could easily lose hours to it, and enjoy the time quite a bit, but I know that come next week, I won’t remember those hours, they’ll be lumped in with all the other hours spent on Civilization.

A game that isn’t procedurally generated however, has a definite beginning, middle, and end. I may not remember every hour spent with the game, but I will remember the overall story arc the game told. Somehow I feel that that time is better spent, because twelve hours spent on, something like Dark Messiah of Might and Magic will give me a complete story to remember, but twelve more hours of Civilization, will just be another dozen hours with Civilization, indistinguishable from the other hundreds.

I’d really like to see, or even better, develop, a game that was able to produce limitless variety, and still give the type of memorable experiences that a non-procedurally generated game often does. I’ve got some ideas, but nothing beyond ideas at the moment.

March EGM Post Mortem

2010-03-30T17:00:00.001-06:00

I took a week out of my normal game development activities and worked on a game for the Experimental Gameplay Project. It was a good experience, I'm thinking I'll probably want to submit entries in future months. You can see the game I put together, Last Stand, here.

All told, I think I spent around 24 hours over a period of five days to get it done. I was surprised at the amount of that time that was spent polishing, and trying to make the experience smooth. It's still got some rough edges, but I was pretty pleased with how it came out.

This is a small exploration of an idea I first had a couple of years ago, inspired by Keith Laumer's Bolos. Basically they are giant machines with human brains in them, they can perceive everything very quickly, and so their movements tend to be precise. I thought it would be interesting to see if you slowed the usual action game way down, if it would become something like a strategy game. It didn't turn out quite how I imagined it, when I slowed it down too much it wasn't terribly interesting. I'm not really sure what might make it more interesting. Allowing the player to move might help, but it could use some more experimentation.

Even if this game doesn't go anywhere, I think it's great exercise for my game development muscles. I'm hoping that if I do this enough I'll start generating some really neat game ideas, instead of the tired old derivatives I typically seem to produce. Also, going through a whole product lifecycle so quickly, and so often should be helpful to my development skills.

Finally, it was a nice break to get away from my other game for a bit. When I finished the Last Stand I was really eager to get back to work on my other game.

Game development update

2010-02-21T21:38:00.003-07:00

I've been making a lot of progress on the game lately. I spent most of Saturday rewriting the navigation system, again. I decided on a whim to see if it would be much faster in C++ than it is in script. So I spent the first half of the day dusting off my C++ skills and writing one of the navigation methods C++.

The difference was phenomenal. The function I rewrote typically takes about 22 seconds to execute in script, which is quite a wait. When I rewrote it in C++, it took less than a millisecond to execute. After seeing a performance increase like that, I decided that I had to port the rest of the navigation code over to C++, and got to work on it.

It'll probably be a couple of more days before I have it all working again, but it will be so worth it. So, the lesson for this weekend is C++ is easier to get back into than I feared, and you shouldn't write performance critical code in script.

Thoughts on the Global Game Jam

2010-01-31T19:26:00.001-07:00

So this weekend I participated in the Global Game Jam, and it was quite the experience. It started Friday evening, when they announced the theme, Deception, and the secondary themes, Maids, Raids, and Trades. We brainstormed, made game pitches, then broke into groups. I ended up in a group with some great people, and I think our game turned out pretty good. Our game’s page on the GGJ website is here. Rather than trying to write a cohesive essay that addresses all my thoughts, I thought I would just share my thoughts in any particular order.

We did the game in C# using the XNA framework. I have only used C# once before, on a project for a class my senior year of college, and I didn’t do any XNA programming at the time. I was a bit nervous, making a game in a day is difficult enough, without having to deal with an unfamiliar language/framework. But it came pretty easy, switching between computer languages typically isn’t too difficult, especially if they have similar syntax like C# and Java. XNA was also pretty easy to get into; there were lots of examples, and some pretty good documentation.

As I was working, I found myself wondering why I didn’t us XNA instead of Torque. It’s pretty easy, very powerful, and it’s free. But then I started running into things I had to do for myself in XNA that Torque always takes care of for me. Like animation and movement, I think I did a pretty good job making my own animated sprites, but I’m glad we didn’t have to do any sort of collision detection, because I hate collision detection. Working with XNA gave me a good appreciation for XNA, and gave me a renewed appreciation for Torque.

We developed the game to run on the Xbox 360, which was a bit intimidating at first. I expected it to be a horrendous process, but it was really simple. We didn’t have to do any weird code tricks to accommodate the 360, it just worked. It was really easy to develop for both windows, and the 360. Although I was surprised by how little room there is on the 360 screen. Developing for a PC gives you a lot more real estate to play with; it felt a little bit restricting at times. Overall, I thought it was really fun to make a game for the 360, and I’m glad that’s the route we took.

Developing the game felt like a whole months-long development cycle compressed into a 24 hour period. It included everything from the initial object oriented design idealism, to the horrible refactoring because your design didn’t account for something, to the bug fixes, to the code base growing large enough that you can’t keep it all in your head, to frantic debugging while trying to add new functionality without breaking anything. There were moments when I would look at a section of code, and even though I had written it only five or six hours previously, it felt the same as it feels at work when I look at code that I haven’t seen in weeks.

You would think by now I would know this, but making a game is a lot of work. I was programming almost non-stop for 24 hours with another guy, working on a rather simple design and we still had to leave a couple of features out. A lot of it was just taking care of small details that you have to take care of if you plan on releasing your program to the public.

Programming at 5:30 am after you haven’t been to bed is a bad idea. There were several times I would run the game to see what needed fixing, see something, go into the code to fix it, and have no idea what it was I was intending to fix. I started having to write down what I saw the game doing so that I could remember what I was looking for sixty seconds later. It was an amusing experience though.

I might post a couple more thoughts as they occur to me, I’m still pretty tired from the event, so I might be thinking better in a couple of days. Overall, I thought it was a great experience, and would recommend anyone who is interested in game development participate in something like this.

Nutritionally Dense Entertainment

2009-12-27T18:04:00.001-07:00

I find that some entertainment choices are better than others. This may seem self evident, but bear with me here as I explain. Some entertainment seems more satisfying, for example, I could spend an hour playing Planescape: Torment, or I could spend an hour looking at lolcats. After the hour is finished I’m going to feel more satisfied if I spent the time with Planescape. It’s almost like Planescape is more nutritionally dense than the lolcats. Like the lolcats are a Twinkie and Planescape is an apple. The lolcats might be tasty, but too many will just make you sick.

I don’t think that you can say for sure that one form of entertainment is definitely superior to another. I think it’s primarily a matter of figuring out what forms of entertainment are best for you, and then having the restraint to seek those out. For example, I do really enjoy action RPGs, like Diablo, Titan Quest, or Torchlight. They are fun, and they’ll suck up lots of time if I let them. But I find that they aren’t as satisfying to me as other more story driven games. So I have to exercise restraint, and enjoy the action RPGs in small doses, while spending most of my entertainment time on other things. That was especially difficult the day after Christmas when Torchlight was on sale for $5.00. It was really tempting, but I knew that I wouldn’t enjoy it as much as some other games, and I’ve already got Titan Quest to give me my action RPG fix.

It’s kind of an interesting journey, figuring out what kind of entertainment really does it for you. Kind of difficult too, but I’ve found it’s helped me to enjoy my free time more. Just thought that was kind of interesting.

Game design lesson: Humility

2009-12-24T13:17:00.001-07:00

So I’ve been thinking a lot about what I’ve learned over the last year, especially from working on my current project. When I started work on the game, I really thought I finally had things figured out. I had worked on several game projects prior to this one, and none of them made it very far. Maybe twenty or thirty percent complete, I would learn new things each time about what made a good project.

For example, I really wanted to make a game that played like Elite, or Privateer, except you drove around a car through a post apocalyptic wasteland. I still think that sounds like a fun game both to make and play. But writing my own graphics and physics engine was something I really didn’t want to attempt. Something that would have taken way too long. So I learned to build on someone else’s technology, and otherwise save yourself time.

I also worked for a time on an online graphic adventure type game. I had the engine mostly written in flash, and it was kind of neat. It was going to be an episodic online adventure, with new episodes every couple of weeks or so. The primary problem with that is that I don’t have much artistic ability. Graphic adventures are incredibly demanding graphically, if you can imagine. So it was a bad idea to try creating something where 90% of the content was outside my ability to produce. I learned to focus on my strengths.

I then worked on a hacker type game. I wanted to create a game that made you feel like an elite hacker flying through the networks at incredible speeds. I wanted to focus on speed, and cleverness, and so I started working on a game design document, and trying to write it in Torque. Unfortunately my design strayed from the original idea, and became a bloated mess of contradicting game mechanics. I learned to keep the design tight and simple, to focus on a single gameplay type.

Then, almost exactly a year ago, I started on my current project. I picked a simple game type, that I really enjoyed, and thought I could bring some new ideas to. I really liked the idea of setting up your defenses, and repulsing wave after wave of enemy. It seemed simple enough to create, and I figured I would have it done by last July. I’ve learned more from this project than any other, but I think the primary lesson I’ve learned is humility.

A year ago, as I was working on the prototype for this game, I thought I had it all figured out. I was going to quickly get the game done, release it and move on to the next game in my brilliant career. I wanted to share what I had learned with others, so I volunteered to speak at a gathering of local independent game developers.

I talked like I knew it all. It kind of got away from me a little bit. I did my best to present the lessons I had learned, but what I didn’t realize is just how little I knew. I had learned lots of lessons on taking a game to the thirty or forty percent complete mark, and I thought with this newest game I had figured out how to smoothly take a game clear to completion.

I’ve learned over the past year how difficult it is to make something that works well outside the controlled environment of your development machine. I’ve learned how difficult it is to make a system of interlocking pieces that interact with each other in a way that is interesting. I’ve learned that all I’ve really produced before were prototypes, and that the real thing requires much more polish. I’ve learned that anyone who produces any sort of game, and releases it to the public deserves a lot of respect. I’ve learned that it is very understandable that a game studio could spend hundreds of thousands of dollars, and years of development, only to push out a product that isn’t any fun. And I’ve learned that I am in no position to tell anyone anything about game development.

I’m going to keep working, learning, and occasionally posting the things I’ve learned from my efforts. I do intend to finish and release this current game, even if it doesn’t end up being any fun.

Primarily I wanted to express how impressed I am with anyone that manages to finish and release a game. I intend to never say anything negative about someone who has worked hard and put their efforts out for the world to see. I might still criticize the work, but the artist deserves accolades for getting it done.

I also wanted to express to anyone who may have been put off by my hubris that I’ve learned quite a bit about how little I know. Hopefully 2010 will bring lots more learning experiences.

Twitter

2009-11-24T22:18:00.002-07:00

I never thought that I would find a use for twitter. But it occured to me that twitter might be a good way of posting project status updates. The hope is that knowing that I have a public log of my productivity will encourage me to do something every day so that I will always have something to post on it. If anyone is interested, here's a link to my twitter profile. I imagine that it will be pretty boring, at least at first, perhaps over time I'll loosen up and post more interesting personal stuff.

Zombie Path Finding: Part 3

2009-10-08T21:04:00.003-06:00

Last time I talked about some of the methods I tried that didn’t quite work out. This time I’m going to talk about what I did that finally worked.

Often a problem that is very difficult to solve, can become much easier to solve it you limit the scope of the problem. The more limited the scope, the easier it is to solve. For example, a self aware AI is a very hard problem, an AI that plays games well is an easier problem, an AI that plays a single game well is even easier. The trick is to limit the scope, without making the realm in which the solution operates uninteresting.

So, I decided that it would greatly simplify things, but still keep them interesting, if I changed the rules of how a map is put together. If you look at screen shots I’ve posted in the past, most of them feature a mix of open areas, and tighter areas, but the two mix together freely. So I set it up so that maps can only have two types of areas, open areas, and passageways connecting those open areas. The passageways are only one tile wide. Here’s a good image of a new map.

This breaks the tiles into two types of groups. One group I call edges, the other is called nodes. The edges are bright green in this other image. Barriers are only allowed on tiles in the edge group, which means that if a barricade is put up, the only way around it is through another edge, which means that I don’t have to look at each individual tile and calculate the best path, I can look at the larger groups of tiles instead.

Each node knows how to get a zombie from any tile in the group to any other tile in the group, and knows how to get a zombie to any adjacent tile groups. So there are two levels of path finding going on, the micro level, getting the zombies between individual tiles, can be done once when the level is loaded, or even when the level is built, because it will never change. The macro level, getting the zombies between the nodes and to the goal, needs to be calculated in real time, but because there is a relatively small number of nodes it goes pretty quickly. I only have to process around 22 nodes, rather than around 300 tiles.

Tuesday night I got the zombies to capture buildings again, and the zombies win pretty quickly. So I'll have to tweak them to make them weaker, or the humans tougher, or a little of both. But I'm glad that they are presenting a good challenge now.

Looking at it now the solution seems pretty obvious, but it was kind of a rough journey to get here. It reminds me of something one of my math professors once said. He had shown us how to do a proof, and a student said “Well I can understand it when I see you do it, but I can’t come up with it myself.” The professor replied “Yeah, it’s really easy to watch a strong guy lift weights in the gym, but it’s much harder when you’re the one lifting the weights.” Hopefully next time my mind will be a bit stronger, and I’ll be able to more quickly find these types of solutions. In any case it was a fun problem to solve.

Zombie Path Finding: Part 2

2009-10-05T07:00:00.001-06:00

Last time I talked about the requirements I had for my path finding algorithm. Today I’m going to talk about some of the false starts I had, and some of the considerations that makes path finding difficult.

Initially I tried a straight implementation of Dijkstra’s algorithm. Basically how Dijkstra’s works, is that you pick a target point on the map, then move out from that point recording the distance to every point along the way. After you’re done you know how long the shortest path from any point to the target point is. You can use this information to get to the target from any point on the map. From any point, you pick the neighbor that has the smallest distance, and move there, then repeat the process until you reach the target.

It did everything really well, except for the quick recalculations. With a map that is only ten by ten (pretty small) there are a hundred squares, and each time I wanted to recalculate the paths I would have to visit each square and check its distance. This was pretty time consuming. Every time I placed a barricade, or the zombies tore one down, the game would pause for a half second while it recalculated. This was completely unacceptable, especially since I wanted to have maps that were at least twenty by twenty or larger. So I started investigating other path finding methods.

One algorithm that is very popular for path finding is A*, it’s a great algorithm, but not well suited to this situation. Mostly because A* works best to find a path between two points. If I wanted hundreds of zombies running around on the screen I couldn’t afford to run A* for each one, and it’s actually quicker to use Dijkstra’s rather than A* to find the quickest path from every point on the map. So I didn’t bother giving A* a try.

The first alternative I did try was the Ant Colony algorithm. Using this method the zombies would wander the map randomly until they found the target, then they would mark the path they followed, and when other zombies stumbled across the path they would use it. As more zombies followed the path, it got stronger, and even more zombies would follow it. There were two big problems with this though. First, it would take forever on a big map for the zombies to find the target point, once they did you would have every zombie on the map running at you as fast as they could come. But until then they wandered around aimlessly, and it was pretty boring. The other problem was that if they did manage to find a path, and you cut it off with a barricade, they would have a hard time routing around the barricade. It all became very noticeable on larger maps.

I tried another idea where I had the zombies do a breadth first search. Basically I marked the tiles that hadn’t been explored yet as the most interesting. The zombies would move in the direction that was most interesting to them. Tiles that were farther away from explored tiles would be less interesting, so the zombies would naturally spread out and explore. The most interesting tile was the target tile, so when the zombies found that one they would tend to move towards it above all the others. This did a good job of getting the zombies to spread out and search, but similar to the ant colony method, they took a long time to find the target tile.

I decided to give Dijkstra’s another try, but decided to see if I could find ways to reduce the number of calculations that had to be done. I figured it might be a good idea to break the map up into groups of tiles, then navigate between the groups of tiles rather than between the tiles themselves. That’s where I got into trying to calculate choke points, because a choke point would make a logical place to end one group of tiles, and start a new one.

So I started looking at ways to find chokepoints. I wrote some routines to go over the map and mark the tiles different colors based on how good it thought they were as candidates for chokepoints. The brighter the green, the more likely that the tile would make a good chokepoint.

None of them really gave very good results, although they were kind of interesting. This image shows the rankings based on which tiles have neighbors that are farther away from the target point. The idea was that if a tile has a lot of neighbors that are farther away, then more zombies will go through that tile on their way to the target.

This image shows the tiles that have a small number of neighbors. I thought that if a tile had a lot of neighbors, then it wasn’t as important because zombies would have more options when moving through the area, and could use one of the tile’s neighbors.

This image shows the tiles that have more options of where to go than their neighbors. This one seemed to have promise, since most of the tiles I would pick as chokepoints were also highlighted by this method. But it also highlighted a lot of extra tiles that weren’t important.

The last method I tried was to see how removing a given tile affected the distance of all of the other tiles. For each tile on the map I would remove the tile, then recalculate all of the distances, and check the new average distance against the old average distance. The greater the difference, the brighter the green. I figured that if a tile increased the average distance by a lot, then a lot of paths must pass through it, which would make it a good chokepoint. Unfortunately, while almost all of the tiles it picked out could be considered important, there were a lot of others that were important that didn’t get picked out.

I tried several other methods besides these to figure out which tiles were the important ones, but I finally decided that I needed a better approach, I needed to narrow the scope of the problem. So I found a way to greatly simplify the problem that I was trying to solve, but still keep things interesting. I’ll talk about that next time.

Zombie Path Finding: Part 1

2009-10-01T07:36:00.004-06:00

If you’ve been following my blog at all, you’ve probably noticed that it’s been over a month since I posted anything, but there’s been a good reason for that. Remember how I said that I’ve discovered that in game development gameplay balancing is the hard part, and implementation is the easy part? Well, I was wrong; they are both the hard part, probably along with some other hard parts I haven’t discovered yet.

I’ve been working on the path finding for my game, and it’s been a real beast, but I’m happy to say that I believe I’ve come up with a really good solution. I’d like to take you through how it works, and the process I went through to get there.

I realized I needed to do something very different with the path finding when I tried creating a big map. It took so long for the zombies to find the target building that I didn’t even have to do anything to win, just wait, it was pretty boring. So I sat down and came up with several requirements that I needed my path finding algorithms to satisfy:

The zombies had to be able to find the target building from any spot on the map
The route had to be able to be recalculated very quickly to route around barricades
I wanted the route to be non-deterministic, so that all hundred or so zombies wouldn’t follow the exact same route through the maze
Route calculations for each zombie had to be very quick, since I was going to be routing possibly hundreds of zombies around the map at once

Individually these requirements wouldn’t be too bad, but together they presented a real challenge for me. I spent a lot of time looking at graphs, and trying to figure out clever ways of handling things. Eventually I realized that in most of the maps there were a lot of wide open spaces that narrowed down to choke points, and that if I were to route the zombies between the choke points, then I could save myself a lot of calculations. So I started coming up with different ideas on how to mark those choke points.

As a human, it’s pretty easy to quickly pick out potential choke points, but that’s because we tend to look at the whole map at once, and do parallel processing to figure out which points are important. A computer can only look at one point at a time, so I had to come up with some heuristics, or rules of thumb, that would allow the computer to quickly determine which points would serve as good waypoints on the map.

Next time I’ll talk about some of the methods that I tried that didn’t quite work out, and some of the difficulties of the problem.

An RPG Should be short

2009-08-24T17:22:00.000-06:00

This started out as a quick response to a question posed by the Rampant Coyote. He talks about how the lengths of games have changed over the years, and asks readers how long they like their RPGs. The response got a little long, so I decided that rather than posting a wall of text in his comments, and would post it here, and link to it.

This question actually has two answers. If it's a wide open, sandbox style game, like Oblivion, I say throw as much stuff into it as you can, make it just as long and involved as possible. Because I didn't play Oblivion for the story, I played it to be immersed in a world, and the more world there is to be immersed in the better. However, for story based RPGs, I prefer shorter games, and here's why:

First, I get tired of the settings. I want to play something post apocolyptic, then I want to play high fantasy, then I want to play sci-fi, by 100 hours I'm sick of whatever setting I've been playing and want to do something new. At about ten to twenty hours, a game is just long enough to give you a good chance to explore the setting, have fun with it, and be done before you have a chance to get sick of it.

Second, I get tired of the mechanics. You can have plenty of growth over a hundred hour game, but you're still doing fundamentally the same things at level 100 as you are at level 1. Even if they are in the same genre, there will be enough difference between two games to make it fresh. I also like the feeling of learning and exploring new mechanics, typically you don't get new mechanics late in the game, they are just iterations of the same old ones.

Third, it takes months, or years, to play through a hundred hour game, by the time I get to the end I've forgotten everything that happened at the start. I can't remember the events that so cleverly foreshadowed what happens at the end, nor can I remember the questions that are finally being answered by the big bad's final monologue.

Finally, if a game is really great, I want to experience it again, that's really hard with a hundred hour game. I recently replayed Metal Gear Solid in one day, you couldn't do that with a game that takes a hundred hours to get through. Additionally, I like exploring different possibilities, especially in RPGs. If the game is really great, and has a lot of options, I might want to go through as a rogue, then as a warrior, then as a diplomat, just to explore the different possibilities. If the game only takes ten to fifteen hours per play through I can easily do that, if it takes a hundred hours, it aint gonna happen.

One really good example of this last point is Deus Ex. That game had so many possibilities for how to play, how to build your character, and what branches in the story to take. I would have loved to play that through two or three times, but I've only been able to get through it once. I started playing through again almost a year ago, and got half way through before another game pulled me away, but I feel like I missed out on a lot of what that game had to offer.

Last year I wrote a post on how I thought that the optimal game should be around eight to twelve hours. I still think that the best game would be one that you can beat relatively quickly, but has so many different ways to play that you keep wanting to come back for more.

Project Update

2009-08-05T19:45:00.003-06:00

It's been a while since I've said anything about the game I'm working on. So let me share with you what's going on.

This has been a big learning experience for me. I always thought that the difficult part of game development was the implementation, but that seems really easy now next to game balance. I recently read a great article that talked about how balance is the maximizing of player choices. An unbalanced element is one that removes player choice. For example, there used to be little difference between the riflemen and the machinegunners, the riflemen cost less, so there was no need to ever use anything but the riflemen. That's a choice the player doesn't need to make because using anything but the riflemen was stupid.

I've been focusing on differentiating the different classes, and giving the player reasons to use them. I think I've made some good strides in the right direction. I introduced a new zombie type, the armor zombie, that takes very little direct damage from attacks. Then I made the riflemen do very little direct damage, but they poison the zombie they hit. The armor zombies are just as susceptible to poison damage as any other zombie, so the riflemen are very effective against them. It takes two or three machine gunners to take down the same number of armor zombies that a single rifleman can handle. But at the same time the riflemen don't do enough damage to take down the other zombie types on their own, so you can't rely on nothing but riflemen.

Another change I made was to make the snipers very bad at tracking fast moving zombies, so they can really only hit a zombie that is coming towards them, or walking away from them. They do a lot of damage though, they can do about as much damage as three machine gunners, but they only cost a little more than two, the drawback is that they aren't any good in tight streets, so you can only use them in a few limited areas. This also gives you incentive to create long straight shots for the zombies to run down so that the sniper has a good shot.

Another problem I ran into was resources. Most tower defense type games have you gain resources by killing enemies. The problem I ran into with this was that I had the amount of money dropped by an enemy tied to how tough they are. This lead to situations where the zombies drop money, which means that the player's defenses improve, which means the zombies need to get tougher, which means they drop more money. It was really giving me fits trying to figure out the optimal rate of resource growth versus enemy strength growth. I finally decided to decouple the two, and made it so that the player gets resources from the buildings. Also the player can gain more resources by building factories on the buildings to boost their production. The trick about the factories, is that they improve their own production, and the production of surrounding buildings, but the effects don't stack. So the most economical thing to do is to spread your factories out over a large space. This whole setup does a couple of things, first it increases the players incentive to keep the zombies from capturing too many buildings, because each lost building cuts into their bottom line. Second it encourages careful placement of factories to maximize the number of buildings that they boost. Third, it encourages the player to hold onto large contiguous groups of buildings, they need as much real estate as they can get to maximize their earnings. Finally, it adds more choices, because the player has to decide, will they buy more defensive units, or more factories, or try to hold out in hopes of winning when they finally amass enough money to win.

Overall these changes seem to really be improving things. At the moment I'm reworking the path finding logic. It's a bit clunky, I set it up so that the zombies would favor exploration over building capturing, unfortunately this means that on smaller maps they never get around to capturing buildings.

I'm feeling really good about where things are headed. Once I get the gameplay nailed down a bit more, to where it's fun and challenging, then we'll be able to start work on the artwork again. Then maybe I'll have some pretty screenshots to put up.

MGS1 in one sitting

2009-07-30T17:32:00.000-06:00

So this last Saturday I was playing Metal Gear Solid 4, which made me nostalgic for MGS 1, so I popped it into the PS3 to see if it would work, and it did. Delighted I started it up with the idea that I would play for a half hour or so, then save my progress, quit, and come back when Nostalgia bit me again.

Then my wife came in, and she thought it was very interesting, and we ended up playing through the whole dang thing in one sitting. Well, my wife went to bed an hour before it was over, but I saved it, then finished it up just so that I could say I had done it. It was an interesting experience, I would recommend you try it some day when you’ve got eight hours or so to burn.

I’ve really been enjoying MGS 4, the gameplay is really good. I haven’t been enjoying the story as much as some of the previous installments though. One thing that has bothered me is the four Beasts, you’re supposed to feel bad for them because they’ve had horrible lives. But their stories are told by another character after you’ve just killed them, and he always says “But you cleansed her, you should feel real proud.” It all feels a bit contrived, a bit like Li'l Brudder from Strong Bad.

Anyway, playing a great game through in one sitting, something I definitely recommend.

All you do is run around and break things

2009-07-18T09:16:00.003-06:00

So we recently acquired a Playstation 3, and I've been playing a lot of Metal Gear Solid 4, but that's information for another post. Last night for our date night my wife and I got takeout dinner, and sat down with the playstation to play demos. We played through about fourteen demos in about three hours, and it was a lot of fun, but kind of a funny thing happened as we were playing.

My wife was playing the demo for Up, it's kind of a platformer game based on the Pixar movie. The characters from the movie would wander around on screen, and you could smash little rock formations, or mushroom patches, or break open coconuts and smash bugs. You would also have to navigate various obstacles, using the different characters together to move forward. The dialog was kind of funny, and it was kind of fun.

The funny thing was that as I watched my wife play I thought to myself, I don't think this could keep my attention, I mean, all you do is run around and break things with your cane. Then it occured to me that that describes a lot of games I play. Most shooter games you just run around and break things with your gun, action RPGs you just run around and break things with your sword, it's a common theme in video games.

I wondered if perhaps the exact same mechanics were presented in a 'darker and edgier' sort of context, if I would have enjoyed them more. I kind of have to laugh at myself, but I'm not going to worry about it too much. In any case, it was a fun game once you looked past the fact that you weren't playing as vampire hunters or elite commandos, but perhaps that's part of why my wife enjoyed it.

Game Moments: Privateer

2009-06-25T19:23:00.004-06:00

The Rampant Coyote has done a couple of blog posts on what he calls "game moments". Moments in a game where a spontaneous narrative emerge, if you've ever experienced one, you'll know what I'm talking about, they can be quite fun to relate. I wanted to share one that I had a couple of years ago while playing the game Wing Commander: Privateer.

I was tooling around in either the Rygannon or New Constantinople systems, trying to earn a little more cash before continuing my investigation of the Steltek artifact. I had by this point bought myself a very nice Centurion class ship. It was the most lethal ship available to civilians, and I just about had it outfitted just how I wanted. This run would get me the cash to finally finish upgrading all of its systems.

I liked to do batches of missions all at once. As I mentioned, my ship was more than a match for almost anything I came across, so I would take several missions where the objectives overlapped. One employer wants me to patrol all of the waypoints, while another wants me to check out some possible pirate activity at nav point three, and yet another wants me to look into a possible Kilrathi sighting at point five. Either way I've got to visit all of the points, and it saves me a lot of time.

This particular outing I was on a patrol, and also investigating some pirate activity within an asteroid field. Normally I don't like messing with asteroid fields, you have to slow down, lest you pummel yourself to death on the rocks. My ship was built for speed, and that's how I liked to dogfight, moving so fast that no one could catch me, swooping in for the kill and disappearing before they could react. An asteroid field put a serious damper on that sort of activity. But they were paying well, and I was confident in both my skills, and my hardware.

The patrol went well, I took down a couple of stray Kilrathi, but only took light damage. I had used probably half of my supply of missles, but I only had a few nav points left before heading home to collect my pay. After checking on a planet, I turned my ships nose towards the final nav point, the asteroid field. I put the ship on autopilot, and after a bit the proximity warning lit up letting me know that we had arrived at the nav point. I dropped my speed to avoid any collisions, and went to check my radar.

"Dump your cargo before you blow, will ya?" The sneering face of a pirate was on my com screen, hurling insults at me. Well, that's to be expected, typically they don't ask you to check on a nav point unless there is something to see. After responding to the pirate with a witty retort, I check my radar, and see that there are six pirates.

Okay, two or three I can handle without a sweat four it more difficult, but six, in an asteroid field? Deciding I'd better not mess around I quickly get a missle lock and fire off a salvo of two missiles at the lead pirate, then switch to guns and pummel another one as we shoot past each other. I bank around to finish off the one I'd started shooting. My missiles hit, taking one of the pirates out. An asteroid hits the one I had been tracking with my guns. The other four pirates are taking potshots at my tail, so I flip around to scare them off. As I do, I hit an asteroid, which knocks out my entire right shield, some of my armor, and one of my right guns. This is why I hate asteroids.

I fire off another salvo of missiles, one hits an asteroid, but the other scores a hit on the pirate, unfortunately it's only enough to damage him. Fortunately it's enough for me to finish him with my guns. Three down, three left. Two of them are on my tail, and my rear shields are just about done, they've also managed to score a few more hits on my right side, taking down the remaining gun, and putting the right missile tube out of commission. I decide to take a risk and hit the afterburner for a moment, just enough to put some distance between myself and the pirates. The gamble paid off as I was able to come about and put my stronger front shields and armor between myself and the pirates. We strafe each other as we pass, and I'm able to take down another pirate.

My shields and armor are just about gone by now, all the weapons on my right side are down, my engines are failing, and the radar is acting up. There are two pirates left by now, the one that was further off has almost rejoined the battle, so I'm in a hurry to finish off his wingmate before he gets here. The nearer pirate turns about and comes at me head on, we exchange fire and he explodes, but not before knocking out my engines and almost taking out my manuvering jets.

At the point I'm dead in space, stuck in one spot. I can roll counterclockwise, and yaw to the left, slowly, but that's it. I have one gun that barely shoots, and one missile tube. The last pirate makes his way back, and I know it's all over. I ineffectually try to keep him in my sights as he circles me like a vulture.

Then a stroke of fortune, and a meteor, strikes. The pirate runs headlong into a passing meteor, but it's not quite enough to take him down. He closes and starts pummeling me with fire. This is really it. I'm having trouble tracking him because my ship is moving so slowly. Then he moves into my field of view and comes at me for another run. This is more than I could have hoped for, with the pirate in my field of view and flying right at me I'm able to line him up and get a missile lock. I fire my last two missiles, and hope.

The pirate was overconfident by now, and so focused on taking me down that he doesn't even notice the missiles, and explodes in a fireball. Breathing a sigh of relief I shut down everything, and let my repair droid get to work on the ship systems. A while later my engines come back online, and I start limping back to port. Hours later I arrive, and land at the mining colony. The money from the jobs doesn't quite cover the repairs, but at least I'm still alive.

Ayn Rand on Video Game Art

2009-06-20T14:45:00.001-06:00

A couple of weeks ago I came across this quote from Ayn Rand:

Art is a selective re-creation of reality according to an artist's metaphysical value-judgments.

I don't claim to be an expert on Ayn Rand's ideas, but I've liked a lot of the things I've heard from her, and this quote especially. As I am wont to do, I immediately started thinking about how this idea would apply to video games, and whether video games could qualify as art under such a definition.

At it's core, a video game is an abstraction, a simplified system that often emulates a real world system. The game designer selects aspects of reality to model within the game, and comes up with game mechanics to represent them. Then covers the whole system with narrative window dressing to show us how the various mechanics reflect real life elements.

On the whole, this works really well, and people seem to forget that the game is just an abstraction, a selective re-creation of reality, rather than reality itself. Running through an FPS gunning down monsters by clicking on them is pretty different from real life warfare. But the mechanical metaphors that we use are good enough that even our noble politicians have trouble remembering that games are in no way reality.

The point is, that games simulate portions of reality, and they do it in the way that the game designer chooses. There are many reasons for the choices they make, ranging from gameplay concerns, to interface device limitations, to hardware limitations, to development costs, to just plain old aesthetics. And it's that last one that is really interesting, some choices are made because that's how a game designer feels that reality works, or that's how he wants people to perceive that it works, or even a little of both.

Consider a game like Sim City, through game play abstractions it allows the player to run a virtual city. We accept that it’s a stylized representation of reality, but even so we expect it to mirror our experience in the real world. This is where the game designer has an opportunity to say something about reality, and how it works. Suppose that the game designer feels that cutting taxes to businesses and allowing the wealth to trickle down to the populace is the best way to build a strong economy. It is a simple matter for him to make his game world function this way. By tweaking the systems that underlie the game, he can force the player to adopt a fiscal policy in game that is similar to the designers idea of an optimal fiscal policy.

As the player plays the game, he will learn, whether consciously or not, that providing tax breaks and incentives to businesses is the best thing to stimulate an economy. This is a very powerful way of expressing an opinion. Not only is the designer presenting his own ideas in a positive light, but he is forcing the player to accept and act as though, at least in the game’s limited reproduction of reality, the designer’s ideas are correct.

The potential for these kinds of statements is present anywhere a game simulates an aspect of reality. The actions available to players, the problems they must solve, and the means by which they may solve the problems all give interesting insight into the world view of the game designer. This isn't to say that every element of a game's mechanics should be subjected to scrutiny, and taken as an implicit statement by the games author on the nature of reality, but that the potential is there, and messages are being communicated even if they aren't intended.

The really neat thing about this, is that this is just one of the many types of expression available to a video game designer. In addition to choices on how the nature of reality will be represented in a game, the designer can make statements through art direction, music selection, narrative and many other avenues. Video games are truly one of the most expressive mediums yet.

So after just a little bit of thought, it becomes pretty clear that any assertions that games are not art because they lack the ability to express anything, are pure garbage. Unfortunately there haven't been a lot of games yet that have started to use game mechanics to say anything meaningful, there are a few, but not many. It's a difficult thing, as I've been working on my game I've discovered that it's hard just to make something that's interesting to play with, let alone making it interesting, and meaningful. But it is something that I plan to explore in future projects, and hopefully this is something that we will continue to see more of.

Penumbra Overture: Further Thoughts

2009-06-16T17:36:00.002-06:00

I didn't want yesterday's post to get too long, I think I tend to have a problem with that, so I'm continuing my thoughts in today's post.

Atmosphere
I'm really enjoying the atmosphere of the game. It does a really good job using lighting and sound to convey a feeling of omnipresent threat. Frequently throughout the game you have to venture into spider infested tunnels, often you don't see anything, but you can hear crawling things all around you. The game thus far has taken place almost entirely in an old mine, which shakes and rumbles from time to time. The small earthquakes sound almost like the angry growls of a nasty monster deep in the mine.

Most of the mine is covered in darkness, it's a relief whenever you're able to spend time in areas that are more well lit. But even the well lit areas are still covered in rust and decay, serving as a reminder that you are very alone. Additionally the areas of light serve a nice contrast, making the dark areas even more frightening.

Saving
This really bothered me for a while until I figured out how the saving mechanism worked. Throughout the game you'll find ancient artifacts, that look almost like lanterns. When you click on one, it gives a brief description of the main characters thoughts as the artifact invades his head. I finally noticed that the save game files all seemed to be created around the same time that I clicked on the artifacts. After that I was able to relax because I didn't have to worry about whether my progress would be lost. There are also auto-save spots scattered around, and so far they have been very well positioned.

One thing that can always sap the scary out of a game is having to replay a particular portion over and over. So good check point placement is important. It's done an admirable job so far. There was one sequence where you have to move through a small spider infested tunnel, and you actually get chased by spiders. You can hear them hatching from their eggs and coming after you, and you have to run through the tunnel, and find ways to prevent them from chasing you. It was thrilling and terrifying, and it could have easily been ruined by poor save spot placement. I had to replay one section through four or five times, there was a rock rolling down an incline, Indiana Jones style, and it took a couple of tries to figure out where to run to get out of the way. Each time I died it placed me right before the rock puzzle, meaning I was only ten or fifteen seconds between attempts. If I had had to replay the entire tunnel sequence each time I would have quickly grown tired of it, and it would have lost all of its terror inducing goodness.

Plot
The plot is interesting so far, it seems to have some Lovecraftian influences, which is always a good thing in my book. So far a lot of the story has been told through notes left behind by other characters, which is always a good way to include other characters, but still keep the player isolated.

Anyway, I'm enjoying it so far. I'll post more thoughts as they occur to me.

Penumbra Overture: Initial Thoughts

2009-06-15T19:24:00.003-06:00

Steam had a sale on the Penumbra games a week ago, and I picked them up. I'd had my eye on them, and just couldn't justify not buying them. So I'm a couple of hours into the first game, Penumbra Overture, and thought I'd share some thoughts I've had as I got into it. Yes, the game is three or four years old, but I think it has aged extremely well, and it's an indie effort, so I figure there's no excuse not to talk about it.

I'll steer clear of any spoilers, and being only a couple of hours in I'm not sure that I'll have much in the way of forbidden knowledge to impart anyway.

Overview
Penumbra is a first person horror adventure game. You solve puzzles, and sneak around avoiding monsters, explore the environment, and try to piece together what is going on. It's wonderfully atmospheric, with sound, music, and lighting all working together well to make the thing scary.

Interface
The interface works like a regular FPS, WASD to move around, and the mouse to look around, but when you look directly at something you can manipulate a hand or eye icon appears. You can then right click to look at the item, or left click to pick it up or otherwise manipulate it. Now this sort of thing has been done before, but what I haven't seen is how you have to use your hand icon to manipulate everything. If you want to open a drawer, you grab it with your hand and pull it open. Want to turn a crank? Grab hold and give it a spin.

Interacting directly with the game objects like this makes me feel more like I'm in the world, and it makes the physics based puzzles much easier. Instead of picking up and stacking boxes like a forklift (like most games), you pick up the box and can see exactly where it's going, and carefully adjust its position in the stack. The best part though is when you're opening doors. I've always hated in games that a door is either open, or closed, especially if it's a scary game. I want to slowly open the door and peek into the next room, which you can do very naturally in Penumbra. Or if you want you can quickly throw the door open. It heightens the suspense when you're trying to quickly close the door before the monster sees you, but you don't want to make a lot of noise.

Combat
Unfortunately the interface, while great for exploring, is not so good for combat. You pick up various weapons in the game, so far all I've found are things like pick axes, hammers, and push brooms. You swing these by clicking, and actually swinging the mouse around the screen. This works really well when you're just trying to beat down a door with your pick axe, but when you're fighting an undead wolf it's not nearly as enjoyable. I'll try to make an attack, and end up looking in a different direction, or try looking in a different direction to target the enemy, and end up swinging my weapon. It feels pretty clunky. Fortunately, as I did some last minute research to confirm that buying the game was a good idea, I noticed that people complained about the combat, so when it asked me how hard I wanted the combat to be I swallowed my pride and set it to easy. I am so glad I did. Overall though, it isn't too bad, I'm glad it's mostly a game of exploration and puzzle solving, rather than combat.

This post has gotten kind of long, I'm surprised at how much I've had to say about the game. I don't want to make this into an impenetrable wall of text, so I'll pick up on this tomorrow.

Free Radical

2009-06-12T21:55:00.001-06:00

Recently I finished reading Free Radical, a book by Shamus Young that is based on the classic game System Shock, and let me tell you, it was a great read. I'm going to talk about some of the things that really impressed me about the book, obviously there will be plenty of spoilers, both for the game and for the book. I figure that if you haven't played the game yet, chances are you aren't going to, it's seventeen years old, well worth playing, but it may prove difficult for more modern palates.

Here's a five sentence summary of the story. Tri-Optimum is a big powerful corporation with a powerful AI named Shodan. They catch a hacker breaking into their system and hire him to break the ethical constraints off of Shodan. In return, they provide him with a neural interface that allows him to interface directly with computers. When he wakes up from the surgery of having the interface installed Shodan has gone crazy and killed everyone. Fighting past her army of cybernetic ghouls and security robots, the hacker finally defeats Shodan.

Something that Shamus often complains about in games is their two dimensional villains, people who do bad things simply because they are evil. This is about the level of motivation that Shodan had in the original game, she was insane, and evil. So as I read Free Radical, I watched to see how Shamus would flesh out Shodan, and he did a remarkable job.

In addition to giving Shodan understandable motivations for the carnage she enacted, he further made her into a character I could care about and empathize with. Seriously, I felt bad at the end when Shodan died! Very impressive stuff.

Further, he took and logically explained away several of the plot holes. I always thought it was odd that a corporation had to hire an outside hacker to remove the ethical constraints. First, why would you need to remove the ethical constraints? So it can start killing things?! Second, you wrote the thing, why not do it yourself? These were questions I never found answers for in the game (not saying they weren't there, I just didn't see them). Free Radical however, provided brilliant reasons for both of these things, in the form of corporate plausible deniability, and crooked bank ledgers.

Finally I loved what he did with the characters. There was real character growth there. Over the course of the story the hacker took a hard look at how he had been living his life, and the consequences his actions had brought about. His motivations changed as he realized his mistakes and felt a desire to atone. He was a very interesting character, and like Shodan, one that I really felt empathy for.

Overall the book was a joy to read. It was delightful seeing how Shamus
brought to life the flat events and characters from the game. I loved reading about the different locations on Citadel station, and recalling being there myself. I enjoyed the action and reading about the journey, even though I knew how it must inevitably end, I still found myself hanging on every word, wondering how the conclusion would be reached.

Even if you haven't played the game, it's a brilliant read. It's a great example of how to make living characters that grow over time, have interesting motivations, and engender empathy in the reader. It has made me change how I plan to approach writing characters for my own games and stories. It would be a great thing for video game stories if we had people like Shamus writing them.

Back to basics

2009-06-11T22:24:00.003-06:00

So I spent about four hours watching zombies move through that small maze to the left, and making tweaks to how fast they came, how much damage the soldiers did, etc.

I've been having trouble with the gameplay, so I pulled it back to its most basic. No building capturing, only one type of zombie, only one type of human. I think it was a really good idea.

It certainly made it easier to see how these elements interact. I'm trying to figure out the optimal rate for the zombie's strength to grow, and how much damage soldiers should do, and so on. Balancing all this is hard work. I'm really surprised. For some reason I had often thought that the difficult part would be coding, but this is pretty tricky too.

I think I'm making progress. It's much more interesting than before. The early stages are filled with genuine panic, but somehow the humans grow too powerful after a while, even though theoretically they should be growing at the same rate.

So that's where I'm at. Hopefully I'll have this figured out before long, and hopefully what I learn here will help me get the other soldier and zombie types working faster.

Deficit programming

2009-05-28T17:15:00.003-06:00

Here's a synchronicity, I've recently been experiencing some major bug problems with my game, due to fast and sloppy programming. I was trying last night to come up with a good phrase to describe the phenomenon when I came across this post on Shamus Young's site.

Basically deficit programming is when you trade time for code robustness, you get code written quickly, but it isn't particularly well put together. This can lead to numerous bugs and strange behaviors in the future, especially when you try to expand on it.

The past couple of weeks I've been adding a lot of features to my game, and not taking the time to do it carefully the way it should be done. I felt (and still do) that it was justified because a lot of the features I was adding weren't going to stick around for very long.

As you're working on the gameplay elements of a game, you have only a vague idea how things are going to affect each other. This is something I had heard about, but didn't really understand until I saw it first hand. Introducing a seemingly small element can drastically alter the way things work. With this kind of thing going on I didn't want to spend five or six hours adding a feature the right way, only to rip it out when it didn't work from a gameplay perspective. If I could get it in in two hours, and see how it works, well that was very tempting.

So right now I've got a good accumulation of elements, but I've also got a good accumulation of bugs that I'm trying to work through. In any case, it was really encouraging to be reminded that I'm not the only one who goes through these kinds of problems, this post was also very helpful in that regard.

Thanks Shamus.

Dear Esther

2009-05-15T23:07:00.002-06:00

I came across this over at Rock Paper Shotgun. It's a brilliant little piece about a brilliant little mod called Dear Esther. I highly recommend you take a look at it.

This is the sort of thing I was hoping to do with games at some point. It isn't exciting or fun, it doesn't break any new ground in game mechanics. It's more like interactive poetry, telling the tragic tale of a man who has lost/is losing his mind, as economically as possible. It hints and suggests at the outlines of the subject rather than coming out and revealing it.

It's really something that I don't think could have been done in any other medium, and that really says something for interactive media. Most of the games we get are the equivalent of summer blockbusters, little more than actionpacked thrill rides. In order the for games to be taken seriously we are going to need more games like this one.

The only thing I wonder about is control scheme. There were a few spots where I struggled with the terrain. I wonder if someone who hasn't been playing fps games since the mid 90's would find this unnavigable. Anyone can sit down and appreciate a movie, or a piece of music, or a painting, but games require at least a little bit of skill in order to experience. I often wonder if navigating a virtual world using WASD is going to become a skill that everyone has, or if we are gong to need to develop some more standard control scheme.

Anyway, it was a well spent hour, give it a go.

Project Update

2009-05-13T21:15:00.002-06:00

Here's a screenshot from tonight. It's coming along well, I've made a whole lot of changes since the last time I posted a progress report.

Currently we're doing a lot of tuning on the gameplay side. Trying to get it to be fun, and challenging, and to work well. The numbers you see on the buildings denote what level the building is, and what kind of building it is. As zombies come in from off the side of the map they can capture buildings. Once captured a building will produce zombies, and can be upgraded. As buildings are upgraded they produce zombies faster, they produce stronger zombies, and can produce different varieties of zombies.

Right now the game is just too easy. The zombies come pretty furiously, but the humans are just too good at holding them off, so I'm doing experimenting to try and figure out how to have both sides increase in power at roughly the same level.

Anyway, I just wanted this to be a quick status update. Just something to set a precedent to get me to post status updates more often.

Six Days in Fallujah

2009-05-09T21:49:00.003-06:00

Wait a minute you say, wasn't this was supposed to be a post about picking a project? Well, yes, it was, but I realized some important things, to wit:

Nobody is reading this anyway
Everything original I had to say on the subject, was said in the previous article
If I'm writing stuff that nobody is going to read anyway, I may as well be writing stuff I get excited about

Right, so now I'm going instead to talk briefly about Six Days in Fallujah. The short of it, as I understand it, is this: Some veterans from Iraq decided they wanted a game made of their experiences, so they approached a developer, the developer started work and got with Konami to publish it. When news of the game got out, lots of people got upset, and Konami pulled their support for the project.

That's all I know about the project, but it's enough for what I want to talk about. I don't want to argue the merits of this individual game, or whether or not it should continue, or whatever. What I do want to talk about is how people got all riled up about this being made into a game, where they probably wouldn't have been nearly upset if a movie were being made on the subject.

I think the problem here is not only in how games are viewed, but also in how we've been making games. Games right now are viewed, and not unfairly, primarily as amusing entertainment at best, and toys for children at worst. Games are only ever made in order to provide a 'fun' experience. That's always been the number one rule of game design, whatever else happens the game has to stay fun.

Movies on the other hand, come in many different varieties, some are fun, and some aren't. And it's because not all movies are fun, that they are allowed to treat more serious subject matter. A piece of media treating something as harrowing and recent as the Iraq war shouldn't be fun, it's just too soon for it to be fun. Some might argue that there is never a time when a depiction of war should be fun, and there might be some merit to that, but I don't want to get into that discussion here.

So would it be possible to make a game that wasn't fun, but was still compelling? Absolutely, most of the efforts on this front have been made by indie developers. I think a great example of this is Judith, a relatively short little game that is absolutely worth playing. I would almost call it more of an interactive experience than a game. There wasn't a lot of room to play in, there wasn't any freedom in the narrative, there wasn't any way to lose, or die, you just move through the story. And yet I think that it was much better than a non-interactive telling of the same story could have been. Somehow, being the one to guide the characters around on the screen forged a connection with them for me, more than I could have felt through another media form.

This is the power of games, but I think we might need to come up with another name for them. Game brings to mind fun, and that's as it should be. But when interactive media seeks to respectfully address difficult topics and issues, we need something to call it that doesn't instantly make people think that we are taking those sensitive issues and making them fun.

But I have no idea what that label might be.

Choosing a Project: Know Yourself

2009-05-02T12:05:00.000-06:00

I recently shared some thoughts with the Utah Independent Game Developers group about choosing a game project that you’ll actually be able to finish. Seeing as my blog has been sorely lacking in updates, I figured this might be a good opportunity to turn my presentation into a couple of articles and put up something that might be of interest to people.

As a foreword, I think it’s only fair that people realize that the ideas in here aren’t the result of years of successful independent game development. They are largely the result of my own quest to find a game project that I would be able to finish. Now that I’ve found a project that is going all the way, I wanted to share what I’ve learned in the hopes that others will be able to avoid some of the struggles that I’ve had.

I’m going to break my thoughts into three articles, because each section is a little long, and reading them all at once would be maddening. Also typing them all up at once would be equally maddening I think. The three areas I chose to focus on were Know Yourself, Knowing Your Audience, and Knowing Your Project.

Know Yourself

I believe that knowing yourself is one of the most important aspects of choosing a project that’s a good fit for you. Independent game development is intensely personal, it’s not something that you can do half heartedly and expect to succeed. If you don’t have your whole heart in the project, then it’s going to be a miserable slog to the end—if you ever make it. So as you choose a project, it’s important to know where you are coming from, and how that project fits into your strengths, weaknesses, and desires.

Know why you are making a game

Making a game is really hard work. It requires long hours, learning difficult things, and stretching and growing in a lot of new ways. You’re going to need more reason than just ‘it sounded like it would be fun’, because if you ever hope to finish you’re going to have to work on your project even when it isn’t fun. Find a reason that fills you with excitement and passion, are you working on a game because you’ve got an idea for a game that will be incredible to play? Or maybe nobody else makes the kind of game you want to play? Or perhaps you have a story that you want to tell, and think that it would make a great game? The only right answer to this question is one that makes eager to start working on your game.

Another thing that having a good reason for game development will do for you, is that it will help you avoid ‘Project Envy.’ This is when you’re working away on your game project and you see someone else’s project, and you think “Wow, that’s really cool. I wish I was working on something like that.” The reasons the other project grabs your attention can be varied. For myself a big one seems to be critically acclaimed indie games. I get jealous, and think “I want everyone to talk about me and my awesome game! Maybe I need to develop something more revolutionary!” But then I sit back and remember that the reason I want to develop games is to create neat worlds, and give gamers interesting experiences in those worlds. And I realize that my current project fulfills that better than whatever game I’m currently envying.

If you know why you’re developing games, you’ll find it easier to stick with a single project, and you’ll find it easier to work on it. When it’s been a long day at work, and you’re trying to find a nasty bug in your project, and you’re just tired and want to give up, believe me, you’ll want a good reason for sticking to it.

Figure out what you like

If you know what it is you like about games, then you’ll have a better idea of what kind of game you’ll enjoy developing. Starting out with the goal of making a game that is just fun is going to lead to a lot of dead ends and frustration. Maybe you like games that include interesting characters, or lots of enemies to kill, or difficult puzzles to solve, or mysterious locations to explore. As you become clear on the things that make games fun for you, you’ll have a better idea of where your game needs to go. Having a clear picture of your destination is absolutely essential to getting there.

In addition to bringing clarity, working on a game you like will engage your passion. It’s difficult to get passionate about a game that you’re not that into, and without that passion the development process will be a painful and unpleasant process. As an independent developer passion is one of your biggest advantages over the big studios. When you make a game that you are passionate about, people will feel that passion, and the game will be a better experience for it.

Another good reason to work on a game you enjoy is because you’ll have more good ideas. If you’re interested in indie game development then you probably do a lot of thinking about games, and the games you think about are the ones you enjoy. All that thinking is going to lead to a lot of ideas about how to change and improve game experiences. Those ideas will help to make your game unique and fun. If you’re working on a type of game that you’re not that into, you’ll have a hard time coming up with new ideas, and you’ll end up creating something that’s pretty average that nobody wants that.

Finally, if you are working on a game that includes lots of elements you like, then you’ll be drawn back to it. That’s really important, as a part time indie developer it’s difficult to find development time. If you’re working on a project that has a lot of things you love then it will be easier and more natural for you to return again and again to work on it.

Know your skills, and work to your strengths

Different types of games require different skill sets, and you should figure out where your skills lie before committing to a project. Here’s an example: If you suck at art, don’t do a graphic adventure. I had to learn that one the hard way. I once started work on a Flash based graphic adventure, it was going to be awesome. I had the engine all programmed, I had a dialogue engine, inventory, puzzles, different locations, the whole thing. I was going to release a new section of the adventure every week, and people were going to come to my site every week for the new puzzle, then they would go to my forums and discuss where the story was headed, and talk about easter eggs. The whole time they were doing this they would be clicking ads and buying merchandise—I was going to be rich.

Then reality hit, with the engine done, all I had to do was start producing art, and putting it up. Six months later I had one or two screens that weren’t terribly impressive. I sat back and realized that there was no way I could produce artwork in the quantities I needed it. I could hire an artist, but that would be a lot of art, and I had zero money. Graphic adventures are reliant on a lot of art, after realizing this I decided that I needed to work on a game where I could reuse my art assets, producing a lot of content with a fixed amount of art.

As an indie developer you’re not going to have a lot of time, what little time you do have is going to need to be well spent. I spent about four months part time coding up the engine for my online graphic adventure, the work went relatively quickly, then I spent six months making two game screens, the work was incredibly slow. You’re going to work faster when you’re using skills that you have already developed, which means time that is better spent.

Keep in mind that there is no shame in getting outside help. In fact, it’s encouraged and almost mandatory. Go out and find ways to leverage other people’s skills to help with your project. Buy an existing game engine, buy an art pack, buy a music pack. You’ll save time, and it will give you the opportunity to use your skills where they really shine.

This isn’t to say that you should avoid doing things that you aren’t good at. Being an indie means wearing many different hats, and you’ll need a diverse set of skills to bring a game to market. Jay Barnson made a good comment about this, paraphrased he said “Don’t be afraid to expand your skills, but don’t bank on having a new skill be awesome either.” Let your already strong skills do the heavy lifting, and grow your other skills along the way.

Finally, if you are doing things that you are good at, then you’ll have more fun, which is very important. If you’re not having fun with your project, then you’ll find any reason at all to stay away from it. Life will give you more than enough reasons not to work on your project, you don’t need to be inventing more. When I worked on my online graphic adventure, I looked for any excuse I could find to not work on my project, because working on the graphical aspects was like pulling teeth. I really enjoy doing artistic stuff in moderation, but when it was for that game project it made me do everything I could to avoid the project. This can be avoided though, by figuring out what you’re good at, and choosing a project that focuses on that.

Know where you stand

Finally, know how you feel about questionable content in games. This was something that was really brought to the front of my mind with my current project. I was reading World War Z, when I had the idea of making a game where you defend a city against ravening hordes of zombie like creatures. I started work, and got really excited about it. But as I got to where it was playable I realized that I didn’t really feel good about the idea of making a gore filled game of slaughter. Fortunately as I was looking for artists I found one who didn’t want to make a bloody game either, and had some ideas on how to make a good game without making it a gorefest.

You’ll never finish a project that you don’t feel right about finishing. If somewhere in the back of your mind you are wondering about the morality of developing the game you are working on, then you’ll have a hard time getting enthusiastic about it. Find a game that you’ll be able to proudly tell people you developed.

Be careful though, just because you feel okay about playing a game, doesn’t mean that you would feel good making a game like it. I tend to like my games a little less bloody than most, but as I discovered with my current project, I have an even lower tolerance for blood in the games I make. Put some thought into it, because you don’t want to be half way through a project, only to discover that the thought of releasing it makes you uncomfortable.

Summary

Getting to know yourself, and what motivates your game development is important. Your game project will consume your life, and if it isn’t something that you can look back on with pride then you’re going to regret the time that you spent with it. By knowing about yourself, you can select projects that will complement your abilities, and be a better representation of who you are.

Next time I’ll be talking about knowing your audience, and some things to consider when thinking about who will be playing your game.

Keeping up the momentum

2009-01-07T21:18:00.000-07:00

I've gone back to work, so I haven't been able to keep working 12 hours a day on the zombie defense game. But I have kept up the momentum. I made a hard and fast rule for myself that I can't let a day pass without doing something on the game. So far this week I've fixed a couple of bugs, and implemented the losing and winning screens. Things are moving along well. I'm planning for a July release, and it looks like things are on track for that.

I feel that if I can make consistent progress then I should have a well polished product ready for market come July. I'll make periodic updates here on the status as interesting things happen.

Game Cow Week: Day 6

2009-01-03T21:44:00.001-07:00

Today was pretty productive. I focused primarily on polishing things. I added buttons for deploying the different defensive units, and implemented limits for the defensive units and defensive barriers, so that the player only gets a limited number of each. I also fixed some bugs relating to zombie movement, defender firing ranges, and several other areas. I added range indicators, so now the player can get a visual indication of what zombies are in range for each of the defenders. Overall the game all works pretty well.

I’m very satisfied with my results. I wanted to have something that was a working game, and that’s what I’ve got. I plan to do quite a bit more polishing, and add some new features. But I’m very pleased with what I got from my week of work.

Game Cow Week: Day 5

2009-01-02T22:05:00.000-07:00

Today was pretty unproductive. I think a week of working way too hard, coupled with really late nights has finally caught up with me. I felt pretty unmotivated and was completely unable to focus. I did however add a title screen, and set up the level loading logic, so that I can now load and unload levels according to the player's wishes.

Here's hoping for a good final day tomorrow.

Game Cow Week: Day 4

2009-01-01T20:32:00.000-07:00

Today wasn’t quite as productive as the other days. But I still got some good stuff done. I had to do a lot of debugging, and code refactoring. I expect that I’ll have to do more of that as time goes on because the code base is getting a lot larger, and more complicated. Additionally, when I wrote some earlier code I was making assumptions that no longer hold true. It’s been interesting producing so much code in such a short time.

I spent a fair amount of time reworking the defender classes. I added some methods to calculate line of sight so that I could have the defenders hold their fire until they can actually see a zombie. I also modified the defenders so that when they are standing on buildings they can’t shoot immediately around themselves. This is a gameplay move, it gives you a reason to put defenders out on the streets, because they can shoot zombies that are up close, rather than just ones that are farther away. I also added some code so that the defenders have accuracy stats, and their weapons also have accuracy stats. This along with some other changes allowed me to implement three different defender classes. There’s the rifleman, they fire in three round bursts that do decent damage, and their accuracy isn’t great, but it’s okay. There’s a sniper, that has a really long range, good accuracy and damage, but they shoot slower, and only shoot one bullet at a time, so they can only hit one zombie at a time. Then there’s the saw (squad assault weapon) soldier, he sprays the bullets, with low accuracy, and pretty crummy damage, but he puts out a whole lot of fire.

Today marked the first day where it really started to feel fun. As I was setting out the different troopers, and trying to figure out the best spots to put them to stop the zombie hordes it was really fun. Hopefully I’ll be able to improve on that as I add more features in the coming days. I’m hoping to finish up the humans tomorrow, adding experience points, and morale to the mix. I’m also planning on reworking how soldier deployment works some, and putting limits on how many soldiers can be deployed. If time allows I’m also going to be working on polishing up the interface some. Adding some menus, and adding methods to display story text, and information about individual soldiers.

Instead of a screenshot today, I have a video. Putting out the troopers was so fun, that I decided that there needed to be sound effects, so I added some gun sound effects. The whole thing was so fun to watch that I decided a screen shot just couldn’t do it justice and downloaded a cool open souce video maker and made a video. I stuck on youtube, you can watch it here. I recommend watching it in high quality.

Game Cow Week: Day 3

2008-12-31T18:26:00.000-07:00

I stopped early today, about 5:30, because it was new years, and because I was starting to get burned out. Although after nearly thirty six hours of programming in just three days, it’s not much of a surprise.

I got some good stuff done today. I added barricades, two varieties, that can easily be expanded into three. I set it up so that when you place a barricade it barricades all four sides of the tile, with an empty space inside which you can place defenders. The defenders can then shoot out of the barricade at the passing zombies. I also got the zombies to chase defenders, so if a zombie sees a defender it will attack it, meaning that packs of zombies will move out and swarm around defenders. So if you have a defender behind a barricade, then the zombies will swarm the barricade and beat on it until it falls apart. The path finding works so that the zombies will sometimes decide that it is faster and easier to beat their way through a barrier, rather than going around. Also at times the zombies will be going around a barrier, except for a few who are trying to get at a defender who is inside. When they finally get through the barrier the other zombies will start following the shorter route opened up by the destruction of the barrier.

I also added a water tile. Water tiles slow zombies down, so they will avoid them if possible. I’m thinking it would be fun to have zombies randomly get washed away in the current, and that shouldn’t be too hard to implement. Maybe I’ll do that tomorrow.

Another new feature is two additional types of zombies. Now there are the standard slow zombies, a faster variety that moves about three times as fast, and a big powerful zombie that moves slower than the others, but is much tougher. The big zombies are giving me a little bit of trouble, because they move slower they don’t flow through the level as nicely as the other varieties. I’m going to have to play around with them some to see what I can do to get them to work better.

Tomorrow I’m going to dive into developing the humans more. I think it could be fun to have the human units be unique, something like your units in Fire Emblem, which would better facilitate a story and be pretty unique for a tower defense game. But I don’t know if that will work out. Usually tower defense games require you to have lots of towers out on the play field, and if I have the units be unique I’m probably looking at only about thirty or forty units total over the course of the whole game. A possible solution might be to have a mix of hero units that are unique, and generic grunt units that aren’t unique. I guess time and playtesting will show what will work.

Game Cow Week: Day 2

2008-12-30T20:19:00.000-07:00

This morning started off a little rougher. I realized that I needed to rework some of my underlying systems, so I spent most of the morning doing that with little visible result. But the change will pay big dividends in the next couple of days.

What I was doing was having each of the objects using their own timers to update things. This made it really difficult to script anything, because the zombie spawners couldn’t be controlled, and the zombies themselves couldn’t be paused or anything. So I set it up to have one class that has a timer, and it sends tick events to all of the objects that need to be updated. Certainly not anything new, but it works well, and it allowed me to easily implement a pause function. It will also make it easy to put in story events.

The reason I had to add this in today was because I was working on making it so that the user gets a bit of time at the beginning of the level to choose which building to hole up in, and where to place defenses. The way it was working zombies would just start spawning as soon as the level started, but now I’ve got it working on a schedule.

Which brings me to the new features. As seen below in the screen shot you can select which building you want to hole up in. This also necessitated some path finding for the zombies, since they might need to head anywhere in the level. Rather than implementing AI for each of the hundreds of zombies on screen at any time, I set them up to use a technique called potential fields. What I do is use Dijkstra’s algorithm to find the shortest path from any point on the map to the target building. Then I set up each tile on the map with a force vector to push the zombies towards the next closes tile. Almost like the zombies are little scraps of paper being blown about in the wind. It works pretty well for herding hundreds of zombies towards their destination, and assures that even if one gets off the normal path it can still find its way.

I also added in human defenders. In the second screenshot you can kind of see a couple of little blue guys, and you can see some of their bullets that they are shooting at the zombies. They work pretty well, too well in fact. I’m going to have to do some balancing, five or six guys strategically placed can take out thousands of zombies no problem. I’m hoping to tackle that problem some tomorrow.

I’m planning on having the human defenders be subject to attrition, over time their morale drops, and they need to go back to the base for a while. That should make it interesting as the player constantly has to move defenders around, to keep fresh ones near the front lines. Also, at the moment zombies don’t even touch the human defenders, I’m going to have to fix that as well, that will require some interesting programming I think to get nearby zombies to head towards humans. Additionally I’m hoping to implement an experience system. In most tower defense games you level up your defenses by spending resources gained from killing baddies, I’m thinking instead that I want the defenders to level up as they kill zombies, which again will figure into the attrition thing.

So, tasks I’m hoping to look at tomorrow include: zombies attacking defenders, adding in barricades that the player can set up in the streets, different classes of zombies, and different classes of defenders.

By the way, if anyone is curious I’m using the Torque Game Builder. I’ve been really impressed, especially at the speed that I’ve been able to learn it. I looked at it a little bit about a year ago, but it’s been pretty easy to get up to speed on. I don’t actually own a license yet. I’m going to be buying one when I finish the week out.

Game Cow week

2008-12-29T20:04:00.000-07:00

Today I started an experiment, to see if I could build a game in one week. I’ve heard people describe what a great experience it was, and I’ve heard others talk about how it can sometimes take a big hairy audacious goal to really motivate you. So I came up with the idea last Saturday, I thought about it Sunday, and this morning at 7:30 I started working. I'm calling it game cow (Complete in One Week) week. If it goes well I may need to make it an annual event.

I’m going to update every day with progress reports, and screen shots so you can see how it’s coming.

It’s going to be a tower defense style game, with zombies. So today I worked on laying out a city that you could defend, and getting the zombies to walk through it. The image is a screenshot of what I got done today. You can see the hordes of zombies parading through the city.

I’m going to see what else I can get done before bed tonight, but tomorrow I’m going to start work on dynamic path finding. Today the zombies follow a hard coded path, but the player will be able to select which building they want to put the survivors in, and they will be able to blockade roads, so I’ll need the zombies to figure out the best path on a changing map.

Tomorrow will also see work on defenses. I’ll come up with some soldiers that the player can put throughout the city to take down the zombies as they go shuffling past.

If everything continues to go as well as it did today. Then I should have a functioning demo on Saturday for people to play. It won’t be very pretty, but it will work, and it will be fun. Check back daily for more zombie programming madness.

An Expressive Tool Unique to Games

2008-12-14T22:14:00.001-07:00

In order for games to become a valid and recognized art form, they are going to need to stop relying on the expressive tools of other mediums. All mediums, when they first come into being rely on the expressive tools of other mediums. For example, for the first period of their life movies were largely stage plays that were filmed. Then people discovered all of the unique things you could do with a camera that you can’t do with a stage play. Similarly, video games are often viewed as interactive movies, or interactive books, or interactive comics, basically an interactive version of some previous format. Eventually, we hope, game makers will figure out the expressive tools that they have at their disposal and put them to good use. Today I wanted to talk about what I thought could be a particularly powerful expressive tool, unique solely to games—alternate timelines.

For the most part the other mediums, if they even include time as a dimension, are strictly one dimensional. No matter how they are presented there is only ever one way that the events occurred. Occasionally a work will dabble in with this, showing what could have been had a single choice been different, but it isn’t common. Games however have vast potential in this area. As the player moves through a game world, making decisions they are changing the narrative landscape, and bringing the story to a place uniquely their own. Each time they play through they can see a different aspect of the world, and see what effects a different decision would have brought.

Imagine a game where the player is trying to save a town from a disease. On the first play through they work tirelessly to overcome the disease. The disease spreads viciously, claiming a good portion of the town, but in the end they beat it back and triumph. This could be a story about the power of humanity in the face of terrible hardships. On the second play through, they play in a more relaxed manner, and discover that the disease doesn’t spread as viciously. Over many play throughs they come to realize that the spread of the disease is connected to their efforts to fight it, and the game becomes instead a story about the need to relax and accept our position in nature. The true nature of the game world only becomes clear after the player has gone through the game a couple of times, and seen how their choices affect the events of the story.

This adds another dimension to storytelling. Almost the way sculpture adds another dimension to paintings or photographs. It doesn’t necessarily make it more expressive, but it does offer a powerful expressive tool that is not as readily available to other forms of art. I believe that this will be a key technique as we learn to give video games their own expressive voice.

Game Length and Narrative Power

2008-12-07T21:18:00.000-07:00

Let me describe to you what I believe the best format for a narrative game would be. First, a first time player would be able to be played through the game in around four to eight hours, with the length depending largely on the scope of the story being told. Second, the game would be broken into chapters, or acts, with each act taking around one and a half, to two hours to complete. So far what I’ve described sounds like a short novel, or a long movie trilogy. Playing through a game of this kind sounds like it would be about the same as watching the Lord of the Rings trilogy, or the Star Wars series. But here’s the difference: to make the most of the interactive medium, these games would need to tell stories interactive enough that the player could play through them three or four times and have radically different experiences each time. I’m not talking about different meaning the first time I shot everyone on sight, and the second time I snuck past everyone. Or the first time I chose the evil dialog tree option, and the second time I chose the good dialog tree option. I’m talking about differences where the entire meaning of the story is changed from one play through to the next, by seamlessly integrating each of the player’s actions into the story, and reacting to those actions in an intelligent way.

That is where we will see the true power of interactive storytelling, each play of the game will render a different experience, but each shedding additional light on the story’s primary theme. As the player chooses different approaches to the game, the narrative would change and reflect the game creator’s views on the subject. Each play-through would show a different aspect of the story, with it a different view of the designer’s vision. Additionally different characters could be used for subsequent play-throughs, allowing the player to see the same events from a different perspective, and gaining even more understanding into the importance of what happened in the game. In this way the interactive nature allows the author to speak more clearly, not just showing or telling the player how they feel about the world, but actually making the player experience it.

There are a couple of reasons why a game of this type would have to be kept short. First, replayability. A game that takes forty or so hours to get through is going to be a difficult to play through multiple times. Further, at forty hours there is just too much story for the player to remember and be able to contrast across different play sessions. Second, development costs; highly interactive stories are very difficult to make, which is why a lot of games are very linear. In order to create a game story that is able to support player influence, it needs to be shorter than the average game. Fortunately, the cost of creating a deeply interactive story will be offset by savings in art assets. The player would still experience forty or so hours of play, by playing through to experience the different facets of the story, but each one would be done with the same art, meaning that the game would require around a quarter of the art a typical game requires.

In the end a game narrative that really allows the player to author the story with their choices would be much more compelling and satisfying than a linear story that lasted even four or five times longer. But more importantly, such a game would be able to be truly artistic in conveying important themes and ideas to the player. Such a game would be more than just an interactive movie, or mindless diversion, it would be a culturally relevant piece of artistic expression—that also happened to be a video game.

Games can be used to teach specific skills or knowledge

2008-03-21T09:27:00.000-06:00

I've been meaning to start a blog for a while now, but I decided it was time because of a desire share my opinion on a post on my sister's blog. I thought it might go long, and didn't want to clutter her reply page.

The gist of her post, if I read it correctly, was that educators are excited to try and use games to teach children. But this can backfire when the 'game' that the children are playing isn't fun. The children, having been expecting something fun because it was called a game, now rebel, and don't have fun or learn anything. And so it perhaps is better if we shy away from using games, and stick to research proven methods of teaching children.

First, I think we need to define what a game is a little better. Defining a game as an activity that is enjoyable works a lot of the time, but it's a little too subjective. I tend to think of a game as a system of rules, with a goal, and it may or not be fun. Most of the games used in mathematical game theory are very interesting to look at, but wouldn't be much fun to play.

Using this definition of a game, games always teach. Given a system of rules, and a payoff, an intelligent agent will always find the most efficient way to use the rules to maximize the payoff. This is used a lot in AI, where you have to be careful about how you structure the rules and payoffs, otherwise your agent will end up doing something other than what you want, while maximizing the payoff.

Similarly a person, given a system of rules, and an appropriate incentive will learn how to work within the system to get the best results. This often leads to exploits and game breaking behaviors when there are errors in the game, but that's a discussion for another time. The point is that a person will learn the best way to get the best results from the game.

We can use this by creating games that mimic real life systems, then as the players learn the principles needed to maximize their results in the game, they will also be learning skills and principles that are applicable to the system that the game mimics.

For example, we could create a game that simulates running a small business. By simulating the different aspects of running a real business, players would gain an intuitive feel for how to run a business. Combined with traditional classroom study of the subject, games could provide practical experience applying the things that are learned in the classroom, and improve both comprehension and retention.

The trick then, would be to present such activities as learning activities, not as games. Because they could be pretty enjoyable when put next to other learning activities, but when compared with other games they wouldn't be nearly as fun. By presenting them as learning activities rather than games we wouldn't have to worry about the students rebelling, instead of being forced to play a boring game, they are being allowed to do a fun learning activity.

So games have the ability to make very good learning tools, but we probably need more research both into learning strategies, and into game development to find the proper ways to teach through gaming, and the best ways to combine gaming with traditional classwork. Until then, don't discount the possibility too quickly.