The Development Process

Druid Soccer was published 1st of January 2007, but I started working on it already in October 2006. The game started out as a Mario-esque platformer game. I had some random ideas I wanted to test out, so I cracked together a quick prototype where I could test these things out. While testing out my Mario physics I happened to discover that balancing and bouncing a huge box on top of the player character was actually really fun. So I thought to myself, that if this balancing a box thing is fun, it would be twice as fun if there where two players. And thus Druid Soccer was born.

Well actually it wasn’t called Druid Soccer. The game lacked a theme. I tested the early prototype with my friends and got a very good response from them. Everybody enjoyed it, but it wasn’t until December 2006 that I started working on the game again. And it was then when I decided that I’d skin the game as a druid soccer.

What Went Right

1. Building the toy first
A blue-square-prototype of the game really helped me balance out and tweak little things in the game. And also I got to test the game with my friends and get some initial feedback on the idea. Something I rarely get to do with my prototypes. The game would have never been made if I hadn’t tested the early version with my friends. That’s the price you got pay for creating a two player game. The playtesting takes a lot more time and people, than it does in a single player game.

2. The simple but deep gameplay
Even though the game has a very simple idea and controls, the game has surprisingly deep gameplay. Because of the physics there are all these small cool little tricks that you learn to do. Ways to get the bolder out of your opponents grip, how to throw the boulder from the middle of the playground, etc…

3. The right theme
I think I managed to pick a pretty decent theme for the game. At least for some people it’s been the theme that got stuck in their head. I was also lucky enough to happen to stumble upon some really create Celtic Creative Commons music: The Dongas Tribe.

What Went Wrong

Even though I had lots of fun testing the game with my friends, the feedback that I got from the game wasn’t overly positive. I was actually little surprised by the feedback I got after the game’s release. Here’s why I think the game didn’t go over as well as I had hoped.

1. Two player game
I think the fact that the game has to be played by two players on the same keyboard, was one of the biggest reasons why the game got so little attention. The game has a single player mode where you play against the computer, but the AI is crappy, and it’s not the same experience to play it against the AI than to play it against your friend.

2. No Juiciness
The second reason I think is the fact the game has a serious lack of juiciness. There are no sound effects or particle effects or stuff like that. There’s very little animation and there’s actually no real award for making a goal. And also somebody pointed out that the game lacked my trademark, which is the big bonuses that drop from the top of the screen (as in Cacodemon and Pluto). I had too much trust in the original prototype, so I thought that game would be enjoyable even with out all that juiciness.

3. Too many nasty bugs
Unfortunately in the final release of the game, there are game stopping bugs. The physics model wasn’t stable enough with the fact that the players were teleported to their goal areas when they made a goal. I didn’t realize this in time, so the game had a bunch of really nasty bugs.

Conclusion

Overall the game is one that has a lot of potential, but I’m afraid that the single player version of the game doesn’t bring that out. The two player game on a same keyboard is always a hazzle to get working, but when you do it’s always fun. Druid Soccer is one of those games that I’d love to redo, so it would get the polish it deserves.

A year ago I played around with an example from a physics tutorial. In the example I could bounce and nudge blue cubes with my mouse cursor. I remember that it was awful lot of fun trying to balance a box on top of the mouse cursor. I ended up wasting hours playing around with that physics tutorial example.

Two months ago (one week before the turn of the month) I was wondering what game should I create for December. I remembered my experiences from the physics tutorial so I decided to design a game around balancing things with mouse cursor. Before I started the implementation of the game I came up with using Cacodemon as the main character, mostly because he was round (the physics model only supports cubes and balls) and because he could float (so moving him around with mouse cursor would be logical). The goal of the game I was to implement would be to sort souls (would fall from the sky) into different compartments.

With this initial design I launched into production. As soon as I got the basic implementation together I found out that spinning the “souls” was way more fun than sorting them out. So I knew I had to make that the primary gameplay mechanism. The reasoning behind this being that the more fun the primary mechanism of a game is, the funnier the game. So I kept a small design break (washing the dishes) and came up with the “spin the kittens to get their fur off” -design.

The plan at this point was to make a game where Mr. Cacodemon was working at the eternal soul burning unit. And everybody knows that kitten fur is the number one cause of pollution in hell. So kitten and their furs would have to be burned in their dedicated ovens.

It was very late in the development that I came up with the barbecue theme and decided to go with it.

So Cacodemon was definitely a game born out during the development of the prototype. The original idea was way crappier than the final game. And I don’t think I would have thought of the design unless I had stumbled through all these steps in the development (with an open mind to tweak the game design as I went along).

So the #1 thing that went right was to let the game its own course, not restricting it to the initial idea.

