Now … to the keynote !

(Too creepy ?)

You can play it in it’s current incomplete state here (requires Flash).

I’ll take the opportunity to give myself a crash course in Flixel to make this, methinks. Now for sleep.

This could turn out to be a handy tool for those last minute sound effects (although for me, sfxr does just nicely) .. except it seems to lack a save-to-WAV function …

Chances are, everyone is far too busy judging the record number of on-time entries this year .. but if you are curious, you can see the details and play the game here.

In about 5 mins I decided to write a simple game based on the garbage compactor scene from one of the Starwars movies.

2 hours on the train from Florence to Rome, I wrote most of the engine in Processing on my little Eee PC.

Then I went and saw the Colesseum, Pathenon, Trivi Fountain etc. Walked lots, slept well.

Then, on the plane from Rome to Hong Kong I intended to finish the game … problem – the power sockets on the plane were malfunctioning, so I only had 2 hours of laptop battery.

Result: I’m here in Hong Kong, without a compatible power adapter, and an almost ready game stuck on my flat laptop. Ah well … it will be late.

Pic of eaten airline food (too hungry to wait):

http://twitpic.com/3mkn9

Ciao for now !

After my LD #11 ‘Minimalist’ entry was voted “most innovative” game, I’ve been trying to pride myself as “that guy that makes innovative games”. So I thought long and hard about the theme for LD #13, “Roads”, trying to come up with something innovative. But the creative juices just weren’t flowing, and it didn’t happen (I’d also just bought Shaun White Snowboarding: Road Trip for Wii, which was taking time away from ‘designing time’). After 12 hours, with no good ideas for a game I was actually enthused about making, I decided to make a simple Frogger clone – at least this way I could hone my Processing skills, and learn the ins-and-outs of Mobile Processing.

Some thoughts about developing for mobile devices

Turns out there is a whole “other world” of mobile development that I just hadn’t really thought all that hard about.

I’d assumed that the whole write-once-run-everywhere thing would have been done properly for Java on mobiles. J2ME (and by extension, Mobile Processing) would have some sort of smart abstraction layer that makes things behave gracefully across various phones … right ? Wrong. Not so. It has become clearer to me now why J2ME MIDIlet development can be a royal PITA: significant differences between devices – screen resolution and aspect probably being the most immediately troublesome. This will more than likely apply to Android powered devices too, which once they start arriving en mass with various random specifications next year. The Android SDK deals with heterogenous devices in a cleaner fashion, via seperate “resource files” (which looks like the J2ME Polish approach ??), but it still leaves the developer to make sure variations between devices are dealt with. The iPhone, despite having far less handsets out there in the wild compared with J2ME capable phones, has a distinct advantage for developers at the moment … you are essentially only targeting one device (okay, maybe two if you count the original non-3g iPhones, or three or four if you include iPod Touches). That said, no one would be silly enough to believe that future versions of the iPhone will have the same screen geometry and capabilities, so I think the problems have really just been ‘delayed’ for iPhone developers. It will be interesting to see how these problems are dealt with for something like, say, the iPhone Nano.

The Processing language for games

While Processing was designed as a language for coding visualizations, it has pretty much everything you need to make simple games; graphics (bitmap with transparency, vector graphics, even OpenGL 3D), mouse, keyboard and joystick input, and sound (samples, MIDI, basic synthesis, via the minim library, among others). Since it’s actually just a layer built on top of Java, you can also do some more advanced things by incorporating regular Java code, outside the scope of the simplified “Processing” language. Things like collision detection are missing “out of the box”, but rectangular collision detection isn’t tough to whip up yourself. The weakest link is probably the sound support, which seemed a little flaky for me – samples triggered via minim seemed to have some unavoidable lag (others have reported similar issue on the forums). Overall, I’d say its still a fair contender against something like Pygame for quickly mocking up little games. One advantage of Processing over Python programs is that stock-standard Processing IDE can produce executables for Linux, Windows, Mac OSX and a Java applet with about three mouse clicks, no matter which platform you are actually running it on. I searched but didn’t find a decent ‘game framework’ for Processing – someone (maybe me) should write one, since it could do with some convenience classes and functions.

Mobile Processing – what happened to my floats

Mobile Processing is very similar to the core Processing language, but it can export applications as J2ME MIDlets which can run on Java capable mobile phones. I started writing my game in Processing, then ported it over to Mobile Processing. One thing that is missing in Mobile Processing: the float data type. In my simple game, it wasn’t too hard to just change my floats to ints, and with a few tweaks to deal with rounding errors, everything worked okay. But if you need floating point calculations, there are some tricks to deal with arithmetic of fractional values. Mobile Processing is lagging slightly behind the recently released Processing version 1.0, but most of the function name changes are trival (eg, framerate() vs. frameRate() ).

The collision detection issue

