As a fan of Douglas Adams since I was a kid, there was very little chance of me not partaking the Towel Day Mini-Ludum Dare. I find it really interesting that Mini-Ludum Dare#42 happened to occur just in time for Towel Day but as Douglas Adams has repeatedly said "42 seems to show up a lot." For those not familiar with The Hitchhikers Guide to the Galaxy, 42 is an important number as it happens to be the answer to "life, the universe, and everything". I decided to take the challenge a bit further and make it a Towel Day challenge instead of a weekend challenge. Here is my postmortem.
What Went Right
Making Towel Day an important part of the project was my personal goal of this challenge. Technically, the theme was "Earth will be Destroyed" to make the challenge accessible to those sad souls who are not Douglas Adams fans. I managed to incorporate the reason Earth is being destroyed, a two headed alien, adding nutrient enrichment to a towel, towels and 42 . Not too bad for a rushed project.
What Went Right and Wrong
The decision to create the game on towel day was a mixed blessing. A game jam is short enough without artificial restrictions. In this case there simply wasn't enough time to add sound and other minor gameplay enhancements such as an unlimited mode. Time limits and other restrictions do help build creativity and let you refine your skills so the extra self-imposed restrictions are useful. To be perfectly honest, though, the real reason for the extra restrictions were the emotions related to creating a game on Towel Day.
What Went Wrong
Thursday, May 30, 2013
Thursday, May 16, 2013
When I heard that Oracle is changing their Java numbering convention because all the bug-fixes in Java are causing them problems with their existing scheme, the idea of porting my older Java games to HTML5 gained a lot higher of a priority. While the Canvas is simply not quite there yet, for the games that need to be ported it is more than adequate. I started porting the Ultimate Retro Project as a bit of a test project. Right now my results are mixed. I am using the CreateJS library instead of writing my own low-level library. This gives me the advantage of a class library that is similar to the Flash class library that I am familiar with but the disadvantage of a library that is a work-in-progress.
Unfortunately, there are quite a few old Java games that will need to be ported, so this project will take quite a while. At the same time, I am starting to port my GameJam library to HTML5/createJS and will hopefully start working exclusively in HTML 5 for my web games. I am going to be adding quite a bit of functionality to my GameJam library as I port my older games as there are many classes that can be broadened and added to the library.
In addition to playing around with createJS, I am also starting to look into WebGL. Rumours of Microsoft caving in and supporting the standard would be nice if they turn out to be true, but I have a functional canvas ray-caster that I can always fall back on so a certain series of games will yet again be revisited and hopefully this time I will get around to actually finishing the 5th and 6th instalments.
Thursday, May 2, 2013
While I did not particularly like the theme of Ludum Dare #26 as it was far too general, I did have Saturday free to work on so I created a quick game. To me minimalism means eliminating all that is unnecessary. For games, this means graphics and sound. The idea is to focus on the essential gameplay. Loot Run is a platform game done entirely with text.
What Went Right
Keeping with the theme, I wanted to keep the gameplay as simple as possible while still being fun. While scrolling would have been easy to do, keeping levels limited to a single screen seemed to fit the theme better. The player needs an objective. Collecting money is a very obvious motivation and is something that most players can relate to. Having just the environment as the obstacle did not seem like enough so monsters were added. While the original plans called for title, instructions, winning and about screens, it became obvious that these things could be integrated right into the game levels.
What was Both Right and Wrong
What went Wrong
The controls for the game were probably the biggest problem. The method I used was to track whether keys were up or down and during the main event loop adjusting the player based on the keys. For most games this would be fine but because I am only updating the frame every 150ms this can result in too big of a lag between the players key press and the processing. For instance, if a player hits up to jump and releases the key within the 150ms it is possible that the jump will be missed. What I should have done is had an array for next actions as well as key states. The next action would have been set as soon as a key was pressed, and every interval the actions would be ORed with the keys that are still down.