The #2 thing that went right was the momentum of the project. Ever since I finished Jimmy’s Lost His Marbles I don’t think I have really pushed myself to work on these prototypes as fast as I could. And that is usually a good thing, but most of the I just end up wasting the development time in the parts of the game where it matters the least: graphics. This time around I set myself to create the game in one day. This goal gave the development a very nice speed which meant that I focused on the stuff that matters: gameplay.

As happy as I am about the development smoothness of Cacodemon, there’s always the other side of the coin. The very tight schedule and rapid design changes also introduced some problems. The biggest being the very low gameplay meaning of the oven. The oven was a little bit of a left over from the initial soul sorting design.

The oven has a great potential for a nice simple risk/reward game mechanism. The player could decide to bounce around with the kitten to get a better a score (risk being they could drop the kitten) or they could throw them into the oven and get a even better score. The problem was that if I punished the player too heavily on not getting the kitten into the oven (not allowing her to get the score for that kitten unless she tossed kitten into the oven) I made the game too difficult for the beginners. If I didn’t punish the players heavily for not getting the kitten into the oven the reward you get for doing so seems very lite. I mentally wrestled with the problem for a while and decided to go with the beginner friendlier version.

Overall I’m pretty happy with the way Cacodemon turned out to be, the only thing that really pisses me off is that I didn’t think of naming the game as “Pussy Shavers from Hell” as Joystick suggested.

What Went Right

1. Toy First
Building the toy first turned out to be a very good idea. I created a very ugly physics toy, where I had some planets (blue circles), the bat (blue square) and I could launch asteroids (smaller blue circles) by a click of the mouse. And I used this toy to prove myself that the core mechanics where fun enough to build a game around.

I then spend almost half of the development time lubricating this ugly bugger so that it was even more smooth to play with. And toy turned out to be surprisingly fun to play with, unlike the toy that I created for Slimy Pete’s Singles Bar.

I then wrote down all the things that felt satisfactory to me in the toy. Like hitting a planet really hard so that collided with the other planets or managing to strike an asteroid so that ended up orbiting a planet. Then when I started working on the graphically intensive version of the game I made sure that the player would be awarded when he managed to perform these activities. The awards where in the form of sound effects, scores, animations and bonuses.

2. Juiciness
The game feels quite juicy. Credit for this goes to the fact that I did spend quite some time working on the basic strike an asteroid hit a planet sequence. I wanted it to feel very juicy. So I created a very simple spring system to pull the planets back to their original positions. This really did boost up the game and I think it’s the most important part of the juiciness factor.

Here’s a list of things I added to make the hitting of a planet feel really extra juicy.
Elements of juiciness in Pluto Strikes Back

• The already credited spring system
• The Candid Camera sound effects (when you hit a planet it sounds like it)
• Rising score message
• Running score counter
• The big bonuses that you get almost every time you strike an planet

Also the background song, which I encountered by pure accident, brings it unique flavor of spinning goodness to the game.

3. Let my baby take it’s course
The first two games that I did, I really prototyped the original idea that I had in my head. I didn’t want to change it or tweak it on the way, because basically I was creating a prototype of that idea. It felt like I would cheat if I changed my mind during the development. Pluto Strikes Back was different. It was much more like a series of prototypes than a one big one.

In terms of gameplay there was very little progress. The original gameplay idea turned out to be very fun so I kept it pretty much intact. Although all the bonuses where developed during the prototyping.

The story did change a little. As the original idea was from a weird dream I had. The player would defend Earth against an asteroid attack by swinging a baseball bat. But that really lacked a reason to try to aim the asteroids to something. Then I figured that maybe Pluto should play the main part, because of the all media coverage. That then quite easily turned into a game that was only about Pluto getting it’s revenge.

I think it’s good to let go of the original idea and let the development take it where ever it is going with it. Clinging too much to the original idea can really kill a good game.

Things That Went Avery

1. No real play testing
Unfortunately I couldn’t afford to use a industry leading QA department to test out my game. I mainly balanced the gameplay based on my own experiences. I should have used couple of friends as testers. In the past I have learned a lot from watching other people play my games.

The biggest problem was the too high gravity of Pluto, that caused some of the new players to get frustrated trying to get the asteroids out of Pluto’s gravity field. I didn’t realize that this was a problem until people started reporting about it at various game development forums. I then dragged a friend who had not played the game to my house and watched how he played. And that’s when I realized that maybe the Pluto’s gravity field was a bit too heavy.

After that I released a quick patch that fixed some random bugs, made the bat controls a bit more firm and eased on the Pluto’s gravity. The new players praised the new patch, but the hardcore players felt that it made the game too easy. Well, you cannot please everybody.

2. Bugs
There where some nasty bugs left in the game. The cause of this basically the same as the last items: no real play testing. The bugs where of that kind that the player would get unrealisticly big scores. Luckily it was quite easy to fix, but unfortunately it really twisted the comparing of the scores.

