Kloonigames

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.

I can’t believe I got mentioned on the Tales of the Rampant Coyote -blog. It’s one of my favorite blogs. I have wasted a lot of good development time because Rapmant Coyote. After reading his post about X-Com, I ended up playing that old time waster for two weeks. So I hold Jay personally responsible for destroying at least 14 days of my precious development time.

In the post, where Kloonigames was mentioned, Jay wrote about my use of time log and said it was something he would like to do more. As a thank you, for saying such a nice things about my blog, I thought I would release one of my secret tools that helped me create Jimmy’s Lost His Marbles: my Time Log application.

Download
Timelog_application.zip (162 Kb)
Timelog_sourcecode.zip (77 Kb)

After reading about time logs from Steve Pavlinas blog, I thought that it was a very good idea. But I knew I was too lazy to actually write a log on a piece of paper and organize entries into categories and add the hours up. It seemed like way too much work, so I wrote my own application that did the job.

I don’t know if my application has much value to anyone else, because the user interface is rather crude (that’s the reason why I also released the C++ source code), but it does the job. And its actually rather straight forward to use, once you get past the fear of using a console application.

How to use Time Log
The way I use it is, I created a folder on my desktop called “Projects” and copied the “timelog.exe” and “timelog_analyzer.bat” -files to that folder. Then I created a quick launch shortcut for the “timelog.exe”. Now when I work on something I want to track I launch the application. First it asks the name of the project (note that the name is cap sensitive) and if a folder of that name doesn’t exist it offers to create a one.

After selecting the project I just type the name of the task I’m working on, in to time log. When I finish the task, I just write the name of the next task.

When I need to take a break, I write “/break toilet”. When I return from a break I can just write the name of the task I’m going to be working on, or just type “/break”. Either case, my break has ended.

You find more commands (such as “/save” and “/quit”) with the “/help” command.

When you want to analyze your working methods, you can use the “/analazy” command, which generates a summary of your tasks from that day.

For a more complete statistics, you can use the “timelog_analyzer.bat”. It creates a excel compatible text file, from a given project.

I think that’s pretty much it.

About the source code
It compiled O.K. with Microsoft Visual C++ 2005 Express Edition. There’s no license on the source code: its public domain. For Time Log I used my own XML serializer and a very simple unit test framework. Both are included in the timelog_sourcecode.zip. If you end up fixing some bugs or coding some other improvements, I would appreciate a comment or a email (petri.purho [ät] gmail.com).

And please let me know if you know some other time log application. I know there’s one under development.

Happy time logging.

UPDATE 09-10-2006: Timelog has now taken a life it’s own as a real open source project titled Tiny Timelog. There’s a new version already out. And here’s the blog post announcement of the project.

Six months after reading the propaganda of Experimental Gameplay Project, I decided to give it a shot. I set myself to create a new game in 7 days. Beforehand that seemed just impossible. My experiences told my that creating, even a small, game takes months, if not years. So to do it in 7 days seem frightening. And not only the code, but graphics, music, sound, levels and all things included. I shit my pants even thinking about it and almost gave up. Luckily I realized that the worst thing that could happen (beside shitting my pants) was wasting a week of my life. I could do that easily with a Buffy the Vampire Slayer marathon.

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.

First game I wrote, within the 7-days deadline. Jimmy’s Lost His Marbles was more of an experiment of the development model. I just wanted to see if I could put together a game within a week. I managed to do it in 3 days. When I started developing the game, I wasn’t sure if the idea was experimental or fun enough. Almost gave up, thinking that it will probably be all crappy. Luckily I realized that the hole point of creating the prototype was to test, if the game was going to be any fun. And also to test myself if I could create a game from scratch within 7 days.

Well here’s the bugger.

Jimmy’s Lost His Marbles

Download
Marbles.zip (1,2Mb) (Release 1)

Instructions
Your goal is to destroy all marbles in a level. To destroy marbles click three marbles that are next to each other to remove them.
R – Will reset the level.
Esc – Will quit the game.

Credits
Game Design, Code & Gfx: Petri Purho ( petri.purho (at) gmail.com )

Thanks
Physics model is based on Markus Ilmola’s tutorials.
Inspiration source: Experimental Gameplay Project.
Jimmy’s Lost His Marbles uses: SDL, SDL_Image and SDL_Mixer