Game Mechanics Dynamic Equipment System for 2D Pixel-Art Game

[Bobink]

Overview/Programs Used (so far):
- Aseprite
- GameMaker Studio 2
- Spine

I have a project I'm working on in GameMaker Studio 2 version 2.3.7.606. The project is a 2D adventure/RPG, and it is heavily pixelated (emphasis on pixel art). I'm wondering if there is a way to implement a dynamic equipment system from inventory-based input.

I.e, I would like my sprite/object to change depending on which piece of gear I've "equipped" from my inventory (4 slots of gear: head, chest, legs, boots [and weapons of course]). I want to implement this with various different pieces and amalgamations of armor, which means that there could be (for example) 10 different head variations, 10 chest variations, etc. that I would like to be drawn to the player sprite/object seamlessly and dynamically.

Example:
- Say I equip a helmet (right clicking it in my inventory), I want that helmet to then appear on my player, and stay on my player until I unequip (place it back into my inventory) it, which means the equipped item would persist through my run animation, jump animation, roll animation, etc.

So far, the best option I've seen (days of research) is using the program Spine, utilizing its GMS2 functionality, since Spine has an intuitive bone system that lets each piece of the sprite's appearance change dynamically based on a piece of equipment being equipped. That being said, Spine doesn't work well with pixelated animation, and even after investigating workarounds, I can't wrap my head around the endeavor of animating a pixelated sprite in this manner.

My proposed solution:
I would like to (somehow) export hand-drawn animations from Aseprite (our sprite art program [there is a script I use to import stuff to Spine from here already and it works*]) and import them into Spine while NOT utilizing Spine's animation features, which I know sounds weird, but that's the best way I could think to use it without heavily altering our current art-style.
The problem with my proposed solution:
- I have no idea how or IF there is any way to import hand-drawn animation strips/sequences from Aseprite to Spine.
- I'm currently using Spine Trial to test this, and I'm not sure if I will even be able to do this type of thing (IF it exists) with Spine Essential (the only version I can remotely afford).

Conclusion: This is a major roadblock in my project, and it has the possibility to make or break my project's RPG-feel. I have looked all over the internet for any type of answer for this, to no avail. Please let me know if this is possible, or if there are any alternatives (I wouldn't be typing this, however, if I hadn't tried everything I could think of).


Thanks,
Bobink

 

[Nocturne]

I'll be honest and say that I think you should maybe not be using Spine for this if you're not going to be using the animation capabilities it offers... For what you describe it will probably be better to simply import the sprites into GameMaker and then simply code the different item slots and positions into the game. This is fairly easy to do, and will give the best outcome... although it will greatly depend on the sprites themselves and what items/changes you want to make. Could you maybe post an example of a sprite animation and the type of items you want them to equip? That would help us give a more informed answer to your question.

 

[Bobink]

I'll be honest and say that I think you should maybe not be using Spine for this if you're not going to be using the animation capabilities it offers... For what you describe it will probably be better to simply import the sprites into GMS2 and then simply code the different item slots and positions into the game. This is fairly easy to do, and will give the best outcome... although it will greatly depend on the sprites themselves and what items/changes you want to make. Could you maybe post an example of a sprite animation and the type of items you want them to equip? That would help us give a more informed answer to your question.

The reason we wanted to use Spine's bone/dynamic capabilities is so we wouldn't have to bother with drawing the gargantuan amount of sprites that it would take if we didn't use its dynamic capabilities.

Unfortunately, we haven't drawn any sprite animations for this yet until we've gotten a solid workflow figured out, just static sprites.

