Game development (or really any kind of software development) is often a learning experience. You start out implementing something that you’ve never implemented before, and suddenly, you gain some insight that tells you that you should be doing things differently than the way you are currently doing them. Inevitably, this insight makes you go back and refit portions of your work to match your new mental model of how things should be done.
Such was the case last year when I redesigned how Dehoarder 2 manages its assets. When I first started this project, Unity 4 was the current version, which only had AssetBundle support for Unity Pro users. AssetBundles allow you to separate your game assets (models, textures, sounds, etc.) from the main build of your game. This has a number of advantages over having all of your assets in the main build of the game, including better management of assets in memory, being able to release new and updated content without rebuilding the game executable, and supporting complex mods to the game.
Last year, I migrated all of my “enumerable” assets (things like junk and furnishings) to the AssetBundle system. However, many other “base” assets, (such as the house, terrain, and the rest of the neighborhood) remained in the main build of the game. What this meant from a functionality perspective was that mods couldn’t easily replace those portions of the game. It would prevent someone from doing a “total conversion” style mod, where the entire setting could be changed to, for example, a high-rise apartment. It also meant that some assets were duplicated between the main build of the game and the asset bundles. I never intended for this to be final state of things, but had other project priorities at that time, such as preparing new content for last year’s GDEX.
I am sometimes frustrated by games that claim to have modding support, only to find out that that support is limited to things like creating new copies of specific existing objects, changing their stats and/or graphics. Thus, I wanted to make sure that Dehoarder 2 supported a robust amount of modding.
In recent weeks, I have been migrating these “base” assets into asset bundles, completing the work that I started last year. My gameplay scene now looks very empty, with only a few management and user interface objects present during design. Everything is now dynamically loaded from the asset bundle when a saved game is loaded. With a few more changes to the “New Game” UI, I could easily support starting a new game from a completely custom map created by a modder. To give an idea of how much of the game has been shifted to AssetBundles: In my latest build, the AssetBundles total 1.01GB, while the game engine itself weighs in at only 94.5MB.
One downside to the AssetBundle approach in regards to modding is that for sufficiently complex mods, they will need to be developed using Unity and packaged as AssetBundles themselves. Fortunately, I can still pretty easily support simple mods, such as object and texture hacks, without requiring development of AssetBundles. I’m not too concerned about requiring AssetBundle development for complex mods, as I’ve seen similar requirements for other popular games, yet their Steam Workshop areas still overflow with mods. ARK, for example, requires that even the simplest mods be developed in Unreal Engine.
What distinguishes a simple mod from a complex mod in the eyes of the Dehoarder 2 engine? It mostly comes down to the question, “can the asset be trivially imported and processed by the Unity runtime?” Things like textures and the XML definition files for the game fall on the “yes” side of this question. Things like new terrains, new 3D models, and sounds currently fall on the “no” side of this question.
The other downside to using AssetBundles for mods is that including new MonoBehaviour code in AssetBundles is not possible. Objects in AssetBundles can refer to MonoBehaviours included in the core build, but AssetBundles cannot define new MonoBehaviours. This is a limitation of the Unity AssetBundle system. I don’t anticipate this being very limiting, due to the Dehoarder 2 engine including a domain-specific game event scripting system that is Turing-complete.
My advice to other Unity developers regarding AssetBundles is as follows: If your game is going to be of sufficient complexity, figure out your AssetBundle strategy early, before you have hundreds of objects that need to be migrated, costing dozens of hours in rework. If you have a lot of content in your game, loading and unloading assets is one of those fundamental things that you will need to manage yourself. Conversely, if you have a limited number of assets, memory use is not a concern, and the set of assets in your game is not expected to change after release, you can skip the complexity of AssetBundles entirely.