Game Update 2...Milestone 2a

By design, most of the early milestones on the project plan are incremental, rewarding, and intended to get something that looks like a game as quickly as possible (albeit with place-holder art, as you can see). I commend that approach, since getting mired in any one milestone for too long will arrest any sense of progress and threaten your commitment to the project (been there, done that).

I've now hit the second milestone, defined as follows:

Milestone 2a - Rail gun/tracking

• Display fixed, non-scrolling level
• Single anchor point with generator in place
• Single attachment site with rail gun installed
• Single enemy from random direction
• Arrives from off-screen, runs simple path
• Rail gun auto-rotates to follow enemy

In Artillery Support, you, the player, control a static Command Post (later to be called something with "tank" in the name, probably) which controls fixed artillery emplacements on the battle-field. Several of these add-ons will need to track their targets and it seemed like a reasonable early goal to get these things on-screen and make them move.

Milestone 2a - I am not an artist

You can see a grab from the Milestone 2a test level to the right. This is a top-down view of the level, showing your CP in the middle of the screen and a rail-gun turret just below it. As the square sprite moves around the place, the smaller turret rotates to track it - perfect! Tick in the box, move on.

It's all placeholder art, of course, and you can't see the fact that the square enemy is pathing around the edges of the screen, but it does exactly what I need and only took a couple of hours to get working.

Despite the cool factor of getting something working this quickly, there are many compromises which might cost me later. For example, I define and load the level from JSON because I can write, by hand, anything I'm going to need for testing very quickly in that format...but I'm also aware that AndEngine supports at least two level serialization formats one of which (TMX) might well be worth consideration since the tile editor is mature and well-featured. I'm also animating the sprites with deformations (a simple rotation in this case) which is probably not going to be viable in the final game and will back-load a ton of changes to do with moving to AnimatedSprite (although I would like to investigate the idea of some kind of fragment shader which can illuminate sprites based on a bump-map).

Don't know...but the point is, I donn't want to wrestle with the problem for two days, I just want to get on with it. I might not have made the best decision, but it's a decision, and it's got me results.

There is another, related consequence of working this way which is to do with the features of the engine itself. AndEngine is huge, and as I said before (and IIRC promised not to say again, oh well), not particularly well-documented. The game-ware I'm writing for Artillery Support, which already includes a subclass of AndEngine's Sprite class as well as the JSON loader and some other things, might already be a repetition of some of the engine's built-in features.

Again, I don't know, and at this point, I don't care. I wanted to write level data in JSON, so I did it. I wanted to build a SpriteLoader for managing texture regions and sprite instances, so I did it. As the project matures I might embrace other methods and rip all this code out, but in the meantime, the project is actually maturing.

This method won't be for everyone but as a programmer with limited time I need to make progress and I need results. I'll take a warty piece of code that I can run and iterate over a perfectly-conceived masterpiece that exists only in my head any day of the week. :)

Game Update...Milestone 1

"Testing" shoot-em-ups is all well and good, but eventually you gotta code. :)

Artillery Support is a Tower-Defence-like game, in that you fire from fixed locations throughout the level, but I use the comparison as a loose reference point, nothing more, so that the screen-grabs I'm going to post have at least a little context.

I'm running the project much like I would manage a commercial project at my place of work, with the exception that this design will be much more iterative than anything the company culture allows during daylight hours. That still leaves room for milestones, though, and I've now hit the first two.

Milestone 1 - Research game engines, settle on a choice

It is all those things

This milestone was a little bit of a fake, because it was in fact the excellent AndEngine that got me seriously interested in developing an Android game in the first place. I've had fifty or a hundred game ideas...but as all programmers know, ideas are cheap, and that part of me that assumed I was going to have to write a load of middle-ware to support what I wanted to do also knew that I would never ever commit the time needed to actually do it.

The idea that a GLES2-based game engine as feature-complete as AndEngine was not only available but completely free and well-supported, never even crossed my mind. Discovering it, and other options like Libgdx, changed my perception of the Android game development ecosystem almost overnight and made me excited to get going.

I settled on AndEngine, not in any particularly scientific way, but it seemed a good fit for what I had in mind (2D top-down shooter) and I know from experience that when it comes to spending my extra-curriculur time on software projects, I need to absolutely stick to what originally excited and interested me about the job in hand rather than agonize over the choices I'm making, which I think is good advice for anyone embarking on a self-determined software project. (It sounds counter-intuitive, but getting underway is worth much more than any mistakes you might have to deal with later-on.)

As well as the obvious audio and graphics foundation, AndEngine also provides vertex and fragment shaders, a physics engine, a particle system, all kinds of helper classes for managing levels, caches, the UI, and so-on, and well-integrated support for dealing with the various types of user and peripheral input you get from a modern smart-phone.

During experimentation I've had no problems with the engine's feature-set or code quality, and while it does suffer from a lack of decent documentation (Libgdx beats AndEngine on this score), the forum has tons of regular posters with good advice, and there are copious demos and examples to fill in the basics. I would like a decent and up-to-date wiki, but it's hardly fair to whinge about documentation when the engine itself works so well, so that'll be the last thing I have to say about that.

If you want to see what AndEngine can do, the AndEngine Examples app will give you a pretty good idea, and the blog lists several games that have made use of the code.