And, the problem with simply importing sprites to the game and coding the item slots and positions is that, although simple at first, once we add the amount of items that we would like to have in-game, this feat would prove ridiculously complicated and confusing, not to mention it would (unless I'm misunderstanding this process) triple or even quadruple the amount of work for our animator/artist; however, this amount of work seems like it could be greatly reduced or even negated entirely by using a program that lets you tell the sprite ahead of time whether each piece (bone/slot) of it is using another sprite (in this case, a piece of unique armor).

The process you mentioned seemed like it would be easier if the system wasn't dynamic, in the sense that the character could only use one piece of armor at a time, which, in that case, is something I would definitely do. But we would really like to implement 4-5 sets of armor with other unique pieces throughout the world, yet we would like to be simultaneously wearing different pieces from different sets in their respective slots without our animations altering.

Here is a sprite example (free asset, not mine nor one I'm using) that could maybe give you some insight:

View attachment 45292

So as you can see, the player has unique boots, a unique shield, sword, cape, etc. but they all persist throughout his jump animation. That being said, I would like my system to maintain that hand-drawn pixelated art style, while also allowing the player to change, for example, his sword, while ONLY drawing a new sword sprite and interconnecting them (through something like Spine), cutting out the entire process of redrawing each animation with that new sword. This CAN be done in Spine, I know for a fact. I've watched several videos on it. The only caveat is that (to my knowledge) the animation you use has to be from Spine's functionality, which as we all know, doesn't coincide well with a more hand-drawn animation feel like this where the joints bend and (for the most part) completely change in shape for each sprite in the animation strip.

Another example of how we will be using these items and such in this process that I can think of is Minecraft: we would like the player to be able to use, in this instance, gold boots, an iron chest, diamond helmet, and leather legs all at the same time without having to draw a sprite with that instance in mind. There's no way that the only feasible way to do something like that is through hand drawing every single variation with every single animation... that would take weeks, if not months, and with all of the different possibilities it would easily get confusing to the point of not being worth it.

I'm starting to think that maybe this is not just a Spine or pixel art problem and maybe it's something on GMS2's side? I just can't find any results when looking to implement something like this. Is this not the right engine for this kind of thing? Thanks for your swift response so far, and sorry if I come off as agitated at all, I'm just very worried and stressed about this development roadblock and have people constantly asking me questions, so I'm just trying to find out about this so we can make a decision.

Thanks again,
Bobink

 

[RhyminGarFunkle]

If you want a hand-drawn animation style, there's no getting around needing to hand-draw the animation. There are a couple things that can make this easier, though:

- You don't need to draw sprites for every possible combination of items the player could have equipped. Just draw a version of the player sprite with no sword, then draw the sword by itself. A simple script can select the proper sprite and image index for the equipped item and animation frame. Repeat for armor, boots, hair, etc.

- With Aseprite, it's very easy to draw multiple versions of the same item using palettes. If you have a wooden sword, copper sword, steel sword, and gold sword, you can simply draw one version of the sword in "indexed" mode, then change the palette to change the material. Those palettes can be saved and reused, so from then on it's basically a one-click process to make different material bows, lances, etc. In practice you'll probably want to lightly adjust each sprite beyond color - a wooden sword probably has some wooden texture - but it still dramatically cuts down on drawing time.

 

[Bobink]

If you want a hand-drawn animation style, there's no getting around needing to hand-draw the animation. There are a couple things that can make this easier, though:

- You don't need to draw sprites for every possible combination of items the player could have equipped. Just draw a version of the player sprite with no sword, then draw the sword by itself. A simple script can select the proper sprite and image index for the equipped item and animation frame. Repeat for armor, boots, hair, etc.

- With Aseprite, it's very easy to draw multiple versions of the same item using palettes. If you have a wooden sword, copper sword, steel sword, and gold sword, you can simply draw one version of the sword in "indexed" mode, then change the palette to change the material. Those palettes can be saved and reused, so from then on it's basically a one-click process to make different material bows, lances, etc. In practice you'll probably want to lightly adjust each sprite beyond color - a wooden sword probably has some wooden texture - but it still dramatically cuts down on drawing time.

And this is also something that can be implemented with code through an inventory-based equipment system? As in, I could send these sprites (through code) to my player from my inventory and the player sprite update?

Thank you for your timely and assuring response,
Bobink

 

[RhyminGarFunkle]

Yes. You simply determine what sprites are needed (based on the equipped items), what image index of the sprites to use (based on the animation frame), the draw order they should be in (sometimes the weapon might be behind the player's body, other times in front) and use a series of draw_sprite() commands in the player object's draw event.

 

[Nocturne]

If you want a hand-drawn animation style, there's no getting around needing to hand-draw the animation. There are a couple things that can make this easier, though:

- You don't need to draw sprites for every possible combination of items the player could have equipped. Just draw a version of the player sprite with no sword, then draw the sword by itself. A simple script can select the proper sprite and image index for the equipped item and animation frame. Repeat for armor, boots, hair, etc.

- With Aseprite, it's very easy to draw multiple versions of the same item using palettes. If you have a wooden sword, copper sword, steel sword, and gold sword, you can simply draw one version of the sword in "indexed" mode, then change the palette to change the material. Those palettes can be saved and reused, so from then on it's basically a one-click process to make different material bows, lances, etc. In practice you'll probably want to lightly adjust each sprite beyond color - a wooden sword probably has some wooden texture - but it still dramatically cuts down on drawing time.

This is really what I was trying to suggest in my post. essentially you just make layers of sprites, where the base is the player body and then on top of that you draw the required items. Check out this video by Friendly Cosmonaut to get an idea of what we're suggesting (I've set the timestamp):

 

[Bobink]

Thank you for your replies. I'm going to do some testing sometime when I'm free and see how well your suggestions work, and I'll report back to you guys!

 

[Yal]

The most scalable way you could do it is to set up your own "skeleton" structure, and then draw individual sprites for each "bone" (limbs, torso, head etc), with positions and image_angle based on the bones' position in an animation:

Of course, a lot of work goes into this! You can get limb positions through basic trigonometry and a hierarchy system (all bones start at the end of another bone, except the "root") but you need to figure out a structure for the data, and maybe make a custom editor for poses etc.

 

[Bobink]

The most scalable way you could do it is to set up your own "skeleton" structure, and then draw individual sprites for each "bone" (limbs, torso, head etc), with positions and image_angle based on the bones' position in an animation:

Of course, a lot of work goes into this! You can get limb positions through basic trigonometry and a hierarchy system (all bones start at the end of another bone, except the "root") but you need to figure out a structure for the data, and maybe make a custom editor for poses etc.

I've tried a couple methods, but the internet always points me to this skeleton direction. I can't afford Spine (and even if I could, I personally like my sprites hand-drawn, as they look a lot better with our art style).
I'm aware of dragonbones and spriter for doing this as well, but I've not seen a straight answer as to which one is even supported in GMS2, or if any of them are anymore. It seems like most of the answers to this I've found online are "umm, maybe? why not just use spine" lol. But yeah that's where I'm at. Not to rant or anything, but I would've never guessed such a simple equipment system (like terraria or diablo) would be SO extremely convoluted and alien to GMS2. I mean, I can't find a solution that works with what I'm trying to do no matter how hard I try lol. I appreciate you and everyone else's help though

 

[Bobink]

Maybe I'm just overcomplicating it, but I've tried DOZENS of solutions people have posted on various forums or videos, and just can't get them to work the way I'd like them to.

This video seems to be the most straightforward and simple implementation of an armor system, but (and no offense to the creator) to newer programmers there are a lot of details that get skipped over or completely overlooked, like random variables that are established in code that are either unexplained or unreferenced elsewhere.

 

[Nocturne]

I'm afraid I really don't see the problem here... and wonder if maybe you're over thinking things? Or maybe not explaining properly to us exactly what the problem is? The concept is really simple and actually very easy to do in GMS2:

1) Create a "base" sprite for the character, with all the animations.
2) Create clothes sprites that cover the parts of the base sprite for each animation
3) Create weapons sprites that are positioned in their animations so they "fit" in the base sprites hands
4) In GameMaker use variables to tell GM what to draw.

