Kloonigames

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

Few weeks back I released this ugly command line tool, that I mainly use to measure how much time I have wasted on this game development hobby of mine. I dubbed this tool cleverly as the Timelog. I never thought anyone else than me and the msn -bot would even download it. But apparently someone else did.

Last week I got an email from Didier Bretin, thanking me for the simple tool and suggesting some improvements. The improvements where of that kind, that I should have had them in the initial release. Like switching projects without restarting the application and autosave. So I ended up coding these features. I was about to announce the new version here on the blog, but then we got into this conversation about the future of the timelog. We came to the conclusion that turning the project into a real open source project was probably the best thing we could do.

So we did. The Timelog has now taken a life of it’s own as a real open source project, with sourceforge.net account and all. Huge thanks for all this goes to Didier, who actually set up the account, wiki, newsgroup, svn and fixed my hacky source code so that it actually compiles on other compilers than visual c++. We also renamed the application as Tiny Timelog, which actually describes the tool rather accurately.

The newest, or the first official version of Tiny Timelog is now available from sourceforge.net and the new official improved homepage can be found at http://timelog.tiddlyspot.com/ .

For those of you, who downloaded the last version the new version includes features, like:

But I think the best improvement is that the code is now on a svn -server, so contributing the project is much easier. Well, happy time tracking on the new and improved Tiny Timelog.

The second game I wrote, within the 7-days deadline. Unlike Marbles this time I ended up using all of the seven days. Slimy Pete’s Singles Bar was created for suomipelit.com summer game development competition. There where 147 attendants of which 35 managed to create a game. The competition was fierce and Slimy Pete came eight. The top three really stood out from the rest of the entries (I recommend you download the
winner: Soosiz, very fun and original game) and rest of the top ten where within only few points from each other (I knew I should have voted for myself 😉 ).

Little bit about the feedback I’m looking for
I’m inviting criticism, because I think it’s a very good way to learn and improve your craft. I hope you don’t put on silk gloves when treating Slimy Pete. Thinking “this is the way it should be, but he had only 7 days to do it”. On the contrary I hope the fact that it was done in a week encourages criticism. I committed only seven days to this game, so its not like I have been developing it for three years and go all berserk when somebody says it sucks.

I’m interested in your “user experience”. Did you have the “Oh I get it now” -moment? How long did it take? Was the game too easy or too hard? When did it turn boring? Or frustrating? What kind of a score did you get? When did you quit the game? Or did you finish it (there are 8 levels)? etc.

I’m also looking for critique on the game’s design. Look beyond the glittering graphics at the game’s core mechanisms. What wrong with it? What are the biggest problems? How could it be improved? Why it feels or doesn’t feel fun? etc. I’m hoping to tear the game into pieces Lost Garden style.
(Also Jimmy’s Lost His Marbles is all open for critique.)

Enough of words here’s the game.

Slimy Pete’s Singles Bar

Screen Shots

Download
Slimy.zip (4,8Mb) (Release 2)

Instructions
You play the part of Cupid. Try to match Jesse and Celine together. Do this by matching conversations. When you match three similar conversation bubbles in a row, they pop and Jesse and Celine move closer to each other. You can shut up a single person by moving cursor over them. If the bubbles hit the ceiling fan, Jesse’s and Celine’s conversation ain’t going so smoothly and they move away from each other.
Esc – Will quit the game.

Credits
Game Design, Code & Gfx: Petri Purho ( petri.purho (at) gmail.com )
Music: Isham Jones & His Orchestra – The Original Charleston
Sound Effects: Hell’s Sound Guy – BUBBLES POPPING.wav. The file is licensed under the Creative Commons Sampling Plus 1.0 License.

Thanks
Inspiration source: Experimental Gameplay Project and Suomipelit.com.
Some modified textures: Image After.
Slimy Pete’s Singles Bar uses: SDL, SDL_Image and SDL_Mixer

Interested in creating a game in a week? I mean who wouldn’t be. Everybody’s got great ideas for a game. Unfortunately you can’t design fun on paper. So the best way to see if a game is fun to play, is to create the damn game (or at least a playable prototype). That’s enough of an excuse for any game developer to be interested in learning the art of rapid prototyping. That and the fact that it takes more than 7 days to write the out dated 250 page design document that nobody reads.

I thought I would gather here a little list of articles about rapid game prototyping. These are from very different contexts and there might be some segments in these articles not directly related to rapid development. Even though the information might seem irrelevant its usually pretty interesting and useful in some way. If you know other articles about rapid game prototyping please let me know about them and I’ll update this list. Easiest way of contacting me would be to write a comment or to send me a email at petri dot purho [ät] gmail.com.

