Friday, May 11, 2012

Sprite System Progress

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.

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.

Wednesday, May 2, 2012


For a while now I've been focusing on my job more than anything. I get less time to spend on the computer at home than I have in the past. My job travel time is partly to blame in that it is actually an hour commute so that removes 2 hours a day from actual development time and blog time. Though I have had new responsibilities at home as well. I know there is little excuse for doing a 5 minute post and keeping things going I just hate putting up things that are uninteresting or that don't help you in your game programming and learning.

What's on the Horizon
But I thought I would take a moment to just start writing a few words to console you in your grief over the lack of posts. I am doing a rewrite of the Timed Animation putting splitting it into two or three posts:

  • Sprites - basic frame switching 
  • Advanced Sprites - collision objects, hotspots, rotations
  • Animations - starting/stopping, animations using hotspots, maybe automated reactions to triggers

I want the code to be a abstract and loosely coupled with the Java standard APIs so that they can easily be ported to Android or Java mobile APIs if anyone uses those anymore. The concepts are pretty simple, each sprite has a number of frames including the current frame. The rendering method and asset type (images basically) should be a bit abstracted away in order to allow for it to be extended to and reused in different types of situations such as using a Shape instead of an image or using some other custom type of renderable object.

This concludes the 5 minute update, any suggestions for things you'd like to see on here please don't hesitate to comment with what you'd like to see. I am always open to suggestions. Thanks