The initial spritework is quite high as you'll need to create animations for all the clothes and weapons so that they "fit" the character regardless of the movement they are doing. Like, if your character can walk, run, jump, and fight, then you're clothes and weapons will also need these animations. You're essentially "onion-skinning" the base character with all they need... Now, having done this already myself for a few games, I can say that once you get the base animations down, creating the clothes and items is actually quite simple to do as you're simply drawing over the main sprite and once you have a few things everything else is just using those and modifying them slightly. You can also GREATLY increase the item number without doing ANY art by using a shader to re-colour them. So you create a base shirt sprite/animation then draw using a shader to create a blue, red, yelloe, purple, green, etc... shirt. One shirt becomes 20 in the game!

The video you linked is pretty much exactly this system, btw... so I'm not sure what's up with that? Are you wanting an EXACT step to step tutorial on how to create this kind of system? Because if you are then you'll be disappointed I think as most tutorials covering this kind of stuff are pretty basic and you're expected to build on the concept yourself. My recommendation would be to create your base (naked) sprite, TWO items of the same clothing (like trousers) and TWO weapons (all with full animations), then try and program drawing these and switching between them. Once you get the basic system in place it'll be a lot easier to customise it for hundreds of combinations. You can post in the programming forum for help with that part too!

 

[Bobink]

