Kloonigames

Here’s a quick look on what’s going on in the world of rapid game development.

First of all my friend Juuso, (the author of the excellent GameProducer.net) has published his first rapidly developed game: Highpiled. It’s a physics game where your object is to build a very high tower from a bunch of boxes. Juuso cranked the game in 21 hours, which is pretty amazing. I’m glad that he has decided to publish the game. And while we are on the topic of GameProducer.net I also recommend you check out Juuso’s post about How To Create Games Incredibly Fast.

As an interesting side note, the game’s setup has the following phrase in it:

Highpiled is “blogware” which means in this context that if you like the game, it would be nice if you could write a few lines about it in your blog and link to www.highpiled.com from there. This is optional, but I’d appreciate your effort.

This was the first time I’ve bumped into the term “blogware” (used in this context), but I have to say that I think it’s a great idea. Up to this point I have just used the term “freeware” for my games, but maybe from now on I should use the term “blogware” 🙂

Another friend of mine Martin (of Grapefrukt.com) has released a new (flash) game called Flashpiper. It’s an addictive pipe twisting puzzle game, with an online high score. I hope to see more games from him during the spring.

The mother of rapid game development ExperimentalGameplay.com has a new competition coming up. It’s due to start at 5th of February and is guaranteed to bring a horde of cool new games. Who knows maybe I’ll take a stab at the competition (if I come up with a decent idea for a game that fits the theme).

Another cool experiment was conducted by the good folks of the Finnish game forum SuomiPelit.com. They created a game (in a day) for every day of November. The result was 30 small innovative done-in-a-day games. The almost complete result of their work can be viewed here. Unfortunately it’s in Finnish, but luckily the combination of screen shots and download urls is a universal language that every gamer understands.

I’d also keep an eye out for these blogs: Bonsai, Skooma Games and the2bears.com. Because the authors of these blogs have promised us rapid game development and I intend to make sure that they keep their promise. Even if it means that I have to personally track down where they live and start harassing them until they give up and create some more games 🙂

There are few things I never seem to get over with. One of them is the Cacodemon’s score mechanism (previous post on the subject) and the other one is Buffy the Vampire Slayer (I started rewatching the season one again).

Actually this is more of a very dry game design theory post about how different score mechanisms affect games. Cacodemon just happens to be the practical example. So if you haven’t downloaded the game already, you can download it from here. And click here to download the examples for this post (a zip file that includes three test exes). Download them now, I’ll wait. While your downloading you can study the highly scientific chart of how the different game modes have different skill vs score rates.

Now we can begin the boring theory part of this post. We’ll begin by examining how the score mechanisms affect the game in general. I agree with Danc of Lost Garden that score mechanism are a meta game mechanics that’s layered on top of the core game mechanism. The core game mechanism stays unaltered but a scoring mechanism can adjust the balance of the game and enhance both the fun and intensity of the core mechanism. A score mechanism can also punish players when they play poorly, but punishing players can easily make the game too difficult and frustrating for the players.

In Cacodemon terms this means that what ever the scoring mechanism is, the player still can spin and bounce the kitties (the core mechanism). Even if there wouldn’t be any kind of scoring, you could still punish the kittens from the bottom of your heart. You just wouldn’t get any kind of score from it, but you could still do it.

The Original Simple-o-Scoring System
In the original release of Cacodemon (the cacodemon.exe) there is the simplest reward mechanism possible. You score by throwing the kitties to the wall or by spinning them. You also get some points if you throw the kitten into the oven. There is no punishment if you happen to drop a kitty. You have ten cute kittens to go and the game ends when you run out of kittens. The kitten count is reduced if you drop a kitten into the pit bellow but also if you throw them into the oven. Only difference is that you get some points if you throw the kitten into the oven.

Because both the oven and the pit reduce your kittens the optimal way to play the game is to just bounce and spin the kitten for maximal points avoiding both the oven and the pit.

The funniest thing to do in the game is to whack the heck out of the small cats and this scoring mechanism encourages player to do that. But the game lacks suspense, because the scoring mechanism doesn’t really punish the player for failing. You don’t get that “Damn, I almost had it” -feeling, that you get from a more intensive gaming experience. And I feel that that’s the biggest short coming of this otherwise good and beginner friendly version of the game.

The Punisher System
During the development of the game I already tested this scoring mechanism and decided to go with the player friendlier system. In this game mode (cacodemon_test1.exe) you also get points for plucking and banging of the kitties, but you can only cash in those points by throwing the kitten into the oven. If you fail to do that (the kitten slips and plummets into the pit), you get a zero score for that kitten.

This scoring mechanism is surely going to bring some intensity into the game. The game gives the player the change to risk it all for a greater score. Keep on bouncing the kitten and it’s possible that you don’t get any kind of score or play it safe and throw the kitten into the oven the first change you get. I think it’s a nice risk to give to the player, because in the end they can only blame their own greed for their failure.

The problem with this scoring mechanism is that in practice it’s frustrating at least for the new players. A series of games with a zero score is surely going to depress even the most enthusiastic player. Even for the player who has been playing it for a while, the game can be a bit too difficult. Especially if they don’t take the risk consciously.

The Score Multiplier System
So if my original version was newbie friendly and the second one was for the hardcore players, wouldn’t it be nice if there was a way of combining the best of both systems. I think I came up with one and I also realized that I wasn’t the only one to use this system.

In this mode (cacodemon_test3.exe) there is a score multiplier that increases every time you throw a kitten into the oven. And it resets back to one when you let a kitten slip to the pit.

This way there is also the risk from the second system, but the punishment isn’t so cruel. Usually the new players don’t even bother with the score multipliers. But for the more experienced player the multiplier system gives a nice boost of replayability. And it also makes the make more intensive to play.

At least I hope it makes the game a bit more intensive without making it too difficult for the new players. I thought of adding this mechanism to the next version of Cacodemon’s Barbecue Party in Hell. So let me know what you think of it.

Little over month ago I released a small done-in-under-24-hours game called Cacodemon’s Barbecue Party in Hell. This is a little summary of what I learned from the development of the game.

There are two ways you can prototype a game. Either you have a very clear goal (and possibly a written design) of what your doing or you have a very vague idea and you pretty much make the game as you go along. Cacodemon was of the later kind.

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.

The new year is here and so is my fifth (I can’t believe it’s already fifth) done-in-a-week game. And it’s my first two player game, although there’s also a single player mode available. But the game is definitely meant to be played with your friend on the same keyboard.

Druid Soccer

Download
Druid.zip (3.3Mb) (Release 1)

Instructions
You take part in the ancient traditional game of Druid Soccer.

Rules: Try to push the big rock to your opponents goal and to defend your own goal. Who ever first gets 10 goals wins the match.

Controls:
Player 1: WASD
Player 2: Arrow keys.

Esc – Will quit the game.
Alt + enter – Will toggle fullscreen.

Credits
Game Design, Code & Gfx: Petri Purho ( petri.purho (at) gmail.com )
Music: The Dongas Tribe (and friends) – Farewell to Erin. The song is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 2.5 -license.

Thanks
Inspiration source: Experimental Gameplay Project.
Physics model is based on Markus Ilmola’s tutorials.
Druid Soccer uses: SDL, SDL_Image, SDL_Mixer and SDL_RotoZoom