And then there was XML

The spritesheet editor has been completed and is now a working tool. Now to start work on the animation editor which will read the output and use it to populate animations. The XNA code to read the XML and draw the image portions will sit between graphics and animation. I'll be writing this sprite rendering code in Java first however because it will be used for rendering everything in the tool from now on (as well as potentially running inside applets on a sprite sharing website I have grand ideas for but too little time to make happen) , then porting to C# and C++.

Here is a small example of the spritesheet output:

http://pastebin.com/f3356d1c

Spritage

I have been mad mad busy at work but things have quieted down somewhat so I'm back to this spritepage / animation editor. It's really not a huge job, it's just a case of finding the time to finish it. Anyway I'm quite drunk so don't intend to make a big rambling post but wanted to share a screenshot, as a wee update and proof I haven't been sat with my thumb up my arse. I present to you... SQUINKER BETA v0.00001

Update: Bit of explanation- this is the spritepage editor, the precursor to the animation tool. It is simply for defining sprite areas on an image and will shortly provide image optmisation. As you can see it will make it very simple to import sprites by name into both the animation tool and the game itself and stops you having to directly manipulate images and filenames repeatedly. The idea is to encapsulate image data away from the code itself, provide high-level, language-independent access to sprites and animations, and to provide a GUI for complete customisation of graphical content without having to open either your IDE or a drawing package!

Imagine for the sake of example that you wanted the missile below to fly out of and circle the big weird-looking mechanical thing (this is not a great example because missiles would almost certainly be an interacting entity, but pretend that they are purely visual- perhaps some electric orbs or something would be more fitting), and at the same time the big mecha thing would be animating like so: Img1 for 2 frames, Img2 for 1 frame... ad infititum (as would the missile). Without the editor there are 2 ways of doing this- coding it, or physically creating lots of almost identical frames of the same size in a graphical tool, and looping them. Both approaches are tedious at best and wasteful at worst. With Squinker, each 'element' will never be replicated and the only data required by the game is an image and some XML data. What's more, someone with no coding experience can mess with animations and immediately see the results in-game. We could have mad complex animations with zero additional time cost.

Moving stuff over to new entity system

Yesterday I got the monster/projectile collision stuff moved over to the new entity system. I took the existing tests that me and Sam did and rejigged them. Pathfinding has also been taken over.

Unit testing each action was fairly easy, but doesn't give you much confidence that the entire interaction will work - pathfinding and shooting both involve a few different components talking to each other. To fully test this I've added some integration tests. They still run as fast as the unit tests, but they involve interactions between several classes (which should be a no-no in a unit test).

There are still a few tests that need to be added, or rather there are still things we need to work out. At the moment each action checks its user and target entities for certain components. If they exist it proceeds as normal. If it can't find them however, it just returns from its DoAction method. We'll need to think about cases where actions can act on entities that have a subset of the components they require to work fully, and what should happen when one or several can't be found.

Are both of you up for a chat later on this afternoon? Thinking about 1700 onwards...?

Mocking Texture2D/SpriteBatch/Content

I've run into a problem.

For constructors for certain things, like the Monster factory, I'd like to add a list of Texture2Ds loaded at startup so that each factory method can give the entity the correct sprite.

However.

To mock a class (which has an implementation) rather than in interface (where the mock provides the entire implementation) you need to mock out everything that goes into its constructor. When you look at Texture2D or SpriteBatch, you'll see they take a GraphicsDevice which itself takes loads of stuff. The object graph explodes.

There does seem to be a way around this - someone's written a test framework called Scurvy.Test which purports to solve these kinds of problems by allowing you to instantiate the whole XNA thing during tests including the ContentManager, which would let us load Texture2Ds.

The other way I can think to deal with it is to abstract the graphics stuff away, dealing with some wrapper or other rather than relying on XNA's built in types.

Either way the unit tests aren't going to be as straightforward as I'd hoped.

Component-based entities II - The Wreckoning

I've made a start at implementing the system detailed in the last link. The diagram from the article sucks the boaby, so I've re-done it using YUML (a free, online UML editor - where you draw your UML using code!):

This says

• Entity is composed of Form, Action and State
• Form is composed of Space
• Entity uses Space
• Action uses State
  

Here's the code for the diagram if you want to edit it or fancy making your own:

[Entity]++-[Action]
[Entity]++-[State]
[Entity]++-[Form]
[Entity]uses-.->[Space]
[Form]++-[Space]
[Space]++-[Entity]
[Action]uses-.->[State]

Component-based entities

(Sam, you were right - the blog is a good guilt-causing mechanism. I've not done any coding since before pyweek!)

At the moment I'm reading up on component-based entity systems. It seems like a much more flexible approach than the one we took initially. When you want to add some functionality it goes in as a standalone component, rather than being wedged into a possibly inappropriate place in the class hierarchy.

• This is a good post from a dude that worked on the Tony Hawks games discussing his experience refactoring their whole engine to use component-based entities. Pretty light on code though :(
  

• This other article discusses Dungeon Siege's system. They seem to have a mad hybrid going on. They have components, but they also have 'template' game objects which are like common archetypes. The components themselves seem to have some hierarchy going on: "The Attack component handles loading and launching ammo for projectile weapons. Requires the Common component. ".
  

• This one has some actual code but it's pretty bare-bones. It does match the way I'm thinking about it though, which is that an Entity is nothing but a collection of Components.

• Yet another one goes a slightly different route again. He's broken down all game objects into five classes - Entity, Space, Form, State and Action. Form is the visual representation and also holds State. Entities hold Actions (insantiated by game events). Space is stuff like view/world frustum, used for optimisation.
  Our components in this system become subclasses of Action and State. An Action operates on specific kinds of State objects (e.g. ItemPickup action interacts with Inventory state object). Here's an example from the article:
  
  • "Let’s say the car is a fast car and we want to make it go even faster. However, what we do not want to do is make the car faster. If we were to make the car faster, we could only affect the behavior of that car. Instead, we make the "fast" faster, and therefore ANY game token car that can go "fast" can be affected if we so choose. Much more importantly, not only could any token representing a car be affected, also, ANY game token with a "fast" behavior could potentially be modified regardless of what it is meant to represent."

I'm going to have a go at implementing the last one, starting with something pretty simple so we can get back to having monsters and bullets collide as quickly as possible. As always, let's hear your thoughts :)

Pyweek's finished!

And here's our game

It came out pretty well for a week's effort, especially considering that the vast bulk of the content was added on Saturday (and the wee hours of Friday night).

Anyway, this means I'll be back on the project now - although maybe not today. Got a lot of missed housework to catch up on :( (and I need a break :P)