Game Mechanics Equipment system (drawing and animating)

D

Destal

Guest
Hello,

I'm wondering how to do an equipment system. By that I mean how to draw different pieces of armor or weapons and follow my player animations.

What I've done so far:
- Have a nude player sprite with idle (2 images), running (4 images), attacking (4 images) animations;
- Every armor has all these same sprites with the same amount of images so it follows the player animation;
- Have the player arms in separate sprites so you draw them in the right depth (if the player is looking to the right: left arm, player, armor, right arm)

I'm only talking about torso armor but I could have legs, arms, feet, helmet, which would mean I could have:

Players sprites
- Running
--- Head
--- Torso
--- Arms
--- Legs
--- Feet
- Attacking
--- Head
--- Etc...

Gold armor sprites
- Running
--- Helmet
--- Torso
--- Arms
--- Legs
--- Feet
- Attacking
--- Helmet
--- Etc...

And draw them in the right order for depth.

Is it a common way of handling equipment system ? Cause it's a lot of work so if there is a better way...
 

Niels

Member
It's a pretty common way how you do it. It's also the reason most classic 2d games didn't show every piece of armor on characters like a game like WoW does.
 

Yal

🐧 *penguin noises*
GMC Elder
This gets a lot easier with an (in-engine, not Spine-based) skeletal animation system: you'll draw different sprites using current body part position/rotation values, and you can just replace those sprites based on equipped equipment. Since the sprites themselves aren't animated, the animation is handled by the skeletal animation system, you don't need to make tons of alternate versions of each animation. For an example of this being used in a commercial game, check out Salt & Sanctuary.
 
D

Destal

Guest
This gets a lot easier with an (in-engine, not Spine-based) skeletal animation system: you'll draw different sprites using current body part position/rotation values, and you can just replace those sprites based on equipped equipment. Since the sprites themselves aren't animated, the animation is handled by the skeletal animation system, you don't need to make tons of alternate versions of each animation. For an example of this being used in a commercial game, check out Salt & Sanctuary.
I wanted to do it this way in the first place, but I think you can't have fancy animations this way, I mean you can't always rely on position and angle. At least that's what i remember from my first try.
 

Genetix

Member
I've spent a lot of time thinking about this very issue, on the bright side it sounds like your game is a side-scrolling platformer? It becomes exponentially harder if the player can move in 4 or even 8 directions! Good luck!
 
D

Destal

Guest
I've spent a lot of time thinking about this very issue, on the bright side it sounds like your game is a side-scrolling platformer? It becomes exponentially harder if the player can move in 4 or even 8 directions! Good luck!
You are right and that's why I like the style where the player only has right and left sprites, even if moving in any direction, like in Nuclear Throne.
 
Why on earth would you not use spine? It was built for exactly this...I'm genuinely curious what your reasoning is.

This gets a lot easier with an (in-engine, not Spine-based) skeletal animation system: you'll draw different sprites using current body part position/rotation values, and you can just replace those sprites based on equipped equipment. Since the sprites themselves aren't animated, the animation is handled by the skeletal animation system, you don't need to make tons of alternate versions of each animation. For an example of this being used in a commercial game, check out Salt & Sanctuary.
 
D

Destal

Guest
I don't know Spine but I see many reasons not to systematically use a software that is supposed to make things easier:
1) the price
2) the learning time
3) the fact that it's too much for what you want

Plus I really don't like the result of what I've seen, like on this page: http://fr.esotericsoftware.com/spine-demos I find it very ugly, the movement wants to be realistic but it's awkward, it looks like mobile games or Flash games.

So if I use Spine only for a specific reason, it may be not worth. I'll check.
 

Yal

🐧 *penguin noises*
GMC Elder
the player only has right and left sprites
I really hope you mean "the player only has one sprite, and I use image_xscale to mirror it when the player is facing left", otherwise you're using twice as many sprites as you need to :p

