Kloonigames

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.

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.

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.