OSX 10.5 (2.3MB)

It’s identical to the windows one. I had been meaning to tidy up both a little bit before this release, but I haven’t had time.

Also, I’d like to say that I had a lot of fun this competition and, though it took some not inconsiderable amount of time time, and also playing through what entries I could; some really beautiful stuff came out of this competition. I look forward to the next one…

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.

1. New name – Some people seemed to think BLDR was related to towlr, and some vowels would be nice.
2. Improved graphics – The art was meant to be “temporary”, but all too often in Ludum Dare temp art becomes final.
3. Modify to use the new library – save code space, etc.
4. More gameplay elements – at least a few, though I’ll try to squeeze as much as I can out of the basics
5. The roads – perhaps some changes to the way the road system works
6. Animations – so when you die you don’t just get teleported back to the beginning
7. Level editor – level editors are always nice
8. In-game instructions – in-game instructions are always nice
9. More levels – of course more levels
10. Enhanced menus – ways to access all the new features

And I think that’s it about now… time to get going! Comment!

Here are a few responses to some of your comments:

- Anyone who said there needs to be a restart button:
I fully agree, so I added one after the contest was over. There are also multiple difficulty levels in it.

- Anyone who said that it takes too long to load at first:
It’s because the sound files are wav, I’ll put them in ogg at some point. This loading time will only happen once, however, as it caches this data on your hard disk. So once you’ve loaded it once (basically equivalent to downloading it) then you won’t have to again for longer than half a second.

- Anyone who said it would freeze and suddenly rush forward:
I don’t know why I did this, but I definitely spent more time to get a dynamic frame rate going, instead of a fixed one. This was I guess to allow slow motion / ultra speed (you can see that easy mode is slower overall than hard), but I also wanted it to be able to adapt to any computer speed so it would be able to play effectively the same speed no matter what it was on, it would just skip frames. Unfortunately, when a ton of particles fly down this actually causes it to skip a bunch of frames. So I’ll either make it take a frame rate average for a longer period of time or I’ll remove this.

- In response to ondrew saying “I have to give technical 1 for the Java App Deployment stuff.”
I have no idea what you’re talking about and I don’t feel this is justified. Did you give me a technical of 1 because you just don’t like Java, or what? Java is a full fledged programming language and does no more for you than C++. I made it in Java because I prefer Java and because I’m on Mac, therefore it’s more accessible to me. Not because it’s easier or something. All of the technical impressiveness of this game (read: particle effects) would have been exactly as difficult on C++. It’s all using direct OpenGL access  which is equivalent in Java and C++. Please edit your review to explain exactly what you mean by “Java App Deployment Stuff.” Thanks.

- In response to Morre:
I totally agree with you, actually. It’s got sort of the basic gameplay in it but not enough variety to be one of my favorite pastimes. If you’re interested, you can try the post-LD version which improves the scoring a lot, adds in a harder (and an easier) difficulty, and also  fixes that score increase bug.

Thanks again, everybody! Hopefully my comments have been helpful as well.

With version 2, there are now 2 levels and a respawn feature. For anyone that had problems with the compo version, I don’t think it would be a problem to vote with this version if you only play level 1.

Enjoy!

http://impellerhead.com/gamedev/ld13_negativegeforce_v2.zip 4.0mb