Engine Status Report

Unlike a lot of modern games, Project ASH uses a custom game engine. That isn't to say that every little thing in ASH is custom - there are a couple of off-the-shelf solutions used for input (such as SDL) and we currently use Steam Audio as our 3D audio solution.

However, a lot of our resources has gone into building our custom game engine, and it's one of the reasons that there has been a lot of time since our last release and we haven't been able to show too much.  We've teased a few screenshots here and there, but due to the incomplete nature of having to build everything we haven't posted too much.

One of the reasons that the License test was so limited was that the engine was solely tailored around accomplishing it. There was so much barely finished, barely started, and barely working that it is a miracle the launch went as smoothly as it did. While a few people had bugs, and a lot of people couldn't run it due to our choice to use Vulkan as our only graphics API, the launch went relatively smoothly for those that did get to play it.

Things are going pretty well overall, and we're happy with the direction of the engine. But a lot of people have asked us in the past: Why use a custom engine? Well, there's a simple answer.  Our coder, Vector025, prefers being able to solve problems instead of work-around them.  By using a custom engine it allows us to be completely in control of everything. There is no problem we can't solve, as we can literally design the engine around solving any issues that come up.

Still, choosing a custom engine has made our development path a lot different, and it makes game development a lot more experimental.

Building From the Ground Up

Building a custom engine has a lot of benefits, but it also brings forth a ton of challenges. There are a lot of things that are simply free when using Unreal or Unity that are instead tremendous efforts for us. All of ASH's physics, rendering, and AI routines are entirely custom. There aren't going to be model exporters for our engine, we instead have to write our own scripts or support existing ones. The entire process of creating assets for ASH is up to us to create and streamline. This is a lot different than something like Unreal or Unity, where importing/exporting models from a variety of editors is just a given.

We're also working on a much lower level than you would need to for most engines. One of the biggest decisions we made with the previous demo was to use the cutting edge Graphics API, Vulkan, rather than the older, more limited OpenGL. This meant that many older graphics cards didn't support ASH, and it turns out a lot of Mega Man Legends fans didn't have cutting edge computers. This misstep resulted in a lot of effort being poured into a second renderer that used OpenGL instead of Vulkan, so that users on older machines at least had a chance to play it.

Something like this is a tremendous maintenance cost, and while we're working on ASH, OpenGL ends up broken a lot of the time. But, when it comes time for our next release, having OpenGL working means we'll be able to support more machines and give people more options.

In terms of graphics, stylization, and rendering, all of the tech powering ASH's engine is essentially custom. We've had to figure out how we want things to look and feel without much for guidelines. Stuff like creating lighting solutions and algorithms, then figuring out how we want to light areas has been a learning experience. What lighting features do we need? Will we need to cel-shade characters/levels? These questions are ongoing in some cases, but we continue to march forward nevertheless!

Learning Yourself

ASH is a throwback to a different era of games. Mega Man Legends is a classically designed game: It's weird, it's built weird, the pacing is weird. But we love it for what it is. It was built in an era where the developers weren't exactly sure what they were doing and had to come up with ideas and solutions as they went. It's very hard to see a game with Mega Man Legends' control scheme releasing in the modern era, as everything has been more-or-less standardized.

As we develop the project, we keep in mind that it's okay to be weird. Our solutions don't have to be normal. We don't want to be a modern game. Whether it be gameplay, graphics, AI, or anything else, we're just kind of winging it and seeing what we find good or fun.

The engine itself is tailored toward how Mega Man Legends plays:

• Designed to handle small, isolated areas with some persistence between rooms.
• Renderer able to dynamically light/shadow moving objects within small rooms without them sticking out. By using realtime Global Illumination, we can seamlessly blend dynamic objects with static geometry.
• Highly detailed collision detection to allow for part destruction and bonus damage on Reaverbots/Mechs
• Ragdoll physics for Reaverbots/characters to introduce a dynamic element to combat.

If you haven't noticed, almost all the engine features are biased toward the ruin. And there's a good reason for that - we haven't done much work on the overworld. In order to handle the bigger areas, stuff like realtime global illumination can be disabled since it won't matter quite as much. While we have done some things to make sure sprawling, open areas can be supported, a lot of the other features needed for the overworld have been put on the back burner.

And that style of development really fits a custom engine. We literally have nothing to work from. No direction an engine is pushing us. Unreal and Unity specialize in certain types of rendering, certain types of games, and certain types of workflow. We're just out here trying to make a game and letting it take us where it will. Is it the most efficient workflow? Absolutely not.

But, we created a fun framework for a Mega Man Legends fangame that we enjoy playing and want to make bigger and better over time. We'll dive into the details of some of the engine features we've worked on and how they affect the game, so stay tuned!