In a previous blog post I mentioned that some of the code could have been structured better. Now that Ball Ball isn’t in its most basic form and has all of the core elements working, both the programmer and I changed some of the code inside of the ball. Rather than all of the other objects waiting to detect when a single object collides with them, and change properties inside of that single object, why not have the single object detect when it collides with things and change its own properties?
Although many more improvements could be made within the game to make it more efficient, and in the case that it would become more complex, more easy to adapt and change. Rather than having 50 pickups and having an individual script, minimize the amount of scripts by having the least amount of objects detect for the majority.
But lets start small with changes like having the ball detect for the pickups that enlarge it and shrink it. There’s multiple ways to do what is being described, but the way that we did it was adding an OnTriggerEnter2D(). And inside this trigger method, check for the colliding objects tag and perform the corresponding code.
It also becomes easier when activating UI elements. So instead of having 4 scripts, 2 of which need a reference each to the UI controller and the ball, there are two scripts. The ball will only need a reference to the UI controller.
This means that there is less room for errors. It also means that there is only one place that code would need to be changed in the event that both the shrunken and enlarge pickup needed changing.
Speaking of UI controllers. Because of the way that this game has been set up, each level is a Scene, and each object is a prefab, or a collection of prefabs.
So because every time a level is complete, a new level is loaded. Each time a level is loaded The GameController and the UIController need access to certain scripts or objects. While it’s appropriate to fill in the gaps through the inspector I can safely say that sometimes I’ve forgotten to fill in one of these gaps. And it causes quite a few issues and wastes time. I like to avoid times like these by making the GameController and UIController get the scripts or objects they need in Start(). I also do the same for some particular UI elements that do or don’t need to be activated on start.
This way, every time a new scene is loaded instead of having to untick every box in the inspector in every scene, it’s already done. So when a Scene Kit prefab is dropped into a level, the only thing that needs placing are the objects that I’d need to construct a level. Other than that, the Spawn point, Ball and Finish zone would have to be moved to the desired location.
I’m sure that DontDestroyOnLoad would have been applicable too, especially to everything in the kit, with the exception of the ball, finish zone and spawn point. But in order to get the prototype working the Scene Kit did perfectly. The DDOL is definitely something worth looking into though, It might have been even more effective and efficient than using a Scene Kit prefab. I’ll have to test this theory later on.
Until next time –