I am using Coco2d-x to create a social network styled 2d Avatar game. The game will give players the ability to pickup accessories, faces, eyes, noses, clothes, hair and stuff for their avatar. Something along these lines:

The characters will be animated with walking, dancing and sleeping animations. I'm a software developer and really haven't ever touched anything 2d before. Coming at this is a bit daunting as I read around on the internet. So I'm here to ask for some guidance and hopefully some answers to a few questions. Sorry in advance if I butcher the terminology, or if this should be posted in the technical section. I'm not quiet sure where this kind of post belongs. It felt more like this section as I assumed these questions could be answered during the animation process, before it ends up in the engine.

Animation

I want to animate the characters in various different states, such as walking, dancing and sleeping. From what I've seen, you can do this with skeletal bone animations. The game engine I've been developing the game in, Coco2d-x, supports this in some fashion. I'm not sure to what extent; i figured determining that would be simpler after I have an understanding of how the animation needs to be created from the artistic side.

From reading online, it seems that you create the bones, and apply a skin to each appendage. You then export a rendered animation or sprite set of each frame. In my case, if I have 500 different items, that's 250,000 potential combinations I'd have to export and store/stream down to the devices. Is it possible to rig the bones and apply the skins after the fact within the game?

How would you handle bones that might not always be present? For instance, using the headgear in the picture above as an example, what if I wanted to attach a swaying feather to a head piece? Would you typically treat that as two different objects, joined together at runtime and animated independently, or can you attach bones to an existing skeletal object at runtime?

The character head and eyes are also hot-swappable. If I am animating their eyes, so they blink, would I export that as an animated sprite and attach that animation sprite to the head and eye joints? Would you just animate them within the game engine, if the game engine supports keyframe animation, which coco2d-x does, rather than export it?

Software

I have Photoshop and I've seen people say that a drawing tablet is not often required. Would photoshop be the tool of choice, or would you guys do this in a different application such as InkScape or Anime Studio Pro?

Do you export the individual layers out, importing them into a different app to handle the animations, re-assembling them during keyframing?

Artwork

What is the best practice when I am finished with character assets and want to export them? Do you export it with a transparent background? When you export it, would you use .png as your go to file format?

How do I go about handling different asset sizes, for different devices? Would you create one large canvas, with the entire character set (set consists of the shirt, shoes, pants, head etc for a specific theme), and export them out in pieces at varying resolutions or would you create it all as vector graphics and only use the vectors in the engine for easier scaling?

Each player has their own house that their character lives in. Their house will be from an orthogonal perspective along these lines:

What are the best practices to create the walls, floors and ceilings along with things like beds, couches etc and making sure they all snap to each other? I can define a grid based system in the game to force snapping, but I'm not sure how to ensure my art will fit into that grid. Are there guidlines you can give on how I can go about mapping how I draw my art so that my assets can snap properly to walls and floors and look right without manually adjusting each piece?

In closing

I appreciate anyones time with these questions. I've done software development for 20 years, but have never worked on a game. It's a bit nerve wracking trying to get into the art side of things with it. Your help would be greatly appreciated!

I'd love any documentation you might have used in the past for your stuff, experiences you have with any of the talking points above or any books that might cover any of these items. I'm not afraid to do some reading or trial & error, if I can just get pointed in the right direction.

Thanks!

In my case, if I have 500 different items, that's 250,000 potential combinations...

One way of doing this is called "paper dolling".

Imagine a player is putting on three items:
A) Blue eyes
B) White hair
C) A red and yellow striped scarf

Each of these have their own pre-rendered animations, with nothing else in the image except for that particular item. Not even the human body is in the image. It's just (for example) pure transparency except for a scarf floating in midair, being animated as if it was on an invisible person.

When you are drawing the player, you then do this:

Draw(animations.bodies.get(player.currentBodyID), player.skinColoration);
Draw(animations.heads.get(player.currentHeadID), player.skinColoration);
Draw(animations.hats.get(player.currentHatID));
Draw(animations.eyeShapes.get(player.currentEyeShapeID), player.eyeColoration);
Draw(animations.hairStyles.get(player.currentHairStyleID), player.hairColoration);
Draw(animations.neckObject.get(player.currentNeckObjectID));
...etc...

Basically, you prerender the animations of each component separately, then you draw the active components one after another, on top of each other.

...that's 250,000 potential combinations I'd have to export and store/stream down to the devices.

Art is a fixed asset. You want to store it locally on the player's computer. Only when it changes, should the player have to re-download it. Basically, this can just be done by a patcher/updater before the player is allowed to enter the world.

How would you handle bones that might not always be present? For instance, using the headgear in the picture above as an example, what if I wanted to attach a swaying feather to a head piece? Would you typically treat that as two different objects, joined together at runtime and animated independently, or can you attach bones to an existing skeletal object at runtime?

I'd personally do it by animating the feather separately (making it white, for easier player color customization - so the same image can be colorized into a blue feather, green feather, black feather, etc... at run-time).

I'd then draw it like this:

Draw(...);
Draw(animations.heads.get(player.currentHeadID), player.skinColoration);
Draw(animations.hats.get(player.currentHatID));
Draw(animations.feathers.get(player.currentFeatherID)); //<-----
Draw(...);

The key (in this method) is to make sure the player can't equip a feather when he's not wearing a hat that that feather can work with.

This can be done by:

struct Hat
{
   HatType type; //What category of hat this is, for animation purposes.

   //...all your other data...
};

struct Feather
{
   HatType forTypeOfHat; //This feather only fits a certain category of hats.
   
   //...all your other data...
};

Then, in the inventory (and checked server-side), you just check (featherToEquip.forTypeOfHat == currentHatEquipped.type), and if false, don't allow it to be equipped.

One way of doing this is called "paper dolling".

Imagine a player is putting on three items:
A) Blue eyes
B) White hair
C) A red and yellow striped scarf

Each of these have their own pre-rendered animations, with nothing else in the image except for that particular item. Not even the human body is in the image. It's just (for example) pure transparency except for a scarf floating in midair, being animated as if it was on an invisible person.

Ah, that makes sense to me. Would you composite a template of the person with hands/feet etc to at least animate the keyframes to give some reference as to how it looks, and then strip them all out before exporting?

Art is a fixed asset. You want to store it locally on the player's computer. Only when it changes, should the player have to re-download it. Basically, this can just be done by a patcher/updater before the player is allowed to enter the world.

I had totally planned to cache it all locally after the user has streamed it down the first time. I play to many games on my phone that re-streams the content every time and it takes forever to load each view. I figured I'd store the files locally and have a local database that maps the asset Id to the file. Then when entering a room with 50 other players, I'd just send the player their character info and asset Ids. What ever Ids I don't have locally, stream in async while loading the local cached assets from disk.

I'd personally do it by animating the feather separately (making it white, for easier player color customization - so the same image can be colorized into a blue feather, green feather, black feather, etc... at run-time).

So if I keep my assets white, I can adjust their tint at runtime? I hadn't thought of that; it would be a nice touch to make the assets stretch a bit further in the customization department.

The key (in this method) is to make sure the player can't equip a feather when he's not wearing a hat that that feather can work with.

Totally, I figured I'd have Mounting Points that each asset would specify it belongs to. Things like "BothEyes, LeftEye, Right Ear, LeftSideOfHat" etc.

How do you typically store those Ids? I was thinking I'd just use GUIDs in this scenario over integers. Is that typical?

Would you composite a template of the person with hands/feet etc to at least animate the keyframes to give some reference as to how it looks, and then strip them all out before exporting?

Yes, or perhaps you'd even write a small tool to show the item animating on top of a base character.

For extra fanciness, your tool could auto-reload the item each time the file changes, so, for example, you might be editing the image on your main monitor, and have the animated preview on a side monitor (or floating in a small window on your single monitor), and each time you Ctrl+S, the animated preview instantly reflects your current WIP. You can also have your game itself do this (which is called "hot loading" or "hot swapping"), so you can be editing your item and see the changes instantly reflected inside your currently-running game. But that requires some extra work in your game code itself that may not always be worth the effort.

Some people even write custom plugins for programs like Photoshop, so any editing they do instantly reflects in-game, without even saving the image, so they can basically edit the image live while watching the changes appear instantly in-game. That's extra complex though, and requires alot of work.

I figured I'd store the files locally and have a local database that maps the asset Id to the file.

A database might be overkill. A simple map does the same thing (e.g. std::unordered_map<AssetID, Filepath>).

Then when entering a room with 50 other players, I'd just send the player their character info and asset Ids. What ever Ids I don't have locally, stream in async while loading the local cached assets from disk.

Yep, that sounds good. Depending on what you are doing, you may also need to know if Image #22784 on the server has changed (e.g. you changed a few pixels to make it look better), and the player's cached #22784 was an older version, requiring him to re-download that specific image.

I'd personally do it by animating the feather separately (making it white, for easier player color customization - so the same image can be colorized into a blue feather, green feather, black feather, etc... at run-time).

So if I keep my assets white, I can adjust their tint at runtime? I hadn't thought of that; it would be a nice touch to make the assets stretch a bit further in the customization department.

Yes. Same with the player's skin, eyes, hair, shirt, etc... If you make the body grey-scale, you can let players tweak some color slider bars and make the skin the color they want. Ofcourse, you'll have to define acceptable ranges (or else just have 40 or 50 pre-selected color values they can choose from), so players don't choose dark-as-void black or bubble-gum pink as a skin color.

This is easy to do, the videocard basically does it for free, and many APIs expose that functionality already.

The problem is when you want to have more than one color in a single image: e.g. a red shirt with a white logo on it. So for those kind of items, just don't use any color-modifying, and draw them the regular way with the red and etc... already in it. Or else make the "not-colorable" details be a separate image drawn over the colorized base, or whatever.

There's actually a clever way to still use more than one color, and have pre-chosen color detail baked into it, but it requires you to be able to micro-manage the pixels as they are being drawn. Basically, you'd need to be able to use shaders to do it, and that's something you might want to avoid for the time present, if you're learning too many things at once.

How do you typically store those Ids? I was thinking I'd just use GUIDs in this scenario over integers. Is that typical?

Why GUIDs? Why not just unique integers?

GUIDs are useful when there is more than one authoritative source: My computer creates something, and needs a unique ID that doesn't clash with whatever your computer is creating, despite your computer and my computer not directly interacting.

But for art assets, you, the developer, are the sole authority. If two IDs class, you can just change one of them.

GUIDs would require you to send alot more data per ID (128 bits) compared to regular ints (32 bits). In my own game, in many places I find I can even get away with 16 bit integers - that still gives me sixty-five thousand unique IDs. If that's not enough, go with 32 bits which gives you four billion.

Why GUIDs? Why not just unique integers?

There isn't any reason in particular. I could just as easily use integers.

Would you use vector graphics, or just export the individual pieces out as PNGs at different resolutions?

Personally, I'd just use raster graphics (like PNGs) because I'm more familiar with that. I also think it'd give a crisper appearance which is important in my own art styles - but your art style may differ. There's pros and cons both ways, so for your game (depending on art style, longevity, targetted platforms, etc...) it may make more sense to use vector.

It'd be good if some other people would chime in with their views so you're not basing your decisions purely off of my limited experience and knowledge.