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. :)