A few people have commented that the collision detection in Badass Frog isn’t great. Well, that’s not a bug it’s a feature . No seriously, it started as a bug, but then I realized that it nicely gave the illusion of making the frog only vulnerable if it was run over by the wheels of the car. But, it probably doesn’t match the expectations of the player, and so feels buggy; lesson learned … cool ‘features’ (aka serendipitous bugs) may not be so cool if they don’t adhere to pre-estabilished conventions and just confuse/frustrate the player.

Conclusions

So, the game I’d produced after 48 hours was extremely basic, and probably not worth more that ~ 1 min of anyone’s time. I did deliberately tweak the difficultly so it ramped up quickly … I figured it was better to kill the player before they gave up out of boredom. As is always the case, I could have done a lot more with it (online high scores, the classic “river with logs” instead of just roads, bonuses ?), but instead got caught up in technical issues; playing with the sprite sizes / layout to get a version that could work on many screen sizes, and getting sound to work in the mobile version. The result was that I learnt a lot about the issues involved in developing for heterogenous mobile devices, but didn’t have much of a game after 48 hours. Summary: simple game, but learnt lots. I’m pretty happy with that.

+ cheezy music ….

Meh. Here it is, my final LD48 #13 entry: “Bad Ass Frog Escapes from LA“.

Get it here, for five different platforms. If you have a Java-enabled phone that can do a resolution close to 240×291 (aka, not an iPhone) you can try the mobile version at http://is.gd/aDRQ .

Tools used:

• The GIMP.
• Sfxr.
• Processing and Mobile Processing, Java Wireless Toolkit.
• Nokia 6320 phone.

Postmortem later.

Lunch on the last day: Wholegrain bread, garden salad, beetroot dip, Danish fetta and pickled onions. No swine fleisch this time.

Journal

Worked on getting sound going this morning … settled on using MIDI drum hits as sound on the mobile MIDP version (that’s all I could get to work), and some sfxr-generated samples on the desktop versions.

What my game lacks in graphics, scope and fun, it will make up for in supported platforms. I’m preparing to post my final entry, which should support Linux, Windows, Mac OSX, any Java-capable web browser and any decent J2ME enabled mobile phone.

Journal

Here it is running on the Java Mobile Edition phone emulator (“Default Color” at 240×291 resolution). I’ve heard people complain about how making MIDP phone games is tricky because you have to deal with lots of different screen sizes/resolutions. It truly can be a pain in the butt, and I haven’t dealt with it properly in this game … on my 128×128 Nokia 6230 the sprite positioning is out of whack, and I don’t really feel I have the time or energy to go back to square one and fix it to work at any resolution. So at the moment it will only be reasonable to play on largish screen phones. I may try to make a special 128×128 version tomorrow, if I get time (basically, I’ll start by shrinking the sprites). I’ll probably also release a non-phone Java applet version so people have more chance of playing it.

Still need to do sound.

Food

The “significant other” reminded me to eat a few hours ago. Looks like I got sidetracked … haven’t eaten yet. (Update: I just ate a banana. No photo, since it looks just like the banana in my last food photo).

Food

Didn’t really have a breakfast. Guess I should have photographed the cup of coffee and the Gingernut biscuits.

Pictured above – Lunch, ~23 hours in: Salad roll with beetroot tzatziki (otherwise know as Pancar dip), with Danish fetta and the flesh of a pig. Banana, and instant coffee with one sugar.

Progress

Not much. Out of desparation, I started making a Frogger clone in Processing, the idea being that once it is functional, I can change some things to make it a little more than regular Frogger. We will see.

At some point this morning, I decided it would be nice to have a mobile version, eg Java J2ME / MIDP game that could run on most Java capable phones. Since there is Mobile Processing, designed for running Processing apps on phones, I installed Java Wireless Toolkit and Mobile Processing (the Linux alpha 0006 version worked for me, while the official 0007 Windows version didn’t. Go figure). I scaled down the sprites, made some porting tweaks (‘real’ Processing supports Java’s ArrayList, but it appears Mobile Processing does not, although I’m probably missing something), and set up the webserver to allow downloading of MIDP apps to my phone (hint: .htaccess needs the mimetype lines AddType text/vnd.sun.j2me.app-descriptor .jad and AddType application/java-archive .jar).

It runs ! It’s not really a game yet, but I still have time to turn it into something that resembles one. If anyone wants to try out this totally unfun useless version, you can get it here (at least for a while). The best way to get it is to go there using your phones browser, click on the download link, and it should install the game for you.

Zero tangible progress on the game. Thought about making a driving game (duh, obvious), drew a picture of a road for no apparent reason, did some research into SNES Mode 7, played with some Processing libraries for pathfinding and loading .obj format meshes. I’m thinking I’ll probably end up with some variation on Frogger at this rate.

It’s a cover of GBGames LD#11 entry, ‘minimalist’; turned evil. I like to think of it as a minimalist survival horror.

You can download maximalist and read more details here.

There is a gameplay video here … but it leaves off the surprise ending, so you still have to play the game .

