RPG-style Skin Handling

Networking & Multiplayer
#1

In designing the crappiest RPG ever, I’m starting to think about how to handle the skinning system. For example:

You enter a room with 15 people there. They all have different permutations of pants (red, green, blue, polka dot) and shirts (Plaid, I’m With Stupid, Slipknot).

The question is, how best to handle and draw the characters. Some issues:

  1. Are all the possible paints and shirts already loaded into memory at startup?

  2. Are the necessary pants and shirts loaded on an as/needed basis…such as, when a new type walks into the room?

  3. Are the sprite objects for each character created to reflect the permutation, or is the pant/shirt/ead drawing all done individually per frame?

  4. How does one handle palette shifting? If a player’s skin color is configurable, should that be drawn dynamically each frame, or as above, cached into the sprite?

My spidey-sense suggests that the sprites should be constructed for each unique look, then linked to each character that matches it. Memory would be loaded/unloaded on an as/need basis. Resources would be JAR-local, so it shouldn’t be too much of a lag issue.

Anybody know of any tutorials on this aspect of the online world? There’s enough tile-based stuff out there that I’ve gone through. :wink:

#2

Is this a 2D or a 3D game?

The techniques are very different. 2D games typically use “paper dolls”. 3D games swap geometries and textures.

As for asset management, thats really an individual game choice. There are tardeoofs that have to be considered with whichever way you chose to go.

Tell us a bit mreo about the project and we can probably be of more help.

#3

Interesting.

The game is 2D. Think classic Ultima stuff…nothing fancy. There will be the standard variet of starter pant and shirt styles. There will also be a selected skin color.

Over the course of the game, players can acquire new duds. The problem hits when you have 30, 40, 50 people in a room…and drawing operations must be streamline while taking into account all the possible outfit pieces and the combinations players have them in.

Not sure what more I can explain than that…let me know.

The “paper doll” thing sounds interesting…can you elabortate?

#4

Sure, ever had a paper doll?

Basically the clothing is keyed with a “layer” numbre and drawn in layer order. First the base character (who may have “molde on underwear” if you don’t want peoep lto be able to strip to totally nude. Many games do this for ratings reasons. as well as preventing in game streakers.) Next under-garments, then pants/shirt, then robe/coat, then cloak, etc.

TYpically 2D games store 6 or 8 viewing angles for a character. Soe acha rticle of clothing is really 6 or 8 images. One is chosen to be overlayed in the right order dependign on the orientation of the charcter.

That all make sense?

Modern 2D games generally avoid trying to re-color thinsg in real time. A LONG time ago when memory was limited and graphcis was all doen through color look up tables (CLUTs) games would reserve parts of the pallete for thionsg like “main character pants” and change them through CLUT manipulation. Given the numerb fo characters onscreen at ocne in a MM game though thsi wpouldnt be terribly practical and besides, you can get better looking images through pre-rendered assets.

WIth the amoutn of main memory in a modern computer, Id preload all the 2D art into main-memory unless you intend to have an outrageously enormous selection. if you DO then you lneed to get a bit fancier and have a on-the-fly laoding scheme. here’s a simpe, example:

On entering a “room”:

(a) pre-load all the art for characters that are in the room at then moment. This may include jsu twhat theya re currently wearing or everythign they have in ventory. (The altter wil lavoid delays when they change clothing.)

(b) When a new character enters, add all the art for that character.

© when new obejcts are egernated ij the room, have the clinets load the art for that object.

(d) flush it all on room chnage.

HOWEVER Java actually gives you soem nice tools that can add some sophistication to this. Using SoftReference and a hash table you can easily add a memory sensative LRU cache layer to all this and speed up transitions between rooms by avoiding unecssary unload and reload of image data.

I routinely use this caching technique for all the image laoding i do in ANY image based app. Yo ucan see it in the code for JNWN, look at the implementaion of ImageFactory i believe ( thats from memory).

#5

OK cool, I’m getting the paper doll metaphor. That totally solves my problem of how to implement skin color.

One more question, I still can’t tell if you’re insinuating that the complete character sprite model should be generated in advance, or if you should draw the character “paper doll style” each frame?

Thanks so much!

#6

Pre generate the layered peices. Draw the paper-doll layers at run-time. Pre-calculating all the possible combinatiosn would blow out the art you need exponentially.

As an rednerefficiency tuning thing you can build the layers up on the fly once and then store that combined image to use over and over until the player changes “clothes”. Thats a memory v. CPU trade-off thing which is typical of game programming.

I wouldn’t do that until you find you really need the speed improvement (eg profiling and tuning phase) but you want to leave your draw pipeline modular enough so its possible.

Does that help?