Support non-zero ‘aim’ directions for bullets
Improve the pattern ‘test/test-4.xml’

This patch adds extra <fire> tags to the pattern so that we can test
out different ‘aim’ values.  It also changes the bullet prototype to
set the origin lower on screen so that we can more easily see bullets
move away.
Allow <direction> tags as children of <bullet>

This is something the BulletML specification allows and is necessary
in order to implement ‘relative’ direction firing.
Add a test case bullet pattern for the ‘sequence’ direction type
Improve TAGS for instruction and node handlers

This patch makes ctags insert an ‘IH.’ or ‘NH.’ prefix into the tag
names so that we can make distinctions between

    Pattern.IH.fire
    Pattern.NH.fire

and similar overlaps.
Add a comment mentioning the enemy XML documentation

Direct people to both the documentation and the Document Type
Definition for further information.
Define a <health> tag for enemies

However we do not add a corresponding property to the Enemy class.
This is because we are likely to add health as a more general property
to Actors later on.  For now we only need to know how we will define
health in the enemy files and not how we will store them in game.
Add <health> to the roach enemy for debugging purposes
Make it clear that an enemy action can <fire> multiple times

We do not want to limit enemies to only firing one bullet pattern.
Redefine enemy <action> tags to allow multiple <fire> nodes

This will make it possible to create enemies that fire multiple
patterns.  We also modify the definition to allow optional <x> and <y>
tags to provide offsets for the origin of each pattern.  This patch
only changes the Document Type Definition for enemies; it does not
implement support for multiple patterns-per-enemy.
Give enemies a list of bullet patterns instead of just one

This patch removes ‘Enemy.pattern’ and replaces it with the
‘Enemy.patterns’ array.  It modifies the draw() method to iterate
through that array to draw all patterns.  However, the patch also
deletes the code for loading patterns and firing them, since we must
re-approach those two things now that we want multiple patterns.
Therefore this patch breaks the current enemy behavior support.
Parse multiple <fire> nodes within an enemy <action> tag

This patch adds a node handler for <fire> tags that we apply to all
instances of the tag which appear in the ‘main’ action for an enemy.
We re-implement the ‘fire-pattern’ instruction so that it will shoot a
pattern from the list of patterns that node handler can create,
instead of assuming there is only one pattern.  However this does
create a problem; multiple patterns will not fire in tandem because
Enemy:execute() will not pass over a ‘fire-pattern’ instruction until
that particular pattern completes execution.  This means we need to
think about how to allow controlling the order of pattern firing and
even allowing an enemy to fire every pattern simultaneously, which may
be a more sane default.
Update the test roach for the new <fire> tag definition

We add one of the optional offset tags (i.e. <y>) so we can make sure
those work as intended also.
Add enemy instruction for firing all patterns

This makes it possible in the enemy behavior to tell an enemy to fire
every one of its patterns at the same time.  We may desire this as
default behavior later on.
Fix the way we offset enemy bullet patterns

Currently we update the origin of the pattern only once: when the
node handler processes the <fire> tag and creates the ‘fire-pattern’
instruction.  However, this is not correct because once the enemy
moves the origin of the pattern is no longer what we want.

The correct behavior is to update the origin of the pattern every time
we fire it.  In order to do this we need to pass along the information
of any <x> or <y> tags that we found with the <fire> node during
processing, because the ‘fire-pattern’ instruction will need access to
that information.  This patch creates an offset vector that we pass to
that instruction which it uses to update the origin of the pattern
every time before firing, giving us the desired behavior.

This does highlight a limitation though: the ‘fire-all-patterns’
instruction does not have access to that offset information.
Simply the ‘position’ in Enemy.__tostring()

Since an Enemy is now an Actor it automatically has a ‘position’
Vector2D object.  And since we have tostring() support for Vector2D
objects we do not need to explicitly break it apart when printing out
the position of enemies.
Add hitboxes to the enemy Document Type Definition

This patch defines the standard on how we will describe an enemy’s
hitboxes in the game data.  It assumes we want enemies to have
potentially multiple hitboxes so that players could have more than one
area to focus their attacks.
Update our demo roach enemy with new <hitbox> data

This will allow us to test the upcoming implementation.
Give enemy <hitbox> tags a ‘vital’ attribute

This patch allows us to mark a hitbox as vital to an enemy.  Vital
hitboxes are those which the player must destroy in order to kill an
enemy.  By default we consider all hitboxes vital.
Remove the old <health> tag from our test roach enemy

We no longer use the <health> tag in this way.  Now it is a child node
of <hitbox> tags.