Sprite System Work
Working on designing the Sprite classes, I am looking to optimizing for large numbers of sprites and being able to handle as many game type situations as possible. Making it easy for you to do some advanced things with it. I am thinking of animating the position and rotation over time. As well as being able to add several sprites to a group and animating them together or independently this will help you reduce the amount of artwork.
Creating Simpler Sprites
There a couple of ways to go about doing sprite animations. You could just have a single hand drawn animation for all your needs where each frame is animated according to what you need. However, that increases the number of images that need to be individually drawn by an artist. If you happen to be the artist this is time taken away from doing programming. So it helps to split an animated sprite into sections that can be animated using code rather than having to draw every frame for every animation.
It becomes almost impossible when you want to...say have a character with a large number of different weapons throughout the game, the artist would have to animate each animation of the character and manually rotate and manuever or even redraw or touch-up sections of the character with each weapon, then if you add different armor or cloths the permutations keep growing. These additional images will increases memory usage at runtime as well as distribution size of the game all the while taking a bit more time to complete. Whereas using a couple of images and combining them using hot spots like say the location and orientation of the hand and the weapon handle. You can draw each weapon depending on which one the character is equipped with under the character image and translate it to the hand position no extra images required other than the character and the weapon.
Benefits
This type of system works very nicely, you can also either define the rotation and position for each frame of the character animation where the hand moves position or interpolate the weapon position based on an overall path of the hand. Another benefit is being able to add post-processing effects using off-screen buffers to individual parts of an animation. The great part about that is you can animate the effects over time as well. For instance say you want to make a flaming sword but you want it to appear random and dynamic instead of pre-drawn. It is much easier to do when the weapon image is drawn separately than the character and not integrated with it. You can draw the sword in an off-screen buffer run your fire generation algorithm and then just draw the sword like normal. You can do heat warping effects and make the flame trail as the sword is swung etc.
Help Brainstorm
If you can think of any other types of animations or situations that you would want in a sprite system please feel free to comment. Always looking to design something that has as many usages covered as possible, since changing the code to accommodate new ideas after the fact can be hard if you don't anticipate them in your initial design.
Working on designing the Sprite classes, I am looking to optimizing for large numbers of sprites and being able to handle as many game type situations as possible. Making it easy for you to do some advanced things with it. I am thinking of animating the position and rotation over time. As well as being able to add several sprites to a group and animating them together or independently this will help you reduce the amount of artwork.
Creating Simpler Sprites
There a couple of ways to go about doing sprite animations. You could just have a single hand drawn animation for all your needs where each frame is animated according to what you need. However, that increases the number of images that need to be individually drawn by an artist. If you happen to be the artist this is time taken away from doing programming. So it helps to split an animated sprite into sections that can be animated using code rather than having to draw every frame for every animation.
It becomes almost impossible when you want to...say have a character with a large number of different weapons throughout the game, the artist would have to animate each animation of the character and manually rotate and manuever or even redraw or touch-up sections of the character with each weapon, then if you add different armor or cloths the permutations keep growing. These additional images will increases memory usage at runtime as well as distribution size of the game all the while taking a bit more time to complete. Whereas using a couple of images and combining them using hot spots like say the location and orientation of the hand and the weapon handle. You can draw each weapon depending on which one the character is equipped with under the character image and translate it to the hand position no extra images required other than the character and the weapon.
Benefits
This type of system works very nicely, you can also either define the rotation and position for each frame of the character animation where the hand moves position or interpolate the weapon position based on an overall path of the hand. Another benefit is being able to add post-processing effects using off-screen buffers to individual parts of an animation. The great part about that is you can animate the effects over time as well. For instance say you want to make a flaming sword but you want it to appear random and dynamic instead of pre-drawn. It is much easier to do when the weapon image is drawn separately than the character and not integrated with it. You can draw the sword in an off-screen buffer run your fire generation algorithm and then just draw the sword like normal. You can do heat warping effects and make the flame trail as the sword is swung etc.
Help Brainstorm
If you can think of any other types of animations or situations that you would want in a sprite system please feel free to comment. Always looking to design something that has as many usages covered as possible, since changing the code to accommodate new ideas after the fact can be hard if you don't anticipate them in your initial design.
No comments:
Post a Comment