I've read a bit about creating assets for games and the consensus seems to be that 2D is cheaper than 3D in all aspects with the exception of character animation. That's caused by the need of redrawing every frame of an animation versus simply animating the skeleton of a model.

The cheapest solution seems to be making all the assets with lots of animations as 3d models and prerendering them to create sprite sheets, and leave the background and everything else that has few animations traditionally drawn.

How do I do it, what tools would be appropriate, whats the process and workflow? How does the pipeline for this work? Where could I learn more about doing something like this?

On the other hand, I'm afraid that such an approach greatly limits the available customisation of my characters - wouldnt such a thing mean that each combination of gear needs to have its own spritesheet? Doesnt that pump up my game size and memory footprint and slow it down due to slow disk access?

How viable is putting a 3d model in a isometric view 2d environment? Would that be a solution to the "lots of sprites" problem, if it exists? How would I go about that in Unity? Where could I learn about that approach?

I've looked at this question but it did'nt really help me, the answers are just vaugue suggestions, I want solutions and resources to learn how to implement those solutions.

EDIT:
I'll elaborate on why that question isnt the same as mine, because some of the commenters didnt get it. That post refers to a game called hero academy that has little to do with the isometric game I'm talking about - that one has a grid, does not use the 8 directions, does not adress the customisation of a character via gear etc. All in all it's totally another beast. As for my question, think Diablo II.

Out of the answers I found there it seemed like the answer referring to project zomboid might be on the right track for me, but I had doubts about the customisation and tons of sprites. So what am I asking here? Does the "project zomboid method" fit my needs (trying it out only to find out it doesnt work would be a waste of time) and if it does, how do I do that in Unity. Why didnt i phrase the question that way in the first place? To avoid the XY problem. Hope this clarifies well enough.

I'm not sure how your question is different. I'd answer it the same way I answered the one you linked. A question about how to develop an entire animation system isn't going to get anything but vague/broad suggestions. It's too complex a topic to ask about here.
–
Byte56♦Jan 30 '14 at 15:45

3

I guess you know that there's also 2D animation software that supports skeletal animation? There's no need for 3D if you plan to make a 2D game.
–
bummzackJan 30 '14 at 17:15

5 Answers
5

You could have your characters represented as 3D models, then rendered to off-screen buffers as sprite sheets on demand and use them to render 2D images. Workflow is rather simple - you just render frames of your animation to render target, then use that produced image as spritesheet.

For combinations of gear you can just render/have each piece of gear available as separate sprite and then just combine/layer them as necessary. You can draw naked character first, then draw selection of armor on top, one selected weapon in hand, etc.

Making nice looking 3d animation is a serious highly paid profession. Making 3d models that will look nice in a 2d game is even more challenging in some sense. You have to remember 3d models in a 2d game may look out of place. Also if you go ahead and use 3d models, you may as well just stick the in the game as they are and render the in game.

Just because game-play is 2d, does not mean visuals need to be as well.

I think you should break this up into multiple questions and try again. Offhand, I see 3 questions that all warrant their own detailed answers, but there are probably more that you can ask to get the detailed answers you wish for:

Using 3D to generate 2D Sprites

You can just use 3D as a way to render Sprites, i.e. by creating your animations, then rendering them out as individual frames and stitching those together into a sprite sheet.

How do I attach customizations to 2D Sprites

The same way you would to 3D Sprites: You break them up into several objects, mark "attachment points" on the main sprite (different ones for each frame in some additional metadata file), and then whenever you draw an actor, you draw the attachments at the attachment points. You may also have to mark attachment points as "above" or "below" the actor, so e.g. you can draw a backpack obscured by the character while she's facing you, but still have a helmet obscure the character's head. And of course you'd need 2D sprites from every angle for the customizations as well.

If you also want to customize the actual graphics, you would also split up parts of the main character into different parts, and then you can apply scale factors to them (e.g. to get a narrower face, offer different noses etc.).

How do I put 3D models in a 2D environment

In short, you can't. What you usually do is the reverse, use a 3D environment with a fixed camera, and then put up all the 2D content as if they were cardboard standups. Then you can leave room between them and use a projection matrix that does not make things in the distance get smaller (IIRC that's what Unity already does when you create a 2D game). Then you can just place the 3D models in between the cardboard standups.

You could take a look at BrashMonkey Spriter. Which is a software for creating 2D animatinos that are rotation based instead of frame based. It is mainly made for XNA framework, but there are many community implementations for other software aswell, and you may implement your own code if you have good knowledge of C#. (It has implementations for example Unity)

The program uses techniques with bones like 3d animations and keyframed animation, and you can exchange the parts of the body with eas.
However, it's not produced by a big professional company and all features are not fully implemented ( It has support for creating collision boxes frame controlled but you have to implement the code to use them yourself.
For commercial purposes, the license is also relatively cheap.
The file output is basicly a huge xml file (.scml) which is then read and processed by the game.