I appreciate it. Yeah maybe I'm just overcomplicating the logic.

 

[RhyminGarFunkle]

Here's a TRPG I'm working on. The player's units (in blue) are procedurally generated, XCOM-style, and are drawn by layering different sprites. in this clip you'll see two different Knights, each with different heads, colors, and weapons.

There is a common armor sprite drawn as the base:

There are several different possible heads:

The color of the skin and hair is handled by a shader.

In this clip, there are two different weapons shown, an iron axe and a gold axe:



Additionally, there's a "hand" sprite, that's sometimes also the back and arms (to simplify frames where the head is behind the body)

Each unit is represented by several data structures that store information like what hair the unit has, the current equipped item, etc. With that data, it's literally a simple series of draw_sprite() calls to draw the relevant sprites over each other in the proper order.

Unit portraits are handled in a similar way, with lots of different pieces (head, eyes, eyebrows, mouth, nose, hair) drawn over each other to create unique faces (although these particular pieces are placeholders I drew many years ago and am no longer particularly proud of, they need to be redrawn).

Feel free to use the sprites here to experiment and figure out the principles, but please don't use them in a released product.

 

[Bobink]

Here's a TRPG I'm working on. The player's units (in blue) are procedurally generated, XCOM-style, and are drawn by layering different sprites. in this clip you'll see two different Knights, each with different heads, colors, and weapons.

There is a common armor sprite drawn as the base:

There are several different possible heads:
View attachment 45453
The color of the skin and hair is handled by a shader.

In this clip, there are two different weapons shown, an iron axe and a gold axe:
View attachment 45454

View attachment 45455
Additionally, there's a "hand" sprite, that's sometimes also the back and arms (to simplify frames where the head is behind the body)
View attachment 45456
Each unit is represented by several data structures that store information like what hair the unit has, the current equipped item, etc. With that data, it's literally a simple series of draw_sprite() calls to draw the relevant sprites over each other in the proper order.

Unit portraits are handled in a similar way, with lots of different pieces (head, eyes, eyebrows, mouth, nose, hair) drawn over each other to create unique faces (although these particular pieces are placeholders I drew many years ago and am no longer particularly proud of, they need to be redrawn).

Feel free to use the sprites here to experiment and figure out the principles, but please don't use them in a released product.

Thanks for the recommendation and support

 

[Yal]

I can't afford Spine

I mean, that's why I made a system in pure GML (not necessarily because I can't afford Spine, but more like, having to deal with two different softwares that can get out of sync is a pain)

It's also surprisingly simple conceptually, you do the same thing for every limb! (In the OJ version of the system shown here I hardcoded this, but I'm working on an improved version which has an arbitrary hierarchy structure... but that's probably a bit excessive for a beginner like yourself, hardcoding still exists for a reason - MUCH easier to get things working)