Project Battlefield: Part 2

---

Overview

An action platforming fighting game heavily inspired by Super Smash Bros.

June – Sep. 2016 Game physics, several character control code iterations

Oct. 2016 – Present Opened to VGDC UCI club members as a Quarter-long learning project.

Back to Part 1

---

Building a State Machine

My refactoring effort began by binning almost everything I had built.

The only scripts I kept were the physics script and the input script. Everything else bit the dust.

After my best efforts to use Unity’s Animator, it wasn’t producing the results I wanted. I decided to create my own state machine.

First, I wrote the state class. State contained a name and a dictionary of transitions. Each transition mapped an event string to the name of another state.

Next, I wrote the StateMachine class. StateMachines held a dictionary of States mapped by name. It also kept track of the current state. A Tick() function would take an event string, check the current state’s transitions, and move to the new state.

Actions

While a state machine is nice, it wouldn’t mean anything without affecting the game. So I created an Action class.

Polymorphic actions were something I used while building Rog. For the state machine, States would contain a list of Actions to perform on entry or once per update.

Action subclasses affected a character’s physics or played an Animation. Animations still changed hitboxes and activated scripts, but they were not bound to any specific state.

ActorScript

No longer having to handle state machine duties, the character control script ActorScript became much leaner. Now, it simply took input data and produced event strings for the state machine to process.

The Editor

Thinking back on difficulties generating assets for Rog, I wanted a way to visually edit state machines.

C# has a library called System.Xml.Serialization that can represent instances of classes as XML files. Storing state machines as XML files meant I could load them into an editor window to make changes and load them at runtime for the game.

I designed the editor window to make large changes as easy as possible. There are also several options to show or hide information.

The editor definitely has a learning curve, but I’d like to think it doesn’t dumb anything down. Once designers join the project I’ll have feedback on its design.

---

Project Battlefield: Smash Reborn

Now it was time to build something.

To meet an exceptional level of quality, I needed to push every system to the absolute limit. Kirby: Planet Robobot and Kirby: Triple Deluxe generate interest through a large variety of level mechanics, powers and cohesive aesthetics. In order to focus on testing the state machine, I wanted to emulate a game more focused on character controls.

As you may have guessed from part 1, I chose Super Smash Bros.

I quickly defined a few states to see where it went. Perhaps it’s simply because I built it, but using the tool came naturally to me. I could fluidly add new physics actions or change transitions

After about a week of experimenting, I produced something I felt resembled Super Smash Bros.

---

Next Steps

Next, I opened the project to members of the Video Game Development Club at UC Irvine. Because of all the great experiences I had with the club, I wanted to bring students into the project to pay the way forward. To prepare, I spent a few days working out as many kinks and inconveniences in the editor and state machine as I could find.

My hope is they get as much out of this project as I have, and that we hopefully make something really cool and engaging.

More to come. Thanks for reading!