Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Sprites and Entities

  1. #1

    Sprites and Entities

    Hello Everyone!

    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

    Code:
    Sprite.Draw(This.X, This.Y, This.Rotation)
    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.

    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
    Code:
     Player.X := 100;
     Player.Y:= 100;
     Player.Rotation:= 45;
    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.

    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)


    • Sprite properties
      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.


    • Sprite tags
      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.


    • Sprite classes
      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.







    Amnoxx

    Oh, and this code appears to be an approximate replacement for return(random() & 0x01);

    Phoenix Wiki
    http://www.phoenixlib.net/

    Phoenix Forum
    http://www.pascalgamedevelopment.com/viewforum.php?f=71

  2. #2

    Re: Sprites and Entities

    I would consider the sprite a game entity. I don't see why you want to store a big array of images and rectangles and control them by using other objects. Both the behaviour and appearance should IMHO be merged into the same object.
    Moreover, the programmer can always decide to let one sprite "own" a few others. The owned sprites don't have alot of functionality and just listen to their owner. This can be usefull for e.g a spaceship with turrents. You can ignore the update-procedure, disable collision checking and such, and expose the internals of a sprite to make it behave as a simple controllable image.

    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?
    You could let the spacehip sprite create a few turret subsprites in it's own constructor and control them as if the are a single entity.

    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!
    You could add a virtual clone method that can be overridden by any child-classes. Each sprite-class can define it's own cloning behaviour, which should work flawlessly with any editor.

    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.
    There are ways to decompose a matrix but they are expensive. A thing you could do here, is adding a virtual "ComposeMatrix" routine. This routine takes the translation, rotation, and scaling data and returns a matrix. If the user want's to do some special effects (skewing etc...), he can do it by overriding this routine, and possible adding some parameters as class-fields. Then there will be no need to modify the matrix from outside AFAIK, thus all data will remain synced.

    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.
    That would be great, allthough i think that properties like color should not always be inherited. I'd give the programmer a way to prevent the parent from setting the child's color.

    Some basic rectangle<->rectangle version would be doable.
    This would be great. I'd add a "TestCollision()" routine to the sprite, on top of this rectangle check. The programmer can override this method and add his own collision-checking code. The DelphiX sprite-engine works the same.

    Good luck with it.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  3. #3

    Re: Sprites and Entities

    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.
    Acording to model-view-controller approach a sprite is a representation (view) of an entity (model). This is more flexible, e.g. an entity can be represented by a 3D model instead of a sprite.

  4. #4

    Re: Sprites and Entities

    Regarding sprites. There are advantages for both suggestions I can agree with. From personal experience I found the method in the 'old' Phoenix insufficient. I quickly resorted to my own version of a 'spriteengine' where I had more control over animations vs object states, as well as a different way of loading textures for game objects.

    What I'm saying is, your implementation will probably work great for most. But no matter how many extra's you'll add to it, there will always be someone who thinks it's missing something they need.

    Seeing how I eventually wrote my own sprite classes and even added tools to support those, I would now rather have a sprite object with separate texture objects. Meaning every sprite still has a draw function, but the texture object defines how it gets drawn. Hmmm, I think that is even different from what you are suggesting right now

    Regarding your concerns about option x or y being harder for beginners. Honestly I think you shouldn't care about that a whole lot. Give them a few tutorials to read over and they'll pick up soon enough. You should integrate that what is best for the majority of users (I doubt they are beginners) and whats the best solution for your engine.

    # Parent->Child relationship with relative transformations
    That's cool, so we can use something like a particle trail on a spaceship.

    # Plugins instead of inheritance.
    I'm not yet convinced yet about the advantages of plugins. Inheritance is just too cool

    # Sprite properties
    How does this work exactly? Are these fixed properties for a sprite object?

    # Sprite tags
    Could be good. But like you said, too vague yet.

    # Sprite classes
    very interesting, especially the triggersprite!

    As always, looking very much forward to the next update. How long do think for a more final version?






  5. #5

    Re: Sprites and Entities

    Acording to model-view-controller approach a sprite is a representation (view) of an entity (model). This is more flexible, e.g. an entity can be represented by a 3D model instead of a sprite.
    True, but according to OOP every seperate part/module inside a program is responsible for his own Model, View and Projection implementation. It just depends on the situation. Like Traveller said, both sollutions are good, but there will allways be cases in which the chosen sollution will not work properly.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  6. #6

    Re: Sprites and Entities

    @chronozphere

    Great idea with the ComposeMatrix and user configurabe update methods, i will probably go this route.

    Quote Originally Posted by chronozphere
    That would be great, allthough i think that properties like color should not always be inherited. I'd give the programmer a way to prevent the parent from setting the child's color.
    Yeah that might be better to keep that as a implement-if-needed thingy.

    Quote Originally Posted by Traveler
    Regarding sprites. There are advantages for both suggestions I can agree with. From personal experience I found the method in the 'old' Phoenix insufficient. I quickly resorted to my own version of a 'spriteengine' where I had more control over animations vs object states, as well as a different way of loading textures for game objects.

    Seeing how I eventually wrote my own sprite classes and even added tools to support those, I would now rather have a sprite object with separate texture objects. Meaning every sprite still has a draw function, but the texture object defines how it gets drawn. Hmmm, I think that is even different from what you are suggesting right now
    This sounds quite interesting, so you're saying that you separated the rendering of sprites completely from the sprite engine? In my world a texture is basically a bunch of pixels and settings and knows nothing about rendering itself.

    Is this solved with some kind of visitor pattern or what? Id love to hear more about this


    Quote Originally Posted by Traveler
    # Parent->Child relationship with relative transformations
    That's cool, so we can use something like a particle trail on a spaceship.
    Among others

    Quote Originally Posted by Traveler
    # Plugins instead of inheritance.
    I'm not yet convinced yet about the advantages of plugins. Inheritance is just too cool
    The plugins solves the "Has A" property of a sprite. For instance TFerrari is a TCar witch is inheritance and it has a TPlayerController or TAIController to steer it. Solved with a plugin.

    Quote Originally Posted by Traveler
    # Sprite properties
    How does this work exactly? Are these fixed properties for a sprite object?
    Yeah that was the idea that you can load in the constructor and is serialized in the sprite file, basically a Map<String, Variant>.

    Quote Originally Posted by Traveler
    # Sprite tags
    Could be good. But like you said, too vague yet.
    Quote Originally Posted by Traveler
    # Sprite classes
    very interesting, especially the triggersprite!
    The trigger sprite might be moved to the TileEngine, and not be a sprite per say, as in you can define a rectangle in the editor and then create a collision object that does something when it collides.

    Quote Originally Posted by Traveler
    As always, looking very much forward to the next update. How long do think for a more final version?
    Well the ground work is there, window handling, rendering and support functions, so those parts is quite final, some polishing mostly. But ten its a question of how much features to add, tiles, particles, collisions, sound, lighting, shaders, d3d renderer etc.
    Amnoxx

    Oh, and this code appears to be an approximate replacement for return(random() & 0x01);

    Phoenix Wiki
    http://www.phoenixlib.net/

    Phoenix Forum
    http://www.pascalgamedevelopment.com/viewforum.php?f=71

  7. #7

    Re: Sprites and Entities

    Hi Andreas,

    I've taken a closer look at Phoenix (ver. 2009-5-11) and I'm looking at entities and sprites. Do you envision, that all the behavior of a sprite should be defined through behavior plugins?

    For instance I want to define characters in my game. characters are simply sprites with a life counter and a collisionbody. So I have the decision to make a character behavior (TPHXEntityBehavior) or a new character class inheriting from a TPHXSprite. Which would you choose? Are your idea with entity behaviors to totally drop inheritance and simply use has-a relationships for the specific implementation of a given sprite?

    Btw. it would be nice if you could check which behaviors a entity has. I couldn't find any way to do that in the current release.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  8. #8

    Re: Sprites and Entities

    Quote Originally Posted by pstudio
    Hi Andreas,

    I've taken a closer look at Phoenix (ver. 2009-5-11) and I'm looking at entities and sprites. Do you envision, that all the behavior of a sprite should be defined through behavior plugins?

    For instance I want to define characters in my game. characters are simply sprites with a life counter and a collisionbody. So I have the decision to make a character behavior (TPHXEntityBehavior) or a new character class inheriting from a TPHXSprite. Which would you choose? Are your idea with entity behaviors to totally drop inheritance and simply use has-a relationships for the specific implementation of a given sprite?

    Btw. it would be nice if you could check which behaviors a entity has. I couldn't find any way to do that in the current release.
    Yeah, that is the general idea, i havnt really put the ideas in any major practical tests so i'm not shure how it will work out, but for instance the steering behaviors that is implemented in the entity source is a example of the plugin based functionality.

    Even inheriting from TPHXSprite is not a "right" way to do it, a player is not a sprite, he is represented by a sprite thus the player should inherit from entity and have a sprite member.

    Stil, its a quite advanced topic where you can spend ages reimplementing stuff, why do you think it takes time between the releases ;p

    I'll do a quick status update while i'm at it. I have made the final adjustments to the collision code. It seems quite stable now, theres two demos. A simple one showing collisisions between shapes without the CollisionBody or CollisionWorld. And a somewhat more advanced breakout example (I know per-poly collisions is way overkill for a breakout but you get alot of stuff for free).

    I've added TPHXTags to the image editor and image class. They can be used in the same way as the tags in the MD3 format if you're familiar with it, ie mark interesting reagons in the image, for instance attatchment points for particle systems etc.

    And for the record Turbo Delphi 2006 doesnt work flawless on Windows 7, do bad D2009 is so expensive ;p




    Amnoxx

    Oh, and this code appears to be an approximate replacement for return(random() & 0x01);

    Phoenix Wiki
    http://www.phoenixlib.net/

    Phoenix Forum
    http://www.pascalgamedevelopment.com/viewforum.php?f=71

  9. #9

    Re: Sprites and Entities

    Yeah, that is the general idea, i havnt really put the ideas in any major practical tests so i'm not shure how it will work out, but for instance the steering behaviors that is implemented in the entity source is a example of the plugin based functionality.

    Even inheriting from TPHXSprite is not a "right" way to do it, a player is not a sprite, he is represented by a sprite thus the player should inherit from entity and have a sprite member.

    Stil, its a quite advanced topic where you can spend ages reimplementing stuff, why do you think it takes time between the releases ;p
    I'll have to take a look at phxEntity again but I do like the concept of using plugins. It's cool that you can make any entity playable by just adding a single controller plugin for instance.

    I'll do a quick status update while i'm at it. I have made the final adjustments to the collision code. It seems quite stable now, theres two demos. A simple one showing collisisions between shapes without the CollisionBody or CollisionWorld. And a somewhat more advanced breakout example (I know per-poly collisions is way overkill for a breakout but you get alot of stuff for free).

    I've added TPHXTags to the image editor and image class. They can be used in the same way as the tags in the MD3 format if you're familiar with it, ie mark interesting reagons in the image, for instance attatchment points for particle systems etc.
    So the first demo is about collision between TPHXShape's?
    And I'm looking foreward to the breakout demo. It may be overkill to use such an advanced collision system for such a simple game, but it makes easier to focus on the interesting parts.

    Looking foreward to the next release

    And for the record Turbo Delphi 2006 doesnt work flawless on Windows 7, do bad D2009 is so expensive ;p
    Not surprised. I doesn't even work well with Vista
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  10. #10

    Re: Sprites and Entities

    Quote Originally Posted by pstudio
    I'll have to take a look at phxEntity again but I do like the concept of using plugins. It's cool that you can make any entity playable by just adding a single controller plugin for instance.
    I spent yesterday evening refining this further, i created a HomingMissileBehaviour, that moves one entity towards another one with a maximum angular velocity, and it seems to be working flawlessly

    After some more testing I'm considering ditching the TPHXEntity.Clone as a object construction method and use something like thise:

    Code:
    TPHXEntityDefinition = class
     private
      // Name of the entity definition
      FName: String;
     protected
      function AddImpl(const AParent: TPHXEntity): TPHXEntity; virtual; abstract;
     public
      // Create a new entity from this definition
      function Add(const AParent: TPHXEntity): TPHXEntity;
    
       // Name of the entity definition
      property Name: String read FName write FName;
     end;
    
    constructor TPlayerDefinition.Create(SpriteImages: TPHXImageList);
    begin
     Image    := SpriteImages.Find('Sprites/AncientCruiser');
     PatternIndex:= 0;
     ShipName  := 'Ancient Cruiser';
    end;
    
    function TPlayerDefinition.AddImpl(const AParent: TPHXEntity): TPHXEntity;
    var Sprite: TPHXSprite;
    begin
     Sprite:= TPHXSprite.Create(AParent);
     Result:= Sprite;
    
     Sprite.Image    := Image;
     Sprite.PatternIndex:= PatternIndex;
    end;
    
    and creating a player sprite:
    
    Player:= PlayerDefinition.Add(nil) ;
    
    and then you can retrieve the definition like this:
    
     TPlayerDefinition(Player.Definition).ShipName
    This seems to be working

    Quote Originally Posted by pstudio
    So the first demo is about collision between TPHXShape's?
    And I'm looking foreward to the breakout demo. It may be overkill to use such an advanced collision system for such a simple game, but it makes easier to focus on the interesting parts.
    Yeah, without messing with collision bodys and worlds, just to get a feel for the inner workings of the collisions, it describes the shape types etc.

    Quote Originally Posted by pstudio
    Looking foreward to the next release
    I've had some great progress over the last few days, i have a canvas demo to make and some more fine tuning on the sprites, and then its time for a more final release. I wont promise to much, but you might see it before the weekend!

    Quote Originally Posted by pstudio
    Not surprised. I doesn't even work well with Vista
    Actually, i found out that using the classic undocked view for normal and debug use removed the error messages!

    Edit: fixxed the code tags
    Amnoxx

    Oh, and this code appears to be an approximate replacement for return(random() & 0x01);

    Phoenix Wiki
    http://www.phoenixlib.net/

    Phoenix Forum
    http://www.pascalgamedevelopment.com/viewforum.php?f=71

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •