Kloonigames

A little bit over month ago I released my third experimental done-in-under-7-days game: Pluto Strikes Back. The game has gotten a very good response from players and it’s a game that even I still enjoy playing. Here are some of things I learned from the development of the game.

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.

I proudly present my fourth done-under-7-days game: Cacodemon’s Barbecue Party in Hell. Actually it’s my first Game-In-A-Day (GID for short) game. Not surprisingly, the idea of GID is to create a game in day. To be honest I did cheat a little, I created the game in the course of four evenings and the total time spent on the development is 23 hours 30 minutes. So in theory its done in a day. Well anyway it’s done in under 7 days and that’s what matters to me.

Cacodemon’s Barbecue Party in Hell

Download
Cacodemon.zip (5.2 Mb) (Release 1)

Instructions
Mr. and Mrs. Cacodemon are organizing a barbecue party in hell. Unfortunately that means there’s some work to do. You play as Mr. Cacodemon and you have to pluck and grill the kittens.

To pluck the kittens you have to spin them in the air rapidly. After all the hair is gone, throw the kitten in the hell grill (the opening in the left side of the wall) for even better score.

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

Credits
Game Design, Code & Gfx: Petri Purho ( petri.purho (at) gmail.com )
Music: Evil Horde – Hangarmageddon (e1m1). Big thanks to Evil Horde (Janne Roivainen) for letting me use his song for the game.
Sound Effects: kitten_burn.wav: The Recordist and the rest from Noise Collector’s aNiMaLs -collection, licensed under a Creative Commons Sampling Plus 1.0 License.

Thanks
Physics model is based on Markus Ilmola’s tutorials.
Inspiration source: Experimental Gameplay Project.
Cacodemon’s Barbecue Party in Hell uses: SDL, SDL_Image, SDL_Mixer and SDL_RotoZoom

I’m in the middle of development, so just a quick note. I’ve uploaded all my games to Pjio.com, so they can now be played online. I hope that I can find some new players for my games, since from now on you don’t have to download and extract the zip files. Even though Pjio.com requires for you to install a plug-in I think it’s a bit easier for the not-so-tech-savvy players.

Here’s the links to my games on Pjio.com:
Pluto Strikes Back
Slimy Pete’s Singles Bar
Jimmy’s Lost His Marbles

In the Pjio.com related news, the founder of Pjio.com, Tim Fisher created a fun experimental game in 4 days called Part One. Check it out, it’s a fun take on the swarm shooter idea.

The feedback on Pluto Strikes Back has been surprisingly positive. So I thought I’d write a little bit about what’s up with Pluto.

There’s a new version of the game (Release 1.5). It fixes the “endless” score bug and makes the game a bit easier to gasp. It also makes a lot of the content modable. The new version can be download from here. Or if you only want a quick patch download this file and extract it on top of the older version of Pluto Strikes Back.

When you have downloaded the new version I recommend checking Pluto Strikes Back’s first mod by Felekar. You can download it from here (just extract it on top of Pluto Strikes Back). It changes the game by increasing the gravity of other planets. The end result is very fun and very different Solar System to play in.

Pluto Strikes Back can now also be played online. Thanks to pjio.com. So if you haven’t played the game already go to pjio.com and try it online for free. I’ll soon be uploading all my games to pjio.com (I’ll try to do that on Monday).

There’s also a gameplay video of Pluto Strikes Back on Youtube.com (Thanks to Seebee). So everyone who doesn’t want to download or play the game online can see what the game looks like in action.

Some time ago I published the Articles About Rapid Game Prototyping post. When I wrote it, I didn’t intend to write a sequel. So I didn’t hold back any links. After I published it I stumbled upon few new resources. The list quickly grew into a bigger one (thanks to Lost Garden) and now I think I have enough to justify a new post.

Last time the articles where mainly about software game prototyping. There where only two articles that touched the delicate subject of paper prototyping. Even if your not interested in paper prototyping or board games I recommend reading the articles about them. They contain a lot of useful information for anyone creating a game prototype in any material.

Casual Games Design – Building A Prototype
http://www.casualgamedesign.com/?p=17#more-17

A very good article about why you should prototype and what kind of different prototyping options you have. I tend to go for the Program a Prototype -section, but I’m starting to get more and more interested in “paper” prototyping. The only type of prototyping not listed there and probably the most used in the (casual) games industry, is the Prototype With an Existing Game -type. In which the game designer plays some over-1-million-copies-sold type of game to prove that the game mechanism works (or at least sells well).

Board Game Designers Forum – Prototyping
http://www.bgdf.com/tiki/tiki-index.php?page=Prototyping

