Building Outscal | Land Jobs in the gaming industry | EA, Epic Games, TCS, | CMU, IIT K
Unity gems like Subnautica, Kerbal Space Program, and Cities: Skylines showcased Unity’s potential. But imagine if devs on these games over-complicated the code in the name of “Good Practise”. I've seen many developers get excited after discovering the Observer pattern, only to implement it in ways that can cause more confusion than it solves. Here's how devs are getting it wrong: 🚩 Broadcasting EVERYTHING: "Oh, player jumped? Let's notify every object in the scene!" 🚩 Zombie Listeners: Objects get destroyed, but their listeners linger like ghosts, causing null reference exceptions. 🚩 Stringly-typed Events: Using string identifiers for events, turning your codebase into a typo minefield. 🚩 Massive Event Classes: One GameEvent class to rule them all, with 100+ event types. There's a code snippet of what I am talking about. This approach is a performance nightmare and a debugging hell! So, how can we do better? 🟩Implement a proper event management system with subscription/unsubscription handling. 🟩Consider using ScriptableObject-based events for better decoupling. Now, I'm curious: What's your approach to event systems in Unity? Have you faced any Observer pattern nightmares? Share your war stories in the comments! Let's learn from each other and build games that are as performant as they are fun! 💪 *** We have a complete module on Observer Pattern inside the Game Development Advance Course. Check it out to learn about the right way to use programming patterns Course Link: https://lnkd.in/gUaenkCp Mayank Grover, Mridul Sharma, Malhar Devasthali, Aryan Saxena, Aryan Khera #GameDev #Unity3D #DesignPatterns #ObserverPattern #Performance
There is a simple way to do Game Events and then there are all the other approaches. It's not that complicated to get something going. If you need a specific type of performance, then you usually tailor your systems to do that. But if you just need a generic system, then I tend to use the simplest approach. You can be as coarse or fine-grained as you want really. No need to rely on MonoBehaviours for that and if you want to, let your MonoBehaviours hook into this, rather than the other way around. Your example is way over complicated.
What are your thoughts on using scriptable objects for events?
Using Scriptable Objects for global events increases human error and reduces ease of debugging, code-walking and systems readability. Basically Singletons but with much more problems! But fine for experiments and gamejams.
Yeah singletons for this kind of system is a no go. You'd be better off using observer pattern in a more decoupled way, one of my personal favorites is using Scriptable Objects as channels for broadcasting systems and communicating between scenes without tied coupling. It's cool stuff. I wouldn't use it for player input mechanics tho. It feels over engineering for that since it's best feature is cross-scene signaling decoupling, you gotta strike the balance.
I've begun to heavily utilize the SignalBus approach (from the Zenject DI framework) for event management, which allows multiple listeners to use events and helps decouple systems. It's particularly handy when you anticipate that an action notifier will be utilized by various systems. For example, when a character kills an enemy: * You notify which character killed which enemy. * You also notify the position of the enemy at the time of death. This signal can then be employed to: * Send an analytic report to monitor the number of characters killed within a level. * Create a VFX at the location to conceal the disappearance of the enemy object. * Increase the player's score. The key is to avoid overusing it. The more you use the tools the better you will be at deciding when to use it.
Senior Gameplay Software Engineer - Assassin's Creed Codename Invictus
6moEvent bus is the w2g for coders. For editor side events for my designers I do data based event channels.