In this new article we are going to talk about “Addressables“, which is how Unity has named its new memory management policy, much more modern than the classic system, which was comfortable, but very inefficient. Addressables comes to solve this.
Note: we have learned a lot about Addressables while porting "Elva the Eco Dragon" to the Nintendo Switch. Now the game, who has added many new features, has been accepted by Nintendo and will be available for prepurchase next September 9. All our games are now being developed or ported to be "Addressables" compatible.
“Addressables” is a new feature from Unity that comes to alleviate a number of important shortcomings in memory management operations, and incorporates a very important new feature: the possibility of remote updates only of those elements that we have defined, without having to download the entire game in each update. A technology that has a part of science and knowledge, but another part of art. Because there is a manual for Addressables, but not a single way to proceed. It will depend on the game, the objectives, and the developers’ own interests.
Unity Addressables main structure
“Addressables”, the general concept.
In this article we are not going to talk about how to work with “Addressables”, for that there are plenty of tutorials on the Internet. Here we want to explain why it is important to abandon the old memory system, and start thinking asynchronously. Because that’s what “Addressables” is all about: working asynchronously and dynamically with memory.
Changes that are here to stay.
The world is changing fast, technology is changing fast, and Unity, the popular game development tool, is changing too. Those of us who have been using Unity since the days of version 4, from not so long ago, and the current one, are hardly recognizable. Yes, it is true: the base is the same. But nothing more. So many aspects have changed that it almost seems like a new tool.
There is still the idea that Unity is for simple games and Unreal is ideal for complex games. However, Unity has evolved to the point that it is the developer’s responsibility, and not the tool’s, to be able to create high-level games. We are not going to get into the classic discussion of whether you can create a triple AAA with Unity, but it is clear that the tool is evolving rapidly so there is no doubt Unity can help to develop great games today.
In that sense, memory management through “Addressables” is a fundamental change in Unity’s architecture, which forces to rethink the design of the developed games. From the old monolithic and synchronous system, we have moved to another where memory management is very dynamic, with powerful tools to verify its management, and, very important, with the ability to store part of the game in remote servers.
This allows three things: to be able to start the game when it has not yet been completely downloaded, to load only the essential elements in memory at each moment, instead of everything in a monolithic way, even when some part is not going to be used, with the optimization that this implies, and something else: the possibility of being able to include mods easily, if desired. For example, change the textures of our hero, or of the enemies, or anything else that is on the remote servers, and that is updated in the next download of the game.
Not to mention the patches. Instead of a multi-gigabyte patch, we can have patches of key game elements that only take up a few megabytes. Especially important is the logic, the programming, the AI, which is downloaded in seconds.
As long as no new textures have to be downloaded, a major update, for example an AI improvement, can be done without the user being practically unaware of it.
Addressables Profiler where we can control dynamic memory management.
Speed above all.
We live in a world of speed. Everything has to be fast, everything has to be immediate. If for this reason we can start the game while it is still downloading, the player will appreciate it. For example, in our last game, Elva the Eco Dragon, which originally worked with the old memory management system, now only four scenes are loaded immediately on the Nintendo Switch version: the two from the opening intro, which activate the key elements of the game, and the two tutorials. The rest are downloaded asynchronously while the player can start saving the planet without waiting or delay.
Migration to “Addressables”.
Unity has documentation to migrate to “Addressables”, although there are dozens of tutorials also on the Internet. It is important to look for the latest versions of the documentation because changes are taking place, and it is convenient to be updated. The most important concept has a name: “asynchronous”.
Before “Addressables”, any referenced object was loaded into memory directly, whether it was going to be used or not. Now those references are changed in such a way that they point to a logical address, which in turn has a physical address. That is, if I say “Load object A32”, this object had to be in a certain and fixed physical place before. Also, that item was loaded into memory even if the game didn’t use it.
For example: we have to load ten varieties of weapons. But in the game, in the first levels, only two are used. The rest of the weapons will be loading in memory, although it is evident that they will not be used until they reach the level that unlocks them. These loaded objects occupy memory that will not be used.
Logical and physical addresses.
With the “Addressables” references, the object has a logical address, “A32”, but it can point to an area of the system hard disk, or to a remote address. As long as it is not instantiated, or is not expressly told to load into memory, the object will not load. And, when it loads, it will do so from the hard disk or SSD, or, if it has been updated remotely, it will load the new version remotely, save it to disk, and load it. This is perfectly parameterizable for each object or group of objects in a very simple way.
But, in addition, this load is asynchronous. So it is very important not to act on the object, for example the weapon, until it is loaded into memory. For this, each asynchronous load can invoke a method that will let us know when it has been loaded, and very importantly, if it has been loaded correctly, generating a controllable exception if it has not been. But it is the responsibility of the designer to build and design the game under these new premises. What is always loaded? What remains in local asynchronously? What items are placed remotely to be updated? All of this must be taken into account.
Design: between science and art.
That said: it is the designer’s task to see how and in what way this operability is modeled. There will be objects that will always be loaded, such as the objects on the stage, but even so an asynchronous loading is better than a loading that forces everything to be in memory before starting the execution. Hence, as we said before, there is some art and thought in how to organize the game for the best memory management. And our recommendation: every new game should already use this system, and think about migrating already active games, especially on mobile platforms, where memory and resources are always scarce compared to a PC.
Summary: synchronize with “Addressables” as soon as possible.
In short, Unity’s new memory management (new means that it has only been active for three years) is a very important step in the optimization of the resources of each game. And it has important implications in efficiency and user experience. So take the leap as soon as possible. It’s a bit cumbersome at first, but you’ll soon see the results. And they’re worth it, you can be sure.
Unity info about Addressables here.
This article can be linked or copied as long as the source, link and author are indicated. Thank you very much.
