Whenever you’re making a save system or you’re making cross-scene references, you might come across a need for a unique ID for all your GameObjects. You might think Unity offers a solution for this, but there’s no clean solution offered yet.
Internally, each GameObject does have a UUID, but this value changes every run. This basically makes this value unusable.
Unity provides a git repository called guid-based-reference (https://github.com/Unity-Technologies/guid-based-reference) that provides this feature, but this comes with multiple disadvantages.
- A prefab instance’s Guid shows up as modified compared to the prefab. If you accidentally apply all changes, then this library will die.
- Guids are illegible. Wouldn’t it be better to mention an important GameObject as
BossCharacter rather than
- Small memory inefficiencies. There are extra 8 bytes per instance to store a reference to a byte array. The sad part is that this array is only used during Unity’s serialization/deserialization.
Here’s how CloudCanard’s UUID system handles these issues.
For the past 2-3 weeks, I’ve been making an internal tool to plan out the world map for CloudCanards.
For those of you who don’t know, CloudCanards is a game development project that me and my team have been working on for the past two years. It has a 2D pixel art aesthetic, but level design wise, it is a 3D Metroidvania with interconnected regions. We needed a way to efficiently plan out the open world while keeping track of which areas the player could visit with specific powerups. This led to the creation of our World Planner tool.
The entire world is represented by a graph where each node is an area and each edge is a connection between two areas. These connections might have requirements that that player needs to acquire before being able to traverse through.
What’s interesting is that the entire tool is heavily integrated into Google Firebase, allowing all of us to edit the graph concurrently. It’s pretty fun to fly around the world planning specific regions together.
Tokei is telling me that I wrote around 4,000 lines of code for this project, which is pretty low compared to the main CloudCanards repository. I was pretty surprised at how intuitive it was to implement Firebase Realtime Database into the project.