Among many other goals, I want Antorum to be easy to build content for. A significant part of that is streamlining the pipelines with which new content gets created, made accessible to designers, and shipped to players. To that end, I've finally taken the time to refactor the entire resource loading system of the client and editor.

In Antorum, all items, entities, map data like zones, dialog trees, scripts, etc., are entirely data-driven and controlled by the server. While this approach works well for most things, client-side assets such as Models, AudioClips, Textures, and Materials still need to be managed and compiled through Unity. This means the server only references an asset by a numeric ID (like model ID 123), expecting the client to have the corresponding asset prepared.

Unity, by default, does not expose game assets at runtime. You can't easily query existing assets or dynamically load new ones. The proper solution for this issue is Unity's Asset Bundles. But seven years ago, Asset Bundles seemed intimidating, so I opted for the simpler Resources system. Unity's documentation outlines the drawbacks clearly:

Unity typically doesn't use path names to access assets; instead, you declare a member variable and assign it via the inspector. Unity then calculates which assets to include when building a player. This radically minimizes the build size. When you use the Resources folder, all assets within are included in the build, significantly increasing the size and impacting performance. Additionally, using path names creates less reusable and maintainable code.

The Resources folder solved the problem of dynamic asset access but created new issues. Assets became permanently baked into builds, making modifications cumbersome, and each new asset added increased the game's boot time. Once the game started occasionally crashing on startup due to excessive loading, addressing this became essential.

The solution involved refactoring our existing ResourceStorage system to integrate seamlessly with Unity’s Addressable Asset system and Asset Bundles. The ResourceStorage class manages assets by asynchronously loading them at runtime, caching them for efficiency, and associating each asset with numeric IDs corresponding directly to server-side definitions. This design simplifies synchronization between client and server and significantly streamlines content management.

In order to actually bake these bundles, the new setup has a sort of dedicated "asset builder project". Developers place new assets into the project, click a button to bake the bundle, and the bundle is then placed in the server files and synchronized with clients.

This system significantly improves the content creation pipeline. What previously took an hour or more can now be accomplished in minutes.

Looking ahead, individual servers could theoretically serve their own data files and asset bundles to create entirely unique game experiences. While this is far in the future, the groundwork is now in place.

There's still room to improve, and we're currently limited to Unity's ecosystem for player-facing assets. However, the long-term goal remains clear: to make Antorum as data-driven and modular as possible.

Thanks for your continued support. Also, come play Glorbio.

- Declan (@dooskington)