Singleton vs Event & Method Chaining vs Caching Objects Before Method Call

Hi!

  1. Can you elaborate on the trade offs between using a singleton vs using C# events here? Couldn’t this have been done in a more decoupled way via a C# event that the LevelGrid processes, which takes the Unit and its world position?

Is it better to couple the LevelGrid and Unit via the singleton as mentioned here? If writing the game with unit tests, wouldn’t the use of C# events for this functionality also make the code more easily testable?

  1. I’ve noticed that you tend to opt to store local variables for each call, avoiding method chaining. What’s the reasoning behind this? And is there any performance difference when creating all these extra local variables throughout the code vs using method chaining?
    For example:
public void AddUnitAtGridPosition(GridPosition gridPosition, Unit unit)
    {
        _gridSystem.GetGridObject(gridPosition).AddUnit(unit);
    } 

VS

public void AddUnitAtGridPosition(GridPosition gridPosition, Unit unit)
    {
        GridObject gridObject = _gridSystem.GetGridObject(gridPosition);
        gridObject.AddUnit(unit);
    } 

What specific part of this lecture are you referring to?
I’m not sure what you mean by Singleton Vs C# Events. Singleton is just a way to get a reference, C# events require a reference. They do different things so I’m not sure I understand how you are comparing them.

In terms of performance chaining them will be faster.
But it will be faster by a miniscule amount so in that case prioritizing code readability is the better approach and I find the second method to be more readable than the first.

Apologies, my understanding of C# events seems to be a bit poor, and I may be taking the general advice I’ve seen to avoid singletons as much as possible to heart a bit excessively.

I suppose I’m thinking about something like Godot’s signal system and the emphasis I saw placed on signaling up.

So I believe my thoughts in asking this were related to the idea of having an event the unit would fire off when it moves, with a reference to itself and its’ world position, which the LevelGrid would receive in order to update data regarding which units are in which GridPositions. This being the case instead of making LevelGrid a singleton and exposing functions for the unit to call directly.

Perhaps I’m wondering whether there’s any way to avoid the Unit having to be aware of the grid specifically, and whether that’s even a good idea in the first place to avoid making the class a singleton. Similar to how the UnitActionSystem is aware of the selectedUnit, but the unit itself isn’t aware of the UnitActionSystem at all. This stems from some uncertainty as to when a singleton is and isn’t justified.

Hopefully that clears my question up a bit. I ran into some of the pitfalls of singletons with my previous commercial release and am more wary of them now as a result. That said, grid-based games seem to have some specific challenges to deal with when it comes to trying to avoid coupling.

I wasn’t sure if it was due to preferences with regards to readability or not, so I appreciate the clarification!

Yes that is indeed a valid option, you can make the Unit fire an event when it moves Grid Position and have the LevelGrid listen to it and run the same function.
Decoupling is usually a good thing but how much of it you need will depend on the game you’re trying to make.

For the design that I was going for I wanted Units to know that there is a LevelGrid and I wanted the LevelGrid to know about Units. For the design that I wanted to make both of those are crucial pieces that are meant to work together.
So because of that design decision keeping them loosely coupled is not a problem.
If you did have a design where you wanted the Units to function even outside any kind of LevelGrid, in that case yes refactoring the code to avoid any mention of LevelGrid would indeed be a good approach.

The singleton pattern can indeed be easily abused, however that doesn’t mean you can’t use it properly. It’s just another tool, as long as you use it correctly you shouldn’t be afraid of it.

2 Likes

Thank you for the explanation!

I agree that the singleton pattern is a useful tool that shouldn’t be avoided entirely. As mentioned, it’s a matter of knowing when to use it and when to choose other methods such as C# events or having an object store a reference.

I appreciate hearing the thought process that was behind the decision to select the singleton over other methods in this case.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms