Almost a month ago I began working on a new project with the goal of recreating many features of one of my favorite games, Super Smash Bros. Ultimate, inside of Unity.

As of writing this I’ve just finished working on the in game movement, and by that I mean all the parts that don’t have much to do with fighting. Here I’m going to go over the process I went through to get it working.

Of course the first step was to figure out everything a fighter can do, and all the things that can happen to it when in a match. While doing this part, I wasn’t entirely sure how the process of developing the fighter was going to be divided up, so I went ahead and figured out as many actions as I could. I took notes in a spreadsheet, and eventually organized everything into separate categories.

After figuring out as much as I could, which at the time I thought was everything (I found more as I went), I began making preparations for adding the movements into the game.

Graphics

The first thing I did before any kind of coding was hop in Blender and make a basic character model. I rigged it up, and gave it an idle animation that I thought said, “Let’s Fight!”

And before I did any work on the actual fighter, I wanted a more stylized aesthetic, so I decided to try my hand at some custom screen shaders, something I haven’t done before now.

The first thing I wanted to make was a screen pixelization effect.

The best solution I could find, (which honestly seems like it shouldn’t actually be the best) was to render a low res render texture, put it on a plane and track a camera to it. I’ve also got the plane to automatically resize with the camera in editor, which is handy.

After getting that to work, I decided it would be cool to have a stroke effect. I figured it would have something to do with the z buffer and normals, but considering it would be my first real screen shader, I wasn’t sure where to start. Luckily for me, I found this amazing tutorial. They’ve written their shader in HLSL, but I was able to figure out how to get it working with Unity Cg since they’re similar enough. I’ve also got some custom outline thickness depending on different variables.

Setting Up the Animator

Before beginning working on the script, I decided I needed to get the animator kind of set up, so the script could automatically put the animations in their proper locations.

I changed the set up as I went to keep things a little bit more organized.

As of now this is how the current set up looks. All the transitions come from Any State, because all the work deciding when to transition happens within the script. And since there are so many possible to and from transitions, it was easiest to do it this way.

Script Organization

Keeping the script organized is something I learned the hard way while working on One Drop Bot. Trying to keep your script organized is very tough when dealing with many complex moving parts. But if you don’t, it can get difficult when there’s so many things its hard to keep track of what’s what.

I’ve organized everything into separate functions based on their focus. It all starts with the basic Unity functions : Update and Fixed Update. Simply put, Update runs every time a frame is rendered, and Fixed Update runs every time a physics calculation is performed.

Within Update is where all one time inputs are checked, like jumping or breaking out into a run. If you try to check for these in Fixed Update, inputs can be missed, so they have to be done in Update. The Animation function, where all the animations take place is called at the bottom of the Update function.

Fixed Update is where all movement input is checked and movement calculations are made like walking and running. This is where any kind of movement over time is done.

And actually, near the end of getting the movement working things began to be difficult to keep track of. Although it’ll be fine, I should probably spend some time reorganizing everything just to keep things clean. I’ve been thinking about looking into ways to use multiple scripts together in Unity in order to keep things simpler, whether by deriving from custom classes or otherwise. It’s definitely something worth looking into.

Animation Importing / Movement Organization

Part of my plan to keep everything organized was to create a few arrays of custom classes each of which would focus on an aspect of the player. I’ve only created the array for the movement which is what we’re focusing on here. The movement doesn’t have any kind of special colliders or other fancy things that the attacks will, so the only thing they have at the moment are animations.

In order to keep things simple I created a button that automatically takes the animations from the fbx and imports them into the animator.

Movement Implementation

Now we’ll start talking about the actual implementation piece by piece.

Basic Movements

The first things I implemented was the horizontal movement, what happens when you press left or right.

The movement is a little more complicated then going or stopping when you move. When you move in Super Smash Bros, there’s a bit of sliding that takes place, especially when you run. You can see it very clearly in the skidding animations of Luigi’s run.

In order to replicate this sliding I used two variables : a speed variable and a sliding variable. The speed is multiplied by the input to get the speed to head towards. Then a direction is calculated from the current speed and the desired speed, and then the current speed is moved in the direction of the desired speed based on the sliding value.

To put it in simpler terms, instead of just moving, there’s a speed to go to and an actual speed. The actual speed chases the go to speed around trying to keep up. The moments where the actual speed is different from the go to speed is when sliding occurs.

Running activation was simple on the keyboard, just double tapping activates it, or tapping the same direction you’re moving in. However, activation on the thumbstick was a bit more complicated. I had to calculate the acceleration of the input, and then figure out how fast was enough to activate the run. I still might tweak this acceleration variable somewhat in the future.

When running is activated, instead of immediatly running, there’s a break out animation that plays. And if you stop running during the break out, you won’t stop moving until the break out animation finishes playing. This allows for some interesting movement.

If you turn around while running, you skid and then start running in the opposite direction. A problem with this was that if you were to stop running then start running in the opposite direction, the skid animation would get skipped, and you’d immediately start running in the opposite direction. In order to combat this, a few frames are added to the running time so you cant just switch directions right away if you move a little slower.

Jumping and Falling

Using the same technique I used for activating running, I created the jumping mechanism. And just like SSBU, there’s a second jump too. And based on the direction of your jump the character has a diffrent animation, one for forwards and for backwards. So that’s four jumping animations in total.

Also there’s different animations for falling. In SSBU there’s four but I took a shortcut and just did two, one for the first jump and another for the second jump. I may come back to this and do the other animations, but for now it’s not necessary.

While you’re falling, if you press down, you start falling faster.

Ledge Grabbing

When you’re falling, the game starts looking for ledges you can grab onto. The range for this is above the characters waist and a little above their head. I found this out by moving the character in and around the ledge until I was sure where the boundaries were.

When a ledge is found, the character immediately latches onto it.

There are four possible actions you can take when hanging from a ledge. You can fall backwards, fall straight down, get up, or jump up.

Falling down or backwards was pretty simple, but implementing getting up was a bit tricky. I had to figure out how the player moves from hanging on the ledge to standing on the platform.

After messing around in SSBU for a bit, I found that it looks like after the getting up animation is played, the player is immediately moved onto the ledge and the animation is switched on the same frame to idle to create a seamless motion.

The way I figured it out was I pushed the computer to the edge, and then saw how it reacted when I got up from the ledge. It moved out of the way as soon as the animation for getting up finished playing.

Jumping up was complicated in its own way. First an animation plays to prepare to jump, then the actual jump occurs, and nicely transitions into a regular fall.

One Way Platforms

This was the most difficult part to figure out. Unity does have a built in one way platform component, but it’s only for 2D collision. And there’s no way I’m converting the colliders to 2D, especially since we want to stay loyal to the way things work in Super Smash Bros where everything uses 3D colliders.

I tried creating a separate script for this, but I found that it’s more efficient to do the work within the player script. The reason I chose this method, is because it’s easier to keep track of how each player interacts with the platforms, rather than have the platforms each worry about multiple players.

The way it knows if a player can stand on the platform is it checks if the player is above the platform, then if that clears, it checks if the player is within the boundaries of the collider. If those both clear, then collision is enabled between the player and the one way platform.

There are exceptions to this. When you hold down while falling you’ll fall straight through, and if you’re standing on the platform while pressing down, you’ll fall through it.

The Little Things

I’ve labeled this section the little things, because it’s mostly things that you don’t really think about. In fact, when I began writing this section I forgot the things that would go here. Without them though, the experience would be incomplete.

First I’d like to talk a bit more about how skidding works. It only activates when you’re either ending a run or turning around. If you stop before finishing breaking out, then you won’t skid.

When you press down on solid ground, meaning not a one way platform, you crouch.

When you’re jumping and you hit the ceiling, an animation plays. What made this difficult was figuring out the timing for where their heads hit the ceiling and when to start the animation so it looks as if it’s actually happening.

This last one is one of the most complex parts of the movement, yet something that’s easily overlooked. In fact the reason I did it last was because I had overlooked it until the end.

While weeding out glitches, I noticed that when standing on the edge, I could go out an unatural distance, even to the point where it didn’t look like I was standing on the platform any more. This got me curious as to what they did in Super Smash Bros. Apparently, if you’re standing close enough to the edge and you’re walking slower than half speed towards it. Then it clamps you to the edge, making it so you can’t move unless you walk away from the edge or walk faster than half speed off the edge.

Conclusion

This project is still in the works, and I plan to turn it into its own game. I was planning on having a webgl demo of what I’ve got so far, but I haven’t got it working yet.

Thanks for reading! If you want to keep up with what I’m working on check out @PlayingwColor on Twitter.