In a more general sense, an entity should always support one or more sprite states, or animation states. I'm going to forego hardcoding entities with set animation states, and I've sketched up an entity, defined in xml. Basically an entity can have one or more animation states, each state can have a set duration, and either a single sprite sheet, or multiple sprite sheets for selecting at random from a pool. The selecting at random from a pool will support my idea for multiple explosion animations.
I normally like to be able to quickly test out the unit I'm working on, and I tend to work and test in pretty small units, so I've decided to kind of fork my development paths into the main game, and a kind of debug mode, in which a sidebar is present along with the original game screen, allowing me to put buttons to test certain functions at will. I imagine what I've created there is the beginnings of a game editor.
A pattern I arrived at with Avalanche (my attempt at a 3d game editor with D3D11) has shown its merit here as I arrived at it once again with InJders. I have a GameEngine class, which contains among other things, a Canvas, and an entity store, as I've called it. I had started by just hardcoding things in the engine's init method to add the player's 'ship', the invisible bounds of the screen, and the enemy bugs, but pulled that logic out into a GameManager class which now sets all that up, and handles mapping input to the player ship and updating the bug entities, etc. For the purpose of the editor, I pushed any common logic up into an abstract base class, and extended GameManager to create one that doesn't contain hardcoded things in its init method, rather it interfaces with the gui controls in my debug mode.
This allows me to reuse all the existing rendering and entity management code I've already written, as well as add new functionality to it and have it be interactively testable. Eventually I want to have my debug mode component create a file that can be passed to the actual game's GameManager to instruct it how to run and manage the game.
This is all to the end of developing some code that can parse my xml entity format and enumerate and switch between animation states, all to eventually get a bug to blow up with a spiffy looking explosion when its shot instead of just disappearing. I think the next milestone after that will be to give the enemies some form of scripted movement so their a little harder to hit. At that point, I plan on getting into an area I have very little experience in, going from programming the technical details to actually making shooting bugs that explode fun. I may either post the jar here for others to try out, or maybe even just embed it into an applet.
Anyway, work tomorrow involving cranking out much less fun java code, so that's all for tonight.