Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I am currently working on a 2D Double Dragon style beat 'em up game project. We are working with DirectX 9 and are looking at implementing a composite sprite system for all our characters as explained below:

  1. Sprites for characters are broken into "pieces", for example hair-head-body-legs. There will be separate sprite sets for each component.

  2. The user can select from different parts to build their characters. For example, they could use Head A, body B, and legs D for one character, Head B, Body C, and Legs A for another, etc.

  3. The parts are not connected statically. In other words, the head will bob up and down at a different rate than the body when the character is running, etc.

  4. Finally, if it makes any difference, the different parts may or may not be pallete swappable. Hair and head will be swappable for hair and skin colors, for example.

This is kind of how the sprites in Metal Slug 4 were built, as shown here: http://img814.imageshack.us/img814/7453/robertor.png You can see that the main body animation has two parts, upper body and legs only.

It would make sense to me to have several large sprite sheets with related sprites grouped together by sheet. Ultimately its all going to be compiled into one / several data files (res.dat, res2.dat, etc) and a resource manager class is going to handle access to the data, and also handle breaking up of the sprite data into smaller logical "files" at run time as required by any constraints.

I had some thoughts about how to develop this system, but I was looking for input. Here's what I had in mind:

  1. Several large-ish sprite sheets, loading and accessing of which would be handled by a resource management class

  2. A sprite data manager that stores a set of information about each sprite): -Which sheet each is on -X,Y offset into that sheet -Width and height -Some sort of identifier (name, or just a number or something) Example of an entry: Sprite 123 is on sheet A, offset into the sprite sheet by 128 x and 284 y, and is 64x64 in size.

  3. A separate data set of animation descriptions in terms of sets of sequences of "composite sprite data", frame-durations, and characteristics (pause on last frame, loop, etc) Example of an entry: 123, 124, 125, and 126 for 100ms, 120ms, 90ms, and 120ms respectively. Loop indefinitely -- to describe maybe a a set of legs for a walk cycle. There would be other entries describing other legs' walk cycles, sequences of hair sprites that represent a hair animation that blows around or doesn't, etc.

  4. Composite sprite data objects. These would be data sets of Z-ordered "animation descriptions" (in item 3 above) that make up a character's complete sprite (as an example, from closest to farthest, hair + head + body + legs + shadow, as described above), as well as each sprite component's offset from the base of the object (ie. draw the head last so its on top, and draw it 55 px above the ground in the center, etc)

Not meaning to confuse things further, but I thought that alternatively I could take out item 3 above, and change item 4 so that it stores a set of animations per character. Each set of animations would be composed of a particular head sprite, a particular body sprite, etc, with an offset for each as well.

I want to design the system so that the entire character sprites could be easily built out of all the parts at run time continuously.

What does everyone think? I'm pretty sure I can make this work, but I didn't want to overlook any other design options, so I wanted some feedback. Has anyone else implemented a system like this?

Thanks!

share|improve this question

closed as too broad by Josh Petrie Jan 3 at 17:45

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
You seem to have an idea of what you want, which seems reasonable, and are just asking for a discussion about that potential implementation, which is overly broad because there is no right answer. –  Josh Petrie Jan 3 at 17:46
    
Thanks for the comment. In retrospect, you're right; I ended up going with this system anyway. Thanks for the "seems reasonable comment" though. Even now, it gives me a bit of confidence in the choices made during implementation. –  Awesomania Jan 3 at 19:48

Browse other questions tagged or ask your own question.