Back to Insights

Asset First Development

While Epic has plenty of fantastic things they’ve contributed to Game Development, one of my personal favorites is the UE4 Mannequin. If you’re not familiar, in the Unreal Engine there is a basic character available complete with animations, simple controls and simple scripts hooked onto it. In many ways, the UE4 Mannequin is the basis for many of the concepts behind Manafold Games.

The reason the UE4 Mannequin is powerful is because it is now a standard. You can easily rig a model to this skeleton and you have a way artists can share a model or an animation between games and studios.

But when work on a game, we seem to always throw away what we have because we want something new. We all have a hubris burning inside of us that thinks we know a way to do things better, and as a result we continue to slowly make more work for one another over time.

Getting to the Fun Faster

We already utilize a process in games called Greyboxing which allows us to quickly generate play spaces to test out the flow of a level, and one of our goals at Manafold is to get to this point and just past it as quickly as possible. Where most games ultimately fail is in the core loop. “Finding the fun”. After all the whole reason we play games is because they’re fun (or because they’re sadistically addicting skinner boxes).

The theory behind Asset First Development is that when starting on a project, rather than coming up with a concept and then requesting the assets you need to get it to Greybox, you instead utilize the assets you have (via Marketplace, Internal Asset Libraries, Open Source External Libraries, etc), and use these to get an implementation in place as quickly as possible.

More Than Just Models

We know this as an MVP, and on its own this might not seem like an overly shocking commitment, but by putting this at the forefront of our development, it means our internal asset teams can focus on creating asset packs (as an example, check out the phenomenal work at Big Medium Small), or a bit of modular code, or a piece of design functionality.

We think of an asset as more than just a model. If you haven’t implemented an inventory system yet, and you can’t find one on the asset store, don’t build a game that needs one.

Our Game Implementation teams are focused on building out good products, while our Asset Development Team builds out the libraries needed to make these products, and while the Implementation Team can certainly request functionality from the ADT, this doesn’t happen during production and Project Chartering.

The Bottom Line

Ultimately this means that when we implement our games, the majority of our time is spent finding the fun and getting to realizing an MVP of the game, and this process can happen more rapidly and with people who are fresh faced in the industry, allowing us a wider degree of perspective and allowing us to Be a Launchpad for the Games Industry.

If you want help applying this thinking to your game or team,

Get in touch