Archive for the 'General' Category

Tiny Timelog

Monday, October 9th, 2006

Tiny Timelog 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 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 and the new official improved homepage can be found at .

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

  • Swapping between projects on the fly (through the /project command)
  • Autosave
  • Configuration file, which enables you to setup the working directory.
  • 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.

    Articles About Rapid Game Prototyping

    Monday, September 25th, 2006

    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]

    How Not To GID by Paul Malyschko

    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

    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

    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

    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

    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

    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

    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

    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

    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:

    “Though you don’t want to obsess, Todd said, “a little aesthetics goes a long way” toward making your prototype something that people will actually use. He called this minimal kind of design a kind of “coating on the aspirin””

    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.

    Tracking My Time

    Friday, September 15th, 2006

    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.

    Time Log

    Download (162 Kb) (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 If you end up fixing some bugs or coding some other improvements, I would appreciate a comment or a email (petri.purho [ät]

    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.

    The First (A.K.A. Worst) Post

    Friday, September 8th, 2006
    Usually, the first post of any blog is rather hilarious. The author gives a crappy definition of what she thinks her blog will be about. And there is the unfulfilled promise of frequent updates. After the first one there are only few posts written and after that nothing. As if the author had killed herself, because she didn’t get the amount of traffic she fantasied about.This blog will be no exception. First post (this) will give a crappy definition and then there will be few posts and after that a quick death. The Internet will be polluted by yet another dead blog.So my crappy definition and empty promise of frequent updates is: I will create a new game every month. And I will use the experimental gameplay “development model”. Basicly this means that every game I create I have to make within 7-days, they have to made by me alone and they have to test some new form of gameplay.

    I have my reasons of doing this. I think the most important one is I want to learn to create good games. And Im a huge believer of the more you do more you learn -school. Instead of working on a eternal MMORPG -project, I’ll release number of small games and try to make them the best I can. The other reason is that working on a games that will only take a week to create, gives me huge amount of freedom. I can experiment and test ideas Im not really sure about. If the game turns out be complete crap, I have only wasted a week. Compere it to this MMORPG -project. If it turns out to be shit, he has sacrificed his whole life for nothing.