First a small status update, i've done a overhaul on the ImageList and Fonts class and i'd feel they are feature complete and somewhat debugged. The image editor is completed aswell and it got a few new usefull features.
So whats is completed so far is Images, Fonts, Input, Device(Some small addons remaining), ImageEditor
Thus its about time to do a review on the sprite engine in Phoenix.
As you might be aware theres some prototype code included in the preview versions, something like a proof of concept that kindof works. However i havnt settled on the requirements of the engine, so here goes:
The first thing i have some troubles deciding is, should a sprite be a entity in the game or only define some image rectangles, properties and transformations. Meaning that the sprite will be more like an image then a entity (ie it will have no update procedure, no position or rotation). And then you have a game object that has a sprite as a member and using something like
In some way the sprite as a "real" sprite, with position, rotation and image etc is quite easy to grasp and is how most sprite engines are doing it. But then we come to some more advanced topics that doesn't make this as easy anymore.
Sprite.Draw(This.X, This.Y, This.Rotation)
Say you have a spaceship, something big and powerful, now you want to add individually controlled turrets to the ship. Okey create a bunch of sprites, one for the ship and one for each turret. This will surely work and will be done in a few line of codes, now heres the problem, you dont really want to create all content in code, thats booring and not that productive. (I'm spending atleast the same ammount of time writing the tools like image and particle editors as designing the components themselves).
If we write a editor for sprites you want to create a sprite with the transformation tree (adding visible turrets, invisible missile ports etc). Okey all fine, but if we decide on "i want a fleet" how should this be handled?
I have one idea that involves having the good old Sprite class with position and state and then just have a Clone function that does a deep clone on the sprite. That would work in a way that you have two sprite lists in the game, one list for Sprite "prototypes" witch are the sprites you create in the external editor. Then you just clone the prototype sprite and add it to the game world. Any thoughts on this idea or any better ones? I'm all ears!
The next big thing is how to handle transformations, now i've implemented the good old
Internally this will be transformed into a 4x4 transformation matrix. This matrix will then be used to transform the image verticies as well as the child sprites.
Player.X := 100;
However theres some limitations when using both the old position values and the transformation matrix. If you modify the transformation matrix manually (witch could be useful sometimes) the values in the Position and Rotation values wont be updated.
The only way around this would be to remove the Position and rotation properties and replace them with functions like SetPosition, Translate, Rotate that modifies the transformation matrix manually. Returning the position from the translation matrix is no biggie so a GetPosition will be there. Rotation is a different issue and cant be extracted without arctan.
However using X and Y is alot easier for the beginner so i'm somewhat splitted there.
Okey alot of idea venting here, bear with me!
Okey, enough with that, a feature list, feel free to comment on stuff.
Parent->Child relationship with relative transformations
Each entity will have a list of children, where the parent position/rotation/scale/color will be inherited by the children. This means that a tanks turret automatically will rotate when the tank body does.
Plugins instead of inheritance.
So instead of inheriting from TSprite to create a player sprite you insert a PlayerController into the sprite that moves the sprite depending on player input.
(You can still inherit sprites but it should not be necesary)
This will be custom Name->Value properties that will be editable from the sprite editor, might be properties as Max speed for the ship and so on.
This is a idea that i havent really put to much thought in, but it would be similar to what the tags in the Quake3 MD3 format is for, attatching sprites to regions in a parent sprite. It would be a tool to attach turrets and other sprites to a parent sprite without knowing the relative transformation needed.
TPHXSprite, default sprite renders a pattern in an image
TPHXBackgroundSprite, renders a full image, tiled, parallax, what is needed
TPHXTrigger, invisible sprite that calls an event when another sprite touches it.
TPHXParticleSprite, a sprite that is linked to a particle system
TPHXTextSprite, has a font and prints text, nothing more to it
And the last part, collisions i have no intentions of coding collisions into the sprite engine, and the reason is simple, the Phoenix collision engine is way to complex to include into the sprite engine, it would be much easier for the end user if its keept seperated (A simple behaviour that updates the CollisionBodys position each frame is sufficient to couple the sprite engine and the collision engine.)
Some basic rectangle<->rectangle version would be doable.
So this was a long post, but then its a interesting subject.
I'd like to hear your thoughts on this, anything that i have missed that is essentional, something that seems totally out of place etc.