Kloonigames

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