Introduction

Design

We initially just intended to build Usagi upon the traditional component entity system. Terminology such as component may sound familiar due to its use in engines like Unity or Unreal, but in fact they bare little relation even to a traditional CES desgin so be sure to read the links to understand the pattern (that said Unity is recently starting to add support for true CES development).

As we continued development we found it was overly involved to construct complex interactions with the systems, and so eventually we decided to try making a hierarchy which was both fundamental to the entities and the systems; this drastically altered how systems were constructed (and their potential to be automatically distributed).

It isn't something we've seen elsewhere so be sure to check the Component System Best Practices and Component entity system coding documents for details on our twist on the design.

Advantages

Usagi has successfully been used to create a multiplayer title on the standard 3DS with destructible environments, animated characters and far more models and particles on screen at once than our previous titles, all at a solid 30fps.
It has also been used to create complex full-resolution 60fps internal demos on Switch and WiiU (dual screen).

The unique hierarchical component entity system we developed was a huge driver of these successes.

Here are some of the benefits:

• Very little branching (largely replaced by system required components and exclusions)
• Minimal code and data cache misses
• Code re-use reduced the amount of overall code required
• Very little interdependence (used correctly changes to one system will not impact other systems)
• Fewer bugs (largely down to improved code sharing)
• Flexible enough to accommodate late design changes without impacting the schedule
• Excellent multi-threading potential
• Design naturally blended with scripts

We found the end of the first commercial project, when the codebase had stabilized, particularly reassuring. Very few bugs or need for optimization meant we had an uneventful debug period without any late nights. From a programmers perspective the engine was a success.

Issues

Although there is a steep learning curve by and large we were happy with how the code design served us, none of the remaining issues seem insurmountable but there are definitely pain points with the engine as it stands now:

We had some compile time issues during development due to the amount of templated code the boilerplate generated; we weren't free to focus on pipeline improvements at the time but said code has since been reduced and compile times are now pretty good. Still, the potential for auto-generated code to bloat remains, there is definitely room for improvement.

The one inescapable downside to a hierarchical design is that when an entity high up the hierarchy has components added or removed the systems to be run on child entities must all be recalculated. There is still lots of scope for optimization to our implementation in of this function but changing entities high up the hierarchy will always incur a cost.

Finally the tool set was always quite limited:

• Animation state graphs had to be written in yaml
• Entity definitions also had to be defined in yaml
• Designers had no visibility as to which systems would run as a result of adding components
• There was no real time debugging for the AI behaviour trees
• Particle editor was very basic and couldn't handle subfolders

To put a positive spin on this though, some of these issues were only highlighted because of the performance successes of the engine. We ended up with far more artist produced particle effects (the need for programmer specially optimised effects was removed entirely) and animations despite the shorter development time.
Work has started on the level editor to allow the creation of entity definitions. But in its current state Usagi is only really programmer friendly.

Additionally in open sourcing the project we had to remove the following tools as they were not internally produced:

• Model material editor
• UI editor

Using Usagi

The open source release is still in progress, it's probably not yet a good foundation for a project even if your needs align with the goals of the engine. At this stage we only expect people to be looking at the CES desgin rather than attempting to implement any projects in the engine.

If you are interested in the engine for producing a title then please see the roadmap for an idea of when this would be feasible.

It's a fairly technical engine aimed at our own team makeup; tools are external rather than being an integrated environment, you'd need at least one programmer with a technical background.