Reviews 1...Air Attack HD Lite

A first look at some of the shmups on offer on Google Play, starting with Air Attack HD Lite by Art In Games.

Action a-plenty

This is a vertically-scrolling shooter over a beautifully rendered fixed-perspective 3D landscape, very much in the mold of 1942, an arcade game I sunk a lot ten pences into when I got my first job cleaning a bakery for three hours every Saturday morning.

When I first booted the game on my HTC Desire S, what hit me immediately were the graphics...if only because they were exactly the kind of thing I'd imagined for my own Air Support game had it ever got off the ground. Crisp, smooth, highly detailed and very well animated, this is pro stuff. It looks even better on the larger-format Google Nexus 7, where you can really appreciate the attention paid to the level design.

For control, the plane stays on auto-fire and you drag it around the screen with your finger, dodging fire and peppering enemies ahead of you, high and low, with bullets and missiles. This is a staple control method and has the staple problems: on a busy screen where I'm forced up into the middle of the display by heavy fire from below, I often find myself having to lift my wrist out of the way so I can peek underneath and see what's going on. Particularly evident on boss battles where the enemy attack pattern uses all of the screen real-estate available, it's one of those silly compromises that shows the difference between designing a game to the control system or designing the control system to the game, and is by no means unique to Air Attack. (Speaking of boss battles, they're great and make particularly good use of the flexibility afforded by the 3D engine. One end-of-level fight has you drop down and circle strafe an enemy fortress.)

Everything felt fast and responsive on my HTC, as you might expect. Shoot-em-ups have to have high frame rates and pixel-perfect collision detection, and this has both. You never feel robbed of a kill or cheated of a life, two of the most egregious crimes committed by lesser examples of the genre.

The upgrade shop

Other systems employ a quick tap or double-tap. Powerful bombs are dropped by double-tapping the target location, although I would've have preferred my plane to stay put rather than leap forward to drop the bomb, while other significant upgrades like the lightning gun require tapping an on-screen button to activate. Overall, this works fine, since you never have to abandon control of your craft for very long, and there are a variety of interesting upgrades to play with.

Enemies come in traditional waves from one side of the screen or the other. The forced-perspective 3D and slightly-wider-than-your-phone levels often mean that you can be shot by enemies you can't actually see, something I don't like on the whole, but you can drag the plane quickly from one side to the other so it's no big problem really. Some kind of overlay to show threats which are out-of-view might have been helpful. Neat touches like the occasional dead enemy diving in flames to crash on the ground keep things interesting, although to begin with I assumed this was a new kind of enemy I just couldn't hit for some reason (dur).

Overall this is a professional product with a lot of passion behind it. The opportunity to try it out for free shouldn't be missed.

Game: Air Attack HD Lite
Price: Free (limited levels, ad supported)
Tested on: HTC Desire S, Google Nexus 7
Rating: 3.5 Neils out of 5

Opening Salvo

See what I did there, with the title? Superb.

I've started this blog to record the process of designing, coding, productionising, and releasing, a mobile shoot-'em-up game for Android, provisionally called "Artillery Support". (If I ever actually get to the point of releasing something, I'll think of a better name.)

Why a shoot-'em-up? Because back in the earliest of earlies, it was my favourite genre. The ancient and creaky among you will surely remember names like R-Type and Nemesis/Gradius (and its various sequels) from the arcades, but it was the outright classics on the Commodore 64 that dominated my days and nights. I invite you to download a C64 emulator and try any of the following: Uridium, Paradroid, Armalyte, Wizball (one of the greatest 8-bit games ever made), Parallax, Cybernoid, and/or Zynaps. They are all brilliant. No regret will be felt.

It isn't my intention to recreate these games (although I occasionally consider the virtues of that), or even develop a side-scroller (although I harbour a latent wish to one day do that), but I do want to create a game where gratuitousness is the norm: bullets, missiles, explosions, debris...utter chaos. I want the player to have three lives and the enemies to attack in waves; I want there to be levels, a score which can climb into the millions, power-ups, bosses, and the whole shebang.

But since I also want to do this on Android, a touch platform, a few compromises are going to be necessary. After playing many of the shmups on offer from the marketplace, touch interfaces just don't do it for me as a replacement for a joystick/joy-pad. Virtual joy-pads, not to put too fine a point on it, uniformly suck. The alternative method of dragging your craft around the screen while it stays on auto-fire is better, but still permanently obscures the action with your finger and hand and feels way too invasive.

I'll review a few of Android's offerings as we go, but with this in mind I took an old game design of mine called "Air Support", originally intended to be a top-down free-roaming shooter along the lines of the old MegaDrive classic Desert Strike, and re-imagined it for a touch interface. In my head, the resultant game plays out very differently from the original design I wrote ten years ago, but should work great on any multi-touch device whatever the screen format.

Now, I know myself quite well, and there's a danger that the project will falter even in the early stages, but the Android platform is enticing. I've done a smattering of work on it for my employer and it's a peach to develop for, with superb development tools and excellent documentation. There are open-source game engines out there of stunning depth and complexity, freeing the modern garage developer from worrying about anything except game design and player fun. There are people who want these games and better yet, people who will buy these games. It's really time to see what I can do.