How Not To GID by Paul Malyschko
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5982

The first article on the list is about how to create a game in day. Or actually how to not create a game in a day. Game In A Day (or GID for short) is semi competition hosted by Garage Games, where you have 24 hours to create a game. It’s not really a competition as much as its encouragement to create games in extremely short time span. Article was written by Paul Malyschko and its about lessons he learned from trying to GID. It’s written more from a hobby game developer perspective, but the lessons told there are valuable to anyone trying to create a quick prototype.

How to Prototype a Game in Under 7 Days
http://www.gamasutra.com/features/20051026/gabler_01.shtml

The second article is the now classic paper by Carnegie Mellon students who started the Experimental Gameplay Project. If you haven’t read the article GO READ IT NOW. If you have read the article and your thinking about prototyping a game, go read the article again. It’s the article that inspired me to start developing experimental-done-in-a-week games.

Sol’s “rules” for surviving Ludum Dare 48h
http://sol.gfxile.net/ldsurvival.html

Third article is Jari Komppa’s (A.K.A. Sol) guide to surviving Ludum Dares 48 hour game development competitions. Because its a real competition, where you have only 48 hours to make a game, the article has a lot of information about managing the stress of the competition. That might not be relevant, when you have a week to create game and it’s not for a combo, but there’s also lots of info about the rapid game development. For example the 3.2 Design considerations -segment is all golden rule stuff.

How To Build a Game In A Week From Scratch With No Budget
http://www.gamedev.net/reference/articles/article2259.asp

Jay Barnson (A.K.A. Rampant Coyote) created a RPG in a week from scratch without a budget and without the help of any existing game engines. It’s impressive when you consider how content heavy genre RPG is. I’m just waiting for someone to do this with a MMORPG. The article is more of a development log, which is interesting in its way, but the real meat for us is at the end of the article: The postmortem, or the top ten lessons learned from developing a RPG in a week. Like the “Lesson 3: Don’t underestimate the art requirements”. Sounds like common sense, but I fell for that one.

Torque Game Engine Documentation – Step 4) Build a quick and dirty prototype
http://www.garagegames.com/docs/tge/general/ch02s05.html

This is snippet from the Torque Game Engine Documentation. There’s some general information about creating a prototype, experiences learned from Marble Blast’s development. At the end, there’s some more specific info about how they created Marble Blast’s prototypes using the Torgue Game Engine.

ALGDS – General Advice
http://www.algds.org/#Advice

Ad Lib Game Development Society runs these semi annual sessions where they create few game prototypes. It’s a little like Indie Game Jam. The link isn’t really an article as its more of list of random pointers they picked up during the development. It’s more concentrated on how to create a prototype with a team and how to host the event.

I know this isn’t directly related but for the sake of completeness here’s a link to Raph Koster’s blog, where he gives an interesting alternative approach to gameplay prototyping. There was also an interesting article about Paper Prototyping on gamasutra.com.

There was a lot of talk about prototyping in this years Game Developer Conference. Unfortunately I wasn’t there, but there is a nice trail of articles about GDC on the web from which I learned a lot. The Experimental Gameplay project guys gave a talk about “How to Prototype a Game in Under 7 Days“. What I understood from the blog coverages and the Power Point slides the information was mostly the same as in the gamasutra article.

But there were also developers from Maxis talking about their Spore prototyping experiences. Their talks where more from the perspective of why you should prototype opposed to how you can prototype, but its makes an interesting reading none the less.

Advanced Prototyping
https://www.cmpevents.com/GD06/a.asp?option=C&V=11&SessID=1914

Chris Hecker and Chaim Gingold talked about what makes a good prototype. Here’s the Game Spy’s coverage about the presentation and Power Point slides. There are some very good points even though its more from a professional game development teams point of view.

Pre-Production Through Prototyping
https://www.cmpevents.com/gd06/a.asp?option=C&V=11&SessID=1619

Also Eric Todd talked about what problems does prototyping solve for the preproduction. There is a good coverage by Gamasutra and here are the Power Point slides. Even though its more about how game designers see prototyping there are some good hints for creating a good gameplay prototype. Like:

That’s about all the googling and bookmarks I had on this subject. I don’t know if there are some other articles about rapid game prototyping, but I know that the BEST source of information about this subject is experience. So go and create a small game. It doesn’t (or at least shouldn’t) even take that much time. Less reading more prototyping.