Why on earth would you not use spine? It was built for exactly this...I'm genuinely curious what your reasoning is.
GM uses an outdated version of the Spine runtime and doesn't implement all Spine's features, and Spine is a proprietary format that requires you to buy a license of an unrelated tool. Handling skeleton animation yourself is more work, but you get more control over the coordinates of each sprite strapped to the skeleton (which is kinda important when you want to position equipment properly). I'm not even sure you can replace individual segments of a Spine graphic with code, or you need to assign it a completely different texture to do that (which would cause exponential growth in the number of sprites needed as you add new equipment, since you need one sprite for each possible combination).
 
D

Destal

Guest
Nope you read it well, I use two sprites because I like my characters to be asymmetric (like have an eyepatch or stuff).
 

Yal

🐧 *penguin noises*
GMC Elder
Unless you have a character that's very different on their left and right sides (e.g. Clownpiece from Touhou 15, pictured below) chances are you're just getting yourself twice the upkeep and twice the VRAM usage for something players will either barely never notice and/or never really think about. So I'd recommend to use it with care. I mean, wouldn't you rather put all that extra effort into making a second character instead? (relevant reading link)
upload_2018-4-6_18-57-17.png
 
D

Destal

Guest
I mean if I use only two sprites for a character when people sometimes use eight for all directions, I think I'm still good. I hope GM engine can handle that without having memory problems. Thanks for the link btw.
 

YanBG

Member
I plan to use the paper doll system for a 2d isometric game as well. Characters will be rendered from 3d models in blender because i can automate the process, it still needs perfection though.

Each equipment piece on a separate layer can be rendered in it's own folder. Inside the node editor on the right i've added a dozen "File Output" nodes.
The body should be cut into pieces to avoid depth issues and i have to figure the ground shadows that will overlap from equiping more items(probably rendered separately as well). Learning blender from scratch might be too much for your game though.
 
I don't know Spine but I see many reasons not to systematically use a software that is supposed to make things easier:
1) the price
2) the learning time
3) the fact that it's too much for what you want

Plus I really don't like the result of what I've seen, like on this page: http://fr.esotericsoftware.com/spine-demos I find it very ugly, the movement wants to be realistic but it's awkward, it looks like mobile games or Flash games.

So if I use Spine only for a specific reason, it may be not worth. I'll check.
1) Yal specifically said not to use spine, so I wasn't considering price. Rather I was looking to address whether it was a good tool to use for a skeleton-based paper doll animation system. Check out dragon bones (or something like that) for a free knock off of spine. I think someone developed a runtime for it in GM:S.

2) It is undoubtedly easier to learn a skeleton-based animation dev kit such as spine or dragon bones than it is to program your own and develop a toolkit of your own to create your animations.

3) The current implementation of spine for GMS only uses the basic features you need. There's no support for mesh deformations or IK iirc.

Also, if you don't like that animation, you won't like any hand-made implementation either. That's skeleton based animation...

I really hope you mean "the player only has one sprite, and I use image_xscale to mirror it when the player is facing left", otherwise you're using twice as many sprites as you need to :p


GM uses an outdated version of the Spine runtime and doesn't implement all Spine's features, and Spine is a proprietary format that requires you to buy a license of an unrelated tool. Handling skeleton animation yourself is more work, but you get more control over the coordinates of each sprite strapped to the skeleton (which is kinda important when you want to position equipment properly). I'm not even sure you can replace individual segments of a Spine graphic with code, or you need to assign it a completely different texture to do that (which would cause exponential growth in the number of sprites needed as you add new equipment, since you need one sprite for each possible combination).
It doesn't sound like he needs mesh deformation, so I think the current implementation is perfect for a skeleton based animation solution. It is a separate license, but you shut the tool down as if it was a bad tool for the job...what if he already had a copy of the license and he wouldn't use it because you specifically said "not spine"?

You can specifically replace bone attachments in exactly the way he was seeking...you have all the control you could need for bone-texture positioning (and a well-made ui to develop the animations in). You can even move bones directly in GM and merge animations. You can also use the skins feature so that all of the textures are neatly contained in the same sprite index.

Dragon bones is a free alternative if cost is an issue. To suggest spine is a poor choice to implement a skeleton-based paper doll animation system is just silly. This is literally the perfect application...
 
Top