The goal is to complete 25 levels an achieve the highest score possible.

Libraries used: Pygame, Rabbyt (including the pygame_font.py font rendering code), my (alpha) simplemenu library.

Tools used: The Gimp, Sfxr (DrPetter saves the day, yet again), Audacity, oggenc

I used a scanner to ‘photograph’ various objects around the house (including myself) to provide source images for further manipulation.

Assests: “Squealer” font by Ray Larabie, A scan of my face, A scan of a carved wooden ‘skull’ box on my desk, some hand drawn sprites (exit and glowstick), me screaming into the microphone.

Things I learned

Rendering fonts using the Rabbyt library is a little ugly unless you are using Pyglet for textures. I was using Pygame, so while I was able to use the pygame_font.py code which comes with Rabbyt to render fonts, it just felt wrong.

Source control (SVN) saved my butt this time. I was happily coding away, when I realized a few revisions ago the game performance had really dropped … constant slowdowns and jitters. I checked out copies of several revisions back and tested them to see at which revision things started to go all sluggish. Then, looking at the svn diffs (using Trac), I could see that it was my implementation of the score rendering code that was the likely culprit. Sure enough, making some sensible changes fixed the slowdowns … silky smooth gameplay again

I also learned that I perform better when I’m more relaxed … I deliberately choose a very simple game to ‘cover’ so I could focus more on graphics and polish, and I wasn’t even fully committed to completing the game this weekend. Taking a laid back approach really helped (at least it felt better).

Here’s a quick screenshot of where I’m up to.

These might turn out to be placeholder graphics (or they might just remain ). So far I have the basic feaures of GBgames original implemented, including the anxiety-inducing audio. I’m also adding a new spin on the idea … the enemies move a little, and can be ‘baited’ to coax them away from the exit.

(Also, sorry to release code so close to the start time … won’t do it for a ‘real’ LD … but for a mini-LD … well … better lateish than neverish).

LD#12: pansapiens timelapse

Congratulations to everyone who participated. I can wait to see what y’all have created ….

Some post mortem thoughts

• Use remotely hosted version control. My Subversion/Trac server runs on my workstation … which left me without access to my code when we had a several power failures. If the code was remotely hosted, I could have quickly found some electricity and Internet access somewhere else and continued working on my laptop.
• Take some time to think through implementations, write some notes.. I fairly quickly got a good idea for a two-player falling block game, where players competed to build the biggest tower, but could lower their opponents tower by shunting across matching blocks, which would annihilate each other. But I failed to think through exactly the best approach for the falling block game engine. I coded and discarded about three related but similar approaches, toyed with using the pymunk physics engine for a while (couldn’t get static Polys to stay still though …??), before basically giving up on the falling block engine after the second power failure. If I’d sat down and really thought the engine through before coding, I probably would have finished the game I originally intended to make.
• It’s nice to have a fallback. Normally, I would make my fallback plan something like “okay, no time left, just polish now … no new features”. But that assumes you have a turd to polish. In this case, all I had about 12 hours and a useless pile of crap falling block engine that I didn’t understand anymore. Writing an Atari 2600 game would be a crazy ‘fallback’ if it was done in the traditional way: assembly language. Luckily, batari Basic is pretty much like a normal version BASIC, just more restricted (with a slightly fussy, touchy preprocesser/compiler). It’s been years since I coded in GWBASIC … but you never forget the basics
• It’s about writing a game from scratch in 48 hours and having fun. (and maybe owls). I did have fun this LD, but I also stressed out a little bit too much for something that was supposed to be mostly fun. The power failures were putting me on edge .. even so, I’ve gotta relax and ease off on the coffee next time.

It’s a game for the Atari 2600 VCS, but you can play it here in a browser based emulator. There is also a zip for Windows, packaged up with a standalone copy of the excellent Stella emulator, including the ROM. Hint for Debian/Ubuntu users: sudo apt-get install stella. For a laugh, take a look at the ugly source code.

Back in the day, every great Atari 2600 game had a back-story (to help you enhance the incredible graphics using your incredible imagination). Be sure to read the all-important cheezy back-story.

Tools used:

• batari Basic and it’s excellent manual.
• PlayerPal 2600 Sprite Editor

You may notice that my journal entries don’t really reflect the development process of this game. After a combination of electricity failures slowing me down, and my realization that I don’t actually know the best way (or rather, any way) to code a decent falling block game, I decided to try something quick in batari Basic. I’ve never coded it before, so I’m really stoked that I even got this much done. It would have sold a million copies in 1981. If you’d asked me at the beginning of the competition “Which is ‘easier’, Python+Pygame+Rabbyt or batari Basic ?“, I would have said Python+Pygame+Rabbyt …. I would have been wrong. Despite only having space for ~ 26 single-byte variables (+ a few bonus, if you are tricky), you can do quite a lot in batari Basic (and I had ~10 variables to spare !! Imagine what I could have done with those !!).

* 100 % Owl free. May contain nuts.