> When less is better Below, I’d like to share my thoughts on my experience working in #Defold on the game I mentioned in a previous [[Vacation Project|post]]. The first stop is about game object architecture in the engine. ![[bruce.gif]] ## **GameObject vs. Collection vs. Proxy** Three entities handle the same idea. I think all these conceptions are too excessive. Let me tell you how things work in different engines. I just wanted to In UnrealEngine, you have a very OOPish approach: Characters are inherited from the Actor, the Actor is inherited from the Object, etc. It's pretty straightforward, but everyone is used to it since the uni courses of OOP. Obviously, you have a level object for level and blueprints for game objects and prefabs. In Unity, you have GameObjects and Components. Composition over inheritance. Great. Scenes for levels. Prefabs are prototypes of GameObjects. Pretty straightforward. In Godot, everything is a node. It is a plain but convenient structure, and you can use it as you wish. The level, the game object, the prefab, and the component are nodes. ![[but_why.gif]] In #Defold… You have GameObject and Components. Great. Similar to Unity. But you also have Collections, which is a set of GameObjects. Ok. It’s still similar to Unity’s prefabs. But it’s also a kind of level asset. Ok. The problems start when we start using all these entities. ## **How can I spawn collections dynamically?** If we consider a collection a prefab, we must use the collection factory component on another game object. In Lua, we call this method on this component. We add the component, set it up, and call it from code. So, the logic is spread across data and code 😒 If we consider a collection a level, we need to use the collection **proxy** component in some other collection. Then we do more or less the same, except we need more boilerplate code to handle collection-level creation (load-init-enable-disable-final-unload). As far as I understand, this code is necessary because Defold creates a new world at the collection level. This new world requires specific message address handling, which makes messaging more complicated when you try to pass anything between objects from different worlds. Also, this requires you to hardcode address names in your code, potentially making the structure very rigid and error-prone. ``` Lua -- unload the level msg.post("#myproxy", "disable") msg.post("#myproxy", "final") msg.post("#myproxy", "unload") -- on level loaded function on_message(self, message_id, message, sender) if message_id == hash("proxy_loaded") then -- New world is loaded. Init and enable it. msg.post(sender, "init") msg.post(sender, "enable") ... end end ``` My main concern is that I don’t understand why there is so much complexity for such mainstream tasks. Level/prefab/game object handling might be one of the most common tasks in game dev: we always need to spawn, destroy, and interact with entities. Why can’t we do it in a more straightforward way in #Lua? Why do we need so much setup in the editor for it? I don’t know, but the docs suppose the only issue is the performance of such dynamic behavior. ## Instead of conclusion Every time I delve into the documentation about game object vs. collection vs. proxies vs. factories, every time I attempt to implement a spawn in Defold, I can't help but feel that this system is a little overwhelming. It doesn’t feel right. There are so many extra entities, and aligning with my existing knowledge is a challenge. I recognize that this learning curve is expected with new approaches, but I’m not sure it’s as intuitive for newcomers in Gamedev. Nevertheless, I persisted and managed to accomplish what I set out to do. The handling of gameplay levels and prototypes could be more straightforward. But, as the saying goes, if it works, it works. Honestly, I won’t use collection proxies at all. They introduce more pain than relief, and I don’t expect built-in engine approaches to be so for such a trivial task. I think it’s better to write your own system for game objects and handle it there. It's much easier to handle messaging, load/unload events, etc. I don’t want to sound overly critical, but Defold's game object handling may be its most minor elegant aspect. However, I want to emphasize that everything else about Defold is significantly better and enjoyable. ![[not_so_easy.gif]]