Game Design with Singleton Pattern
By: Jason Zhen Li
Tags: Game Design, Game Development, Indiedev, Software Development, Game Programming

Game Design with Singleton Pattern

There can only be one, so make it count

This is the 6th entry in the Game Design with Programming Patterns series looking at the game design side of programming. Try the example experiments in the interactive supplement!

Photo by Charles Deluvio on Unsplash

What Is The Pattern?

Singleton pattern objects have two properties: they are limited to one instance of themselves and provide global access to methods and data from themselves. Once created, any subsequent reference to a Singleton object will be that one object — it never creates more than one instance. In addition, any other part of the program can use the object because it is globally accessible. Singleton’s openness lets it provide data and services throughout the rest of the program. As a consequence, hastily applied Singletons create more problems than they solve, leading to Singletons that have more information or behavior than reasonable. Avoid creating unwanted problems by thinking carefully when singular uniqueness and access are needed.

How I Used It

The singleton will track the clicks inside and outside of the scene in the UI at the bottom left. | Clicking on cubes in this scene makes them jump

The nature of the Singleton made the most sense to me as a statistic tracker. By entering the singleton scene, a fairly simple stat tracking singleton instance is created. It counts the mouse clicks both inside and outside of the scene as well as the total seconds the application has been running. The singleton can be told to reset the click count by the button at the bottom and will resume tracking after that reset. Once the singleton scene has been loaded, the object will continue tracking the clicks and time from anywhere. Storing these stats in the singleton keeps them persistent and global.

Design Impressions

Creating a singleton in Unity is easy. Deciding when to create one is hard

A Singleton can be the best place to provide dependable utility and information to the rest of our game. Narrowing a Singleton’s focus to metadata like clicks or time counting lets it operate outside of the game space while still connecting to objects within. The Singleton can hold references to services or methods related to itself, and try to keep other objects from relying too heavily on it. This serves as a basic guideline to avoid bad Singleton scenarios where they become too entangled with other objects and systems.

Going Forward

Singleton objects should be used to address consistent and unchanging demands over the progression of the game, and they should reliably serve those demands no matter what. They are most suited for systems that are independent of specific games. Systems like a game’s rendering, debug, or stat tracking systems all inform how a good Singleton is constructed, that is, by not containing any critical logical functions. They should instead hold complementary processes and information. Holding references to other objects, handling player inputs, or containing “universal” information about a game all are good candidates for Singleton objects. Limited to that external domain, the Singleton pattern finds its place in the implementation details and not in the actual game design.

Previous: Prototype

Next: State

Code: https://github.com/jasonzli/game-programming-study

Reference: Game Programming Patterns, Nystrom, Robert 2014 http://gameprogrammingpatterns.com/singleton.html