Chopper

Shoot-em up at its best!

During my college years (09/2004 – 05/2007) I was heavily into Game development. I had previously been spending a lot of time running a rather successful gaming community (TresCom) and gotten to know several highly talented people. Up until then I always wanted to become a game developer myself and figured that after a 3 years of business administration, I would instantly have the opportunity to follow that career path. Boy was I wrong; boy was I stupid, but nonetheless.

During this time, I began my work on a tiny project under the name of CHOPPER, which would be a milestone in computer graphics, sound and gameplay. A multimedia experience unrivaled by any other application on mobile devices… or so I thought. Of course, not having any real experience in the field of game design (well, not counting Trespasser ofcourse) the learning curve was steep and many problems had to be tackled.

I realized quickly, that in order to sell my fun little pet-project, which of course was not existent at that point, I would need to get it to work on all J2ME/Midp2.0 devices. Unfortunately for me, I later learned that midp2.0 was rather basic by itself and all the rather fancy graphics came from additional libraries that were proprietary to the vendors – each vendor delivering its own library. Furthermore, after a rather unsuccessful attempt of porting full-res videos to my phone, I had come across the fact that most devices were limited to 100-120kb of jar size – meaning that each application should rather not get any bigger than 120kb or it would not run on a huge list of devices.

The former was not really a problem per se, but meant that I would need to study the basics of visual graphics and implement a system myself, rather than depend on an already existent system. So I spent a rather long period of time, a few hours each day after class, on this matter until I came up with a routine for double-buffering, sprite-collision-detection, transparencies and alike. It wasn’t until much later that I found out, that at least the collision detection was already available on J2ME…

The latter however, proved a much more difficult problem altogether. 120kb is not much space. The images accompanying this very article for instance are already ~60kb each, so two of them would have used up all the space I got. And that would be without any written lines of code and I, naive as I am, wanted to add soundeffects, music, a splash menu, several weapons and enemies, huge levels and more! In addition, as mobile devices being absolutely in no way comparable to the power of high-end pcs, I always had to keep in mind that things would also need to be fast – who would want to play a 5fps shooter anyway???

In retrospect it doesn’t come to a surprise that this would soon prove to be a great teacher of efficient programming, but back then, former-me often felt the project to be rather tedious if not with some surprising realizations:

First – Sprite-Systems can trick the user into thinking that there is more than the eye can see. As for my game, this meant that I could really deliver huge levels to the user without anything ever being repetitive. For that I developed a tiny system that would build complete island-maps on behalf of a few sprites – each differing a bit their selves. I had some that were cornerstones and others that were plain blue water. Martijn Buijs created the tiles in such a way that they would never look the same, depending on the way they were rotated and aligned. This by itself gave me a backdrop as a neat setting for a game.

Second – If you want effects, scale and reuse them! After playing the game (yet without any opponents) I realized that a map itself was no fun, unless it seemed believable. So I wanted to add moving clouds for atmosphere. Placing the clouds was no problem, BUT and here comes the space-issue again, each tile would effectively use up much of what I had left. So, Instead I began using only a few clouds and scale them by repeating each pixel a couple of times, intersecting clouds would add their transparent values, thus allowing really thick cloud layers, as well as a few puffy ones. As for enemies: I already had my own player-model, so why not simply recolor the enemies? This could be done on startup and stored in the backbuffer, hence allowing the game to be much smaller in size and yet surprisingly random at times – neat, eh?

Third – Gameplay is key! And this is precisely where I failed. To be honest, up to this point, I had a great looking (well, Snake2 was still on the market) game engine suitable for mobile devices, but yup, it had not come to my mind, that a game to be played would need to be fun and not just visual effects – let’s face it, mobile devices do not have stunning graphics anyhow, no matter how much effort you put into it, the technology is years behind.

And it didn’t stop me from developing – I still added music, explosions, homing missiles, path finding-algorithms and sound effects to name a few – but someday it just occurred to me that this game was simply no fun to play. I struggled a few more weeks, trying to add the fun I wanted, but then I finally gave up (I swear that it was the fault of that bimbo-rugby player that used to tackle me after college – damn you Philipp!). To close this tiny little review of Chopper, I still wanted to add a little pride to this chapter and show Chopper the way it was – a great experience for me and a fun project for anybody else… enjoy: