Capstone Blog #5 – Refactoring and Fighting Game Essentials

Standard

Since last week I spent a lot of time prototyping the more experimental mechanics, I spent this week getting down some of the fighting game essentials.

Pushback

Last week I had implemented push forward, where a move like a sweep will slight reposition you forward. Another key aspect is push back, which is the amount that a player gets knocked back when either blocking or hit by a move. Not only is this vital to game balance, but this also helps give a move a sense of impact. Both a move’s push back and push forward all fully customizable by the designer in the editor.

Throws

A lot of my time this week went into getting throw logic in. For those who are unfamiliar with fighting games, a throw is an attack that cannot be blocked – it’s how you put pressure on an overly defensive opponent. The catch however, is that your opponent can react to a throw by also inputting a throw – therefore “teching” it and putting both players back at a neutral position.

lucha throw.png

Got ’em.

Next to rope shenanigans, throw logic is probably the most complex mechanic I’ve had to code so far, what with all the conditions and animation states that come with it. I put in some extra time making sure it played nice with the systems I already had in place.

Meter

What’s a fighting game without supers? Well, while supers are definitely on the list, you can’t have supers in fighting game without meters!

luchameter.png

I swear the UI will look a lot cooler soon.

I spent some time this week setting up a multilayered meter system where the player can stack up to 5 supers worth of meter. I also set up the design pipeline so that our designer can tweak and fine tune just how much meter is gained when a move is hit, blocked, etc.

Refactoring

One big focus this week was refactoring a bit of code. While prototyping a lot of these mechanics so rapidly, I started realizing that I wasn’t really using inheritance to its fullest. The main issue is that the animation states were unique to the fighter sub class, so the base class had no access to it. I set this up, thinking that each character would be unique and that it wouldn’t be that big of a deal in the future. However, I found myself having to write a function specific to a subclass just to make room for that one line of code involving the animation state.

I took some hours and opted for a more universal animation state system. Where the all the states that every fighter will share are all in the same order, and any unique states will be handled at the end of the list, there by not interfering with the states that everyone is gonna use. This lets me port a lot of sub class specific code over to my base class. Just to show some numbers, my subclass line count went from around 500 to 100 after I made my changes. Though my base class line count went up quite a bit (its in the 1000 range now), it’ll definitely be a worthy investment as we add new fighters to the game. Anything that reduces my workload and the chance for character specific bugs is a plus for me.

Conclusion

When I first sat down to write this, I felt like this was a slow week. Looking back however, a lot got done! Our team is already eyeing up the next challenge, so there’s a lot more to work on, but I’m honestly extremely satisfied with the rate our team is going at. Also, we finally got our art pipeline worked out! Expect to see some cool 3D models in the game next week.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s