The Observer pattern is very commonly used and is one of the Gang of Four design patterns which are meant to solve design problems and create reusable object-oriented software.
The book chapter from the book Game Programming Patterns by Robert Nystrom on the Observer pattern provides an example of its use in specifically game design (an achievement system), however its implementation remains the same as it would in any other type of software. The pattern essentially allows communication between systems without having to couple them together. It does this by creating observers that receive notifications from the subjects that their observing and sharing that information.
In the example provided by the chapter, it shows how a physics system can communicate to an achievement system to unlock an achievement where the player falls off a bridge:
It does this without having to couple the two systems together and eventually creating a huge mess of code.
The author then goes on to describe some concerns and potential problems of using the patterns, such as speed and memory allocation, as well as their solutions. Although even if you implement this or any design pattern correctly and efficiently, it doesn’t mean that it’ll work well depending on whether or not it’s applied on the right problem.
I chose this chapter in particular because it’s likely that we will be using this pattern in the future. Also I think it’s interesting to see how these design patterns can be used in game development, so it may be useful to others who are interested in developing games. I used this pattern in the past for a system where the physics system would notify the observer when a collision happened and it would tell the sound system to play the sound for that collision. I ended up running into a lot of problems due to my poor implementation of the pattern, getting errors because of improper memory allocation. Referencing the examples from this chapter helped me learn how to fix these issues and optimize my code. However, while using the Observer pattern for my audio system worked properly, I ended up doing it differently afterwards using a service locator to provide a global point of access to the audio system as well as an event queue to prevent multiple instances of the same sound from playing at once and blowing out my ears. Although I wouldn’t use the Observer pattern in this situation again, it’ll probably be useful in the future.