⚠️ Note: most aspects of Abare and Avatar are under active NDA and cannot be shared or screenshotted.

In 2023, after development of TFH had ended, I was assigned to work on two upcoming games that were both powered by Maximum Entertainment’s Abare Engine. From my experience and record on TFH, I was promoted to Technical Director for the upcoming Avatar: The Last Airbender themed fighting game and the existing Diesel Legacy: The Brazen Age. As of this writing, this is my current role.

While the nature of the project is similar, I was now far more integrated with a team and a corporate structure than before. The engine had a far more console-first priority than TFH did.

Since much of the project and details are under an active NDA, I am not generally allowed to include screenshots or detailed descriptions on this page. If you have questions about specific features, please contact me via LinkedIn. In this section I’ll describe some major features I worked on, the challenges of each and how they contributed to the project.

Custom Variable Declarations and flow control

When I first arrived on Diesel Legacy, what I found was a very competent fighting game engine, but the developer tooling was in a rough state. The levels were edited by manually entering numbers on screen, the scripts were largely written in Notepad with no real auto-completion or navigation to speak of, there were no loops in the language, navigation between files was extremely difficult and there was no debugging tools to speak of besides print statements. New variables for characters had to be introduced at the C++ level and script was extremely hard to read due to all ‘general variables’ falling under generic names like Var0, Var1 – Var9. As such, it was very difficult to get new people into the project, and it was very difficult for others to read scripts that they did not write. While all of these tasks were eventually addressed, these were among the most pressing issues.

I expanded the scripting system to introduce custom variables first. This was a challenging aspect due to the way variables were stored inside of the engine: that being a fixed array of values indexed by an enum, essentially. I had to rework everything to be able to access dynamic custom variables that may not exist from both C++ and the scripting language side. The work was a resounding success. Now Abare has custom variable declarations, and effectively a stack, that programmers can use at will to declare whatever they want.

Next up was new kinds of flow control. Namely for loops, which were previously nonexistent, function calls and macros. These are standard features of any language, but are nonetheless tricky to implement from scratch and prove that they work in all cases.

Runtime Debugger

Next was a runtime interactive debugger. This was the most challenging aspect by far. I had never dealt with vscode’s Debug Adapter Protocol and there was very little helpful documentation on how to interface with it. The only place I was able to find any real information or examples was a long set of coding live streams integrating the Debug Adapter Protocol into a custom engine called Vectrexy. After a very, very long weekend, I was able to get a proof of concept up and running inside of Abare. Code breakpoints were now working.

Custom Scripting IDE

The goal of Abare from the beginning was to be a licensed fighting game engine other studios could use. When I entered the project, there was no editor environment to speak of. We were essentially writing in Notepad-like editors with some minimal syntax highlighting. Continuing work from the Abare Debugger for vscode, I created a large and powerful vscode extension with symbol parsing, auto completion, definition finding, link resolution, image previews, localization previews and snippets. Everyone working with Abare moved to this IDE and reported success using it.

Signed Distance Field Rendering for Fonts

Abare previously had no notion of dynamic fonts. All words in the game were put together manually with sprites. This resulted in a huge amount of code and overhead to display simple text on screen. I learned how to render fonts with signed distance textures and created extremely crisp, dynamically generated fonts at any resolution that can be seen in the released game.

Virtual File Systems

Abare initially had no pack files or virtual filesystem. I integrated PYSFS in about 2 days on a crunch deadline, which allowed the engine to read compiled art files and scripts from compressed packages on shipped builds.

Animation and Key frame Editor

One of the biggest issues to solve in Abare is that all aspects of sprites had to be manually animated through code and with math in scripts. This creates cumbersome workloads for scripters and limits the amount of people who are capable of creating such animations. It’s also very confusing to navigate hierarchies of sprites representing singular entities.

I was able to put together a WYSIWYG key frame and animation editor for creating and animating sprite hierarchies and allowing them to have a singular point of control. The representations were extremely compact in memory and very fast to apply, often measured in a few microseconds on my machine.

Due to an NDA, I cannot share screenshots of this feature here.