I know that your all wondering why I listed a board game prototyping article here. The reason is that in this small article is the best answer I have read to the question of why graphics matter in prototyping and why they don’t. Generally from what I have read there seems to be two extremes in the prototyping guides. Other end says that prototypes don’t need graphics, because it takes more development time and doesn’t replace missing fun. Other end says that the prototypes live longer and are more useful if you put in the extra hours for the graphics. The small article cleared my head and explained to me the good and the bad of graphically intensive prototypes.
I recommend digging trough the Board Game Designers Forum, there’s a lot of good information directly related to computer game design and prototyping. For example read the Design Process part. It’s the best written article, that I have read about iterative design.

The Siren Song of the Paper Cutter: Tips and Tricks from the Trenches of Paper Prototyping
http://www.gamasutra.com/features/20050913/sigman_01.shtml

Here’s a great introduction to paper prototyping by Tyler Sigman. It addresses the common problems of paper prototyping: how to build cards, tokens and boards. Even if the practical aspects of paper prototyping doesn’t create a huge urge to read the article I recommend checking it out for the chapters that deal with benefits of prototyping and playtesting. The information in both of these chapters is directly related and easily converted to software game prototyping. But on the other hand if your seriously interested in paper prototyping I recommend reading Tom Sloper’s Lesson #20 Board Game Design. At the end of the article there is a great list of resources for the paper prototypers.

prototyprally – Conclusion
http://www.grapefrukt.com/blog/conclusion/

Martin did game in a week for six weeks and published his games in his blog. There are some very interesting games, Hovercrafty is my favorite. At the end of his game design marathon he published an article that sums up what he learned. I highly recommend reading it, if you want to create a game in a week. On his blog there are also postmortems for every game he did. They are rather brief for my taste 🙂 , but there are some good insights in those blog posts too.

Game Design Workshop – a book
http://img.cmpnet.com/cmpbooks/pdfs/1578202221_excerpt.pdf

A book by Tracy Fullerton, Chris Swain and Steve Hoffman, that I haven’t read. But luckily for us they published the prototyping chapter as a preview. The chapter is more about paper prototyping and it’s a good guide to the world of paper prototyping. There is an interesting example on how to paper prototype a FPS. There is also a section called Using Software Prototypes In Game Design by Nikita Mikros, which is of more interest to us software game prototypers.
Lost Garden: Common Game Prototyping Pitfalls
http://lostgarden.com/2005/08/common-game-prototyping-pitfalls.html

This is an extremely good article about the problems of prototyping that no one wants to talk about. But I feel that I have to comment some of the solutions.

The infrastructure of prototyping is a concept that I didn’t even think about before I read the post. But it’s true. You have to have some kind of “infrastructure” before you can start prototyping. I don’t think this infrastructure is only the engine or framework, but also the skills to use the engine / tool. I don’t believe that you can just pick an off the shelf engine and start prototyping. Even an experienced programmer has to get himself familiar with the engine to be able prototype quickly. When prototyping the programmer can’t spend time learning to use the tool in question. Spending time on finding how to do stuff can easily kill the momentum. Simple things can sometimes take days to figure out, so that why I think it’s very important for the programmer to know his tools.

I’d also like to comment about the hacker, architecture, genius programmer thing. I believe that a good programmer can change his programming style to fit the project. When I’m prototyping I haxor the code together. When I’m building my engine I put (too) much effort on the architecture. Of course there are programmers who cannot change their style of coding, but when your prototyping it’s important the realize that your not going the reuse the code. The most important thing is to get code up and running in the fastest (possible the ugliest) way possible.

Lost Garden: Article: “How to prototype a game in under 7 days” on Gamasutra
http://lostgarden.com/2005/10/article-how-to-prototype-game-in-under.html

Here’s Danc’s take on the Experimental Gameplay Project gamasutra article. There is a good description of building the toy first and putting the game elements on top of that. I used this exact method when I did Pluto Strikes Back. First I created a simple physics model and played around and found out what where the fun things to do. Then I made a scoring system that gives scores when you execute those fun things. I also added the health bar so that it’s not only a simple toy but a “real” game. In the end the line between a toy and game is scoring system and a health bar?

Lost Garden: Space Crack: A gift prototype
http://lostgarden.com/2005/10/space-crack-gift-prototype.html

A very good post about how to evaluate prototypes. This is something I want to start doing with my own prototypes. Only problem is that I fear that I’m too attached to my own games to tear them apart this brutally.

Lost Garden: Cheap custom whiteboards for rapid game prototyping
http://lostgarden.com/2006/05/cheap-custom-whiteboards-for-rapid.html

Just as a last quickie a good, cheap and easy way of doing paper prototyping.

That’s all I for this time. If you haven’t already read the articles in Articles About Rapid Game Prototyping post I recommend reading them through. If you have read them then I hope that this post gave you a new dose of inspiration for your prototyping experiments.
Btw. If you happen to know any other articles that I haven’t listed, don’t hesitate to contact me either by commenting on this blog or by mailing my at petri (.) purho [ät] gmail.com.