Archived

This topic is now archived and is closed to further replies.

Utwo

Managing Sprites in a 2D game (loaded with questions!)

Recommended Posts

Hello. I''m a little confused. I''m trying to come up with a solution for managing a screen full of animated sprites and I''m getting this feeling that I''ve got it all completely wrong. If you have a minute, could you read this over and give me some feedback. This will be my first game, and so I''m very clueless. Here''s what I planned to do. First, I plan on creating a singly-linked list, the nodes of which are instances of a sprite. When the instance of the sprite appears on the screen, a new sprite node is created on the list. When the sprite is killed, that node is removed. Every frame, the DrawScreen() function traverses this list, stopping at each node and gathering information on the destination position of the sprite, as well as the source rect from which to blit that specific frame. So I suppose I should tell you what my Sprite consists of. First I should say that every frame of animation for a sprite exists on one bitmap. So I defined two new structs : POINT: This struct cimply contains an int x and an int y , and is used where needed to describe a point on DC, or whatever else you can think of. FRAME: This struct represents one frame of animation. It contains a POINT which describes the upper-left corner of the rectangle on the source bitmap to be blitted. It also contains an int start_time and an int end_time , which describe the time interval that this frame is to exist on the screen. Now the Sprite class contains a FRAME[] which can be resized to accomodate as many FRAME''s as you need. This array allows me to pretty much script the whole animation, by providing each element with the frame to be used (with the POINT) and the duration of that frame (with the start_time and end_time). There is also a BOOL m_loop, which describes if the animation should loop or not. There is a int width and an int height to describe the width and height of each frame. There is a method called GetFrame(), which takes a look at the time the sprite was created, finds how much time has elapsed since, and then checks the FRAME[] for which frame should be used at that time, and return''s the FRAME''s POINT values, so we know which coordinated to blit from on the source bitmap. So, here''s how it would work. Whenever an event occurs that would result in a Sprite being created (for example, shooting a missile would require a missile sprite, a sprite for each puff of smoke it creates, and an explosion for when the missile collides), a function is called that creates these Sprite objects, the constructor initializes the member data, and these objects are added to the linked list. Then, each frame, the rendering function runs through this list and uses the functions like GetFrame() and others to determine what frame of animation should be used and where it should be blitted to. Questions: 1. Am I on the right track? 2. Most sprites don''t animate in one place. They move as well. Should I add some kind of movement functionality within this class itself? Or should the movement be handled by some outside function? 3. Most sprites have different actions: they walk, run, jump, punch, etc. Would the best way to handle this be to create a Character class, and then have that contain several Sprite objects, one for walking, one for running, etc? If so, would it be a "has-a" or a "is-a"? 4. Should collision detection be a part of this class? Should I make it part of the Character class, if at all? Also, many sprites do different things when a collision is detected. A missile would simply disappear while an explosion animation is drawn at the location of impact, while a ball may bounce in another direction.
I guess what my main concern is that there are so many types of sprites for so many games that, while I''d like to create a set of classes that contains all the functionality needed, it''s very difficult to do so, especially on my own. Am I headed in the right direction? Is there any online tutorial or artical that relates to this subject? Any books to read?

Share this post


Link to post
Share on other sites
quote:
Original post by Utwo
Hello. I'm a little confused.

Should I add some kind of movement functionality within this class itself?

Would the best way to handle this be to create a Character class, and then have that contain several Sprite objects, one for walking, one for running, etc? If so, would it be a "has-a" or a "is-a"?

Should collision detection be a part of this class? Should I make it part of the Character class, if at all?



The universal answer is - find it out by yourself.

You are not required to solve _ALL_ design problems before starting coding (it's impossible, anyway).

If you don't know what to do, hack together some messy code using lots of "if" and "switch" statements, and then figure out how to do the same thing with more elegant code.

[edited by - Advanced Bug on March 17, 2003 3:49:34 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Advanced Bug
The universal answer is - find it out by yourself.


I think Advanced Bug is right--you seem to have some great ideas to start with--get coding and see what happens! I''m not saying design isn''t important, but to see results you have to get your hands at least a little dirty...and remember, any mistakes now you make will only make you a better programmer in the long run.

Share this post


Link to post
Share on other sites
quote:
Original post by Utwo
1. Am I on the right track?



I''d say you have a pretty good handle on what you want to do. Is it the right track? Well that all depends on what your ultimate goal is. This one you should be able to answer by just thinking about how things will be a bit farther along. Only time can tell if the design holds up.

quote:

2. Most sprites don''t animate in one place. They move as well. Should I add some kind of movement functionality within this class itself? Or should the movement be handled by some outside function?



This one all depends on what you are going to use your sprites for. If they need to move, and you are working with Object Oriented Techniques, then you would want to make a sprite''s velocity an attribute. But it''s all really up to you.

quote:

3. Most sprites have different actions: they walk, run, jump, punch, etc. Would the best way to handle this be to create a Character class, and then have that contain several Sprite objects, one for walking, one for running, etc? If so, would it be a "has-a" or a "is-a"?



Again, this is another design decision based on what your ultimate goal is. Try it out, see if this is really what you need.

quote:

4. Should collision detection be a part of this class? Should I make it part of the Character class, if at all? Also, many sprites do different things when a collision is detected. A missile would simply disappear while an explosion animation is drawn at the location of impact, while a ball may bounce in another direction.



Collision detection is a whole different issue. This should be looked at after you''ve got your object strategy down. Come back to this one later.

I agree with thehurricane, you have a quite a bit here, but now you need to validate your designs. The only way to do that is to code something up and see how well they work. Good Luck.

-----------------------------
kevin@mayday-anime.com
http://www.mayday-anime.com

Share this post


Link to post
Share on other sites
I would just like to comment that your plan sounds a lot like what I plan to do, and seeing as how I had my planned before I read yours, that''s a good thing Whenever two different people come up with a similar idea independently, that is a good indication that there is something right about it

As far as collision detection, I''m thinking of having an object manager poll each object for its coordinates and a RECT around the object (if graphical) to find out if it collides with another.

Peon

Share this post


Link to post
Share on other sites