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.