3. I ran out of time
With Pluto Strikes Back I really did run out of time. Luckily I managed to implement all the important features for the gameplay that I wanted (not including the destruction of planets). But some of the small things that I would have liked the game to have, I could not do in the 7 day limit.

Conclusion
Pluto Strikes Back was a prototype to prove that the core mechanics could work and where fun to play. Right now I don’t know what future holds for Pluto, but I would definitely like to continue the development of the game. Hopefully I have time to release a new version of the game that would include the much needed and desired highscore list.

Btw. Big thanks to everybody who downloaded and played the game. And even bigger thanks to all of you who took the time to write comments and suggestions about the game. The comments really motivated me (and still do) to work on the game further from it’s initial release.

Things that went horribly Wrong or Lessons I learned

1. Good Graphics Don’t Save a Bad Game
I know that your thinking that I’m a complete idiot, for having to make a game to realize this, when playing any Myst game would have told me this in a second. But when your in love with your own ideas, you don’t think straight. It toke me two hours to set up a very crude prototype of the core mechanisms (with recycled graphics from Marbles). I remember thinking that this isn’t all that fun, but that’s probably because the graphics suck. So created a bit better placeholder art. The game still sucked so I created even better art for it.

I should have realized that glittering graphics don’t magically turn my game into something playable. When I was developing Jimmy’s Lost His Marbles, I had a lot of fun playing around with the ugliest early prototype ever (with broken ui). From now on I’ll have to create the early prototypes with the ugliest graphics ever. Not wasting my devtime in the beginning creating the graphics, but I’ll spend it making the blue square prototype fun to play. As Raph Koster said in his great blog post 40 ways to be a better (game) designer:

Art enhances, multiplies, improves. It does not replace missing fun. If you can get to something fun with minimal presentation, it will get more fun with good presentation.

2. Player Has Too Little Control
The reason why the game isn’t fun to play, is that the player has way too little control over the events. In Slimy Pete’s there is no way to think ahead or make meaningful decisions. More experienced game designer could have known this even before making the prototype. I didn’t and I didn’t even realize it when I playtested the blue square prototype.

I know that seems like a very trivial thing, but I never figured this out before. Control is essential for a good game. Nothing is more irritating than playing an action game where the character doesn’t seem to respond to your controls. Or think of playing strategy game where the A.I. is actually running the show and you have no control. I busted my head trying to come up with a good game that gives the player very little control. I couldn’t figure out any. Games tend to give players more control than is logically possible. For example in Civilization the player has almost god like control over his nation. In almost any action game the player runs faster, jump higher, endures more damage than is realistically possible for a human. And there’s a good reason for all this. Control == (more) fun, artificial restrictions != (less) fun. Nobody likes when developers limit the number of saves, put in invisible walls or disable the ability to undress your female fighters.

3. Couldn’t bring myself to shoot the baby in the crib
As I said before, I fell in love with my own idea. I didn’t want to believe that the game was crappy, so I just kept on working on the graphics. Instead I should have just murdered the game brutally. No point in trying to salvage a broken idea. But killing your pet game idea turned out to be rather hard thing to do.

Before I started creating prototypes of my game ideas, I thought there is no point in prototyping because the games where already perfect. I had them figured in my head. Now I have learned that you cannot design a game in your head or even on paper. Because there is no guarantee that the game will be fun. You just have to test it with an open mind, with the mentality of molding it into something better. If the game sucks you have to be able to pull the trigger, kill the game, bury it deep and wait until lightning strikes and brings it back to life. Like Jason in Friday 13th. It’s possible that the day may never come when you figure out how to make the game fun to play. But at least now you are wiser. Knowledge hurts and that’s why I don’t want to prototype every game idea I have. I have build up the feeling in my head, of how much fun it would be to play the game. And I kinda want to presume that. I don’t want to kill them by testing with ugly graphics, because that’s not the way I see it in my head.

Sometimes it hurts when you have to bury your favorite child and you want to remember the game just the way it was in your head. Sometimes it’s a relief to know that the game will never turn out to be anything great. Don’t have to waste time dreaming of them.

What Went Right

1. Pretty Graphics
I’m kind of a proud about the graphics. I know the gameplay sucks, but I also know that the pretty outer shell can fool a lot executive kinda guys. Or to put it this way, it looks nice on my CV and I know that nobody who’s going to interview me for a job is going play it enough to realize the gameplay sucks.

2. I Made A Game That Sucks
Why is this a good thing? Well first of all I’m not one of those optimists that turn everything into a happy sunshining experience, I’m more of those cynical bastard kinda, but never the less I’m happy that I made a bad game. It’s liberating. When you try to create something new your bound to fail, embracing the possibility of failure will probably let me do even wilder (and possibly crappier) games. I’m no longer afraid to screw up, I know that I have done it already.

