Tiny Timelog

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 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:

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

    Slimy Pete’s Singles Bar

    October 1st, 2006

    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
    Screenshot of Slimy Pete's Singles Bar Screenshot of Slimy Pete's Singles Bar Screenshot of Slimy Pete's Singles Bar

    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

    Articles About Rapid Game Prototyping

    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] 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:

    “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

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

    Postmortem: Jimmy’s Lost His Marbles

    September 11th, 2006

    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. One of Jimmy's Lost Marbles

    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.

    Nice excel diagram of my time spent
    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.

    ConclusionOne of Jimmy's Lost Marbles

    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.