ID:2327788
 
Since the beginning of 2012, I've been steadily releasing a series of RPGs starting with the game "Epic". Epic is sentimental to me because it represents the start of my main "franchise"(for the lack of a better term) and was the first full length original game that I was able to produce. Over the last 6 years I've developed Epic, Epic:Legend, Epoch, and Nother, all with similar design pillars and references to one another in a shared universe. One of these design pillars is something I'm going to be talking about today, because I find it to be the most applicable for other developers.

First, let's establish why overlays are important to talk about. In an RPG where you can collect all kinds of weapons and armors, it's very easy to say that you want the player to be able to visually see those items equipped on their character. But we're making 2D games on this website, and that comes with an inherent challenge. Because we can't rig pieces of armor or weapons to bones on the character like in a 3D game, we have to manually place and animate anything we want to add to the character. This can add up really fast: anyone who has ever made an RPG on this website knows exactly what I mean.

Let's look at Crono, for instance. Let's be really generous and assume that Crono ONLY has a walking animation, right?

So that's 16 frames. 4 frames for walking, and multiplied by four because the character faces in 4 directions. Ok, now let's say we want to have five weapons in the game. That means we will need 80 frames total for those five weapons. Even if you only have ONE animation in the entire game, and it's four frames long, things still add up fast. Now let's look at reality.

Now you can see why this is a problem? Between headgear, body gear, legs, shoes, gloves, weapons, capes, etc, one of the deciding factors for the viability of your RPG will just boil down to how you handle overlays. As a result, most of the RPGs on this website that have animations on the character are limited in the variety of overlays they offer, and the ones that do have a lot of overlays typically are more rigid and simplistic.

So now we have established why this is an important conversation to have. This was something I personally learned very early on while making games on BYOND. Hopeful projects would immediately get swamped the moment overlays came into the equation. But clever developers on the website have found ways around this problem. I'm going to share the four ways I've done it so far.

1. Epic: Bird's eye perspective

The simplest solution was found in 2012's Epic. By using a bird's eye view, you sacrifice form for function. The player sprites are kind of ugly and unappealing in Epic, and are very simplistic bird's eye circles. Because of this, however, I was able to rotate the player at any angle I wanted. So if I wanted the player's sword to swing, I just had to rotate it over time. It sounds easy enough, but in 2012 transforms and animate() were not in the engine, so I had to rotate the icons using icon procs. This was really slow and caused a whole bunch of problems but I was pushing the limits of the engine at the time. For some perspective, this game also featured dynamically instanced maps, and maptext(before maptext was a feature). Epic is laughably easy to recate in 2017 with BYOND, but back then it was riddled with road bumps(in addition to my own lack of foresight in designing efficient game systems).

So, in Epic I only had to draw 1 frame to add a new weapon or armor to the game. This was AMAZING compared to the 100+ frames I was used to doing in my older projects and I knew that going forward, I wouldn't work on another RPG unless I used a similar workflow.

PROS: Easily turn the character in 360 directions while still only requiring 1 frame to add a weapon into the game!

CONS: Not aesthetically pleasing or in perspective...

2. Epic: Legend: Hard-coded animation rig

Epic: Legend was planned to have a lot of weapons. Around 160, to be exact, and they're all in there... despite a few problems. The way weapons were handled in Epic:Legend was innovative for the time but had a lot of issues. Here's how it worked: The player base had 2 animations, walking and attacking, and both were 4 frames each. The game had a hard-coded animation generator that knew how to place and rotate the weapon icons onto the base and then export the results as .dmi files. Sounds neat, right? A similar, inspired system actually made its way into Eternia as a result. It's a good idea, but there are a few issues. For one, it's all hard coded. If I wanted to add a new animation, then I had to hard code that many frames into the game and rigorously test them as I went because hard coding an animation rig has a lot of trial and error. That made the whole process incredibly tedious and is the reason the final result base only has 2 animations(this was also partly due to my lack of animation experience at the time). The second major issue is that I was using file() to assign icons to weapons. This is really not a good idea because it requires you to include the weapon icons in a folder with the game's executable, so a lot of people played Epic:Legend and had an all-naked cast of characters. This is NOT a viable way to make an RPG. If I wanted to make an animation rig again, I'd have to find a way to innovate that fixes these two issues. Unfortunately, big ideas take time.

PROS: The animations for weapons can go in 4 directions now and the attack animation is more fluid looking! It's in perspective and still only requires 1 frame to add a new weapon into the game.

CONS: The process is so tedious that I can't add any new animation states. It's also trial and error which makes it take forever to add the existing animation states. As a result, the game's character only can do 2 animations. Also, use of the file() proc to find weapon icons has a lot of baggage.

3. EPΘCH: BYOND 5.0 BABY

With transforms letting us finally rotate stuff, it was time to try a new animation process. One of the major focuses in the initial design of Epoch was to look back at what made Epic 1 good, and try to recreate those feelings while still creating something fresh and forward-moving. I knew I fucked up in a lot of different ways in designing and delivering Epic:Legend and Epoch was to be the redemption piece. So, with transforms in BYOND 5.0, I was ready to try and apply it to a new RPG.

Epoch uses transforms to rotate a weapon overlay applied to the player. The big heads and small bodies let me cover up some quirks of this while still making it look kind of like it's in perspective. The result of being able to attack in 360 directions had a nice feeling of freedom to it and was a lot faster than Epic's icon proc based system. In Epoch, however, each weapon has 2 icon state. The first is just the weapon doing nothing. The second is the weapon mid-swing. This lets me create a better looking "swing" animation while I rotate the weapon over time for an attack. But because the attacks were hard-coded into the state machine, it was really complicated to add new animations, and even if I tried there were only so many effects I could pull off. As a result there are really only 3 attack animations in Epoch: Swing left, swing right, and stab. Different weapons play them at different speeds(because, again, it's hooked into a frame-by-frame state machine) but overall there isn't a lot of variety in the attack animations.

PROS: Still 1-ish frame only needed to add new weapons. Looks better than Epic and Epic:Legend, so it was a step forward. 360 degrees of attack. Put a 3/4ths perspective chibi head over the weapons instead of Epic's birds-eye bodies to get a more aesthetically pleasing result.

CONS: Lack of variety in attack animations. Few animations in the game in general because they all had to be hard-coded(all of Epoch's animations besides the walk are procedural). Not as good looking as it could have been, but it was the best I could do at the time.

4. Nother: Trying something new

Coming off of the cons of Epoch, I knew I wanted to make something with a player character who could just perform more animations. The result is Nother. Nother has a LOT of animations the character can do and every single one has four directions. Here's what the previews for some of the overlays look like.

How is this possible? For the first time, I used a 2d animation rigging system made specifically for Nother. Despite all these animations, I still only had to draw 1 frame per new weapon. Cool stuff, right? Here's how it worked.

The rigging system is located in a folder inside Nother's main game directory called "overlay generator". This has its own .dme and thereby .dmb that I can launch. That DMB locally generates the weapon icons, etc and saves them in a folder. Because the overlay generator folder is in Nother's main directory, I can reference the icons from within Nother's code. In addition to this, when the overlay generator makes icons for weapons, it also programs those weapons for me by generating automatic code for them that references the weapon icons, saving me a LOT of time. This system is AWESOME! But it has a few flaws. Before I go over those, here's how it actually generates icons:

There is a "reference" icon that is basically the skeletal rig for the character. It's like the player base, but with little colored dots on certain parts of the the body. Think of these kind of like how motion capture software works. For example, there is a green dot to tell the engine where the weapon hilt goes, and a red dot to tell the engine where the weapon is pointed(in relation to the green dot). A blue dot tells the engine that the weapon is using its "swing" icon state, two blue dots flip that "swing" state on the x axis, cyan and purple dots tell the engine where shoulder pads go, and a white dot tells the engine where the headgear is placed. Once all these parts are together, the engine can assemble overlays pretty accurately and quickly. As a result Nother has a ton of items!

There are a few major downsides though. The hitboxes in Nother just aren't as precise as the pixel perfect hitboxes in Epoch. There are minor discrepancies in the differences between different attack directions that make it really hard to place hitboxes especially since different weapons have different attack lengths. Also, in Nother you can two hand and dual wield weapons. Because of this, every attack essentially needs 3 versions: left, right, and two handed. This made rigging extremely tedious and as a result there are only two swing animations and a lunge animation, which add up to 9 attack animations in addition to a left and right grab/throw animation. This means it has the same flaw that Epoch had in a lack of animation diversity.

PROS: 4 directions, in perspective, tons of animations, still only 1 frame needed for a weapon.

CONS: Lack of different attacks the character can do, animations are all kind of rigid, hitboxes aren't precise, small character sprite is less appealing than the cute style of Epoch.


So what's next? Who knows. Thanks for reading. If there's one thing I hope you take away from this post, it's that you should really plan out how you're going to handle overlays if you are making a 2D RPG. It will save you hundreds of hours of work in the long run. I also hope you learned that there are a whole variety of techniques you can use to handle overlays. Happy holidays.
Good read, nice to see some innovation to the normal way an overlay would be tediously done.

Great job.
Thanks for the post :)
Now I have to go play some Epic games

Login to reply.