3. It’s Juicy
Compared to Marbles, Slimy Pete’s has a lot more juiciness. There is nice feedback for the player, in form a sound effects and graphics and it has a good feeling all around. To put it this the outer shell is much better than in Marbles but Marbles has that inner beauty that really matters.

Conclusion

In the post, the game comes out as more worst than it really is. It’s playable, but not enjoyable. But I’m happy that I made the game. I learned a lot from this one. Had a first hand experience of the things Experimental Gameplay Project guys wrote about. I would even recommend doing a bad game as a learning experience. (Or atleast, you can do as I did and dub your bad games as learning experiences).

This is a brief summary of stuff I learned from creating the game Jimmy’s Lost His Marbles. You can download the complete game from here.

What went Right

1. I Pulled It Off!
I fucking managed to do the damn game under 7 days. It actually took only 3 days, which makes Jimmy’s Lost His Marbles the first game (which I have been part of developing) ever to be released before its dead line. Maybe 3D Realms should hire me to program Duke Nukem Forever.

The reason why I put such a high importance on this finished-before-deadline-thing, is that it changed the way I will be developing games. Not just the experimental 7-days-deadline games, but the bigger buggers as well. Because now I know I can do a complete prototype of the gameplay within a reasonable time. This means that I don’t just have to speculate if a gameplay is fun to play, I can test it. That’s the reason why I think any game developer should give this thing a shot.

2. It turned out to be an OK game
Despite my fears and even though I say myself, the game turned out to be a rather good one. The gameplay was easy to grasp and it had a feeling of freshness, even through the underlying mechanism was as old as Charles Heston.

3. Timelog
I ended up using a simple timelog, thanks to Steve Pavlinas blog entry. This turned out to be a very good thing. The Basic idea of timelog, is that you write everything you do to a log, including toilet visits, coffee breaks and web surfing. Then at the end your day you can calculate how much time each task took. You can see that you have spend hours reading Buffy quotes and your coding is interrupted constantly by Irc. Besides collecting data of your time spent, it works as an invisibleboss standing behind you. The temptation to visit a Buffy fan forum is reduced hugely, when you know you have to write it down to a log. So I think the use of timelog was one of the reasons why I managed to do Jimmy’s Lost His Marbles in three days.

Here are some statistics on the time that I used. It took 37 hours to make Marbles and of those hours, 10 where spent on various breaks. On the diagram below you can see how my development time was divided. The big surprise was how much time the graphics took. And how little time I spend on the level design.

4. Good graphics
For a prototype done in three days, the graphics turned out to be rather good ones. Or at least good when considering they where made by a programmer. One of the reasons why I never got myself to test any prototypes was the graphics. Even if the gameplay was golden I never ended up downloading them because the graphics looked like something a 5 year old mutant child would draw in MS Paint. As Juuso pointed out graphics matter. This is one of the things guys at Experimental Gameplay Project changed: games done in few days don’t have to look like shit or Grid War.

What went Wrong

1. Level based gameplay
Even through the levels made Marbles feel more like a real game than just a cool toy, I think this was a bad decision. The reason is, that creating levels takes time. And in a project like this, time is the only resource you don’t have. And because the game is as fun as the levels are, balancing and creating good, fun to play levels is extra hard work. So I think I stick to the cool toys department from now on.

2. Too complex graphical style
The graphics looked good, but the creating them took quite a big bite out of development schedule. Creating the graphics took more time than hammering the code together. I think I could save a lot of time coming up with a fast to create graphic style. Like Darwinia.

3. No sound or music
This is the thing where I think I should have spend an extra day working on. Coming up with some Creative Commons music and sound effects and stuffing them into the game. Biggest problem was that the song that inspired me to do Marbles was copyrighted so I couldn’t use that. And I didn’t find a good replacement for it. So I ended up not using any music or sound effects.

4. Physics made player feel she was cheating
The biggest problem with use of physics in a puzzle game (or any other game for that matter) is that it creates the feeling to some player that they are cheating. This is especially true if they find way to complete a level, that was not intended by the designer. This is not necessarily a bad thing. Some players take huge joy in finding these things, other not that much. In Marbles this was a bigger issue, because the physics affected the way you finished a level. Finding ways to finish a level, not indented by me was literally cheating. Not really, Im just happy that my physics code worked so well that players could complete the levels.

Other issue that the use of physics caused was that, even if you removed the marbles in same sequence the end result was not always identical. Because of the physics there was sort of a luck factor involved. This reduced the puzzle factor and gave the game a more arcady feel. Someone suggested the use of high score, sorted by time it took to finish the level. I think that would fit Marbles well and enhance the arcade side of the game.

Conclusion

Overall Im very proud of Jimmy’s Lost His Marbles. For me it stands for more than just another freeware game. I proved to myself that I can create games that don’t take forever to finish and don’t slip from release dates. Hope you enjoy the game. For me it was a thrilling three days of development.