Kloonigames

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.

This is the third done-under-7-days game that I have created. It was inspired by a very weird dream I had and the cruel treatment of planet Pluto. Or as it is now-a-days called dwarf planet Pluto.

I’m still looking for cruel criticism on my games, so don’t spear the comments.

Pluto Strikes Back

Download

The newest version
Pluto_r1.5.zip (4.4 Mb) (Release 1.5)

The original blog post version
Pluto.zip (4.4 Mb) (Release 1)

Instructions
What happens when a planet living on the edge loses its identity? It goes mad and releases its fury on to the unsuspecting solar system.
Your job is to control the huge baseball bat that is circulating Pluto. Try to hit the meteors so that they will cause damage to other planets.

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

Credits
Game Design, Code & Gfx: Petri Purho ( petri.purho (at) gmail.com )
Music: De Zwervende Keien (The Drifting Boulders) – Wooden Shoes In Tirol. The song is licensed under Creative Commons Attribution-NonCommercial 2.0 -license.
Sound Effects: from various sources: The Recordist, Tintagel’s Free Sound File Archive and Brandens.net.

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

Few weeks back I released a done-in-7-days-game by the name of Slimy Pete’s Singles Bar. The download link for the game is here. The game mechanism is actually rather crappy, but playing it might help understand what I rant here about. (For the record, before releasing the game here I knew it was a bad egg, but I didn’t want to over shadow the game by announcing my opinions).

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).