• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ATC

The Singleton Pattern: To be or not to be [used]?

80 posts in this topic

+1 for Hodgman and swiftcoder answering what I would've said.

Add to that static initialization issues that will come as static fields/members try to use the memory manager to initialize themselves. Certainly uncommon, but a gotcha that will exist for any singleton implementation.
1

Share this post


Link to post
Share on other sites
[quote name='LorenzoGatti' timestamp='1352306194' post='4998460']
...an [i]implementation [/i]that expects to be the only instance...
[/quote]

I love this choice of phrase and it really highlights a key problem so effectively. You've identified a key failing in this design pattern - a huge dependency on factors outside of it's implementation. I'd +10 if I could.
1

Share this post


Link to post
Share on other sites
I don't understand how you can completely avoid globals? I completely understand to avoid it as much as absolutely possible, but for instance a logger object. Should you really pass your logger instance to all objects in your game that might need logging? And also say for example you use a framework like GLFW for input, how would you pass on the callback without storing some info globally? Edited by KaiserJohan
1

Share this post


Link to post
Share on other sites
[quote name='KaiserJohan' timestamp='1352383448' post='4998860']
Should you really pass your logger instance to all objects in your game that might need logging?
[/quote]

Yes.

Making it global is a time saving measure, that you can usually get away with if you're reasonably certain that the downsides (lack of testability, lack of flexibility, dependency issues, threading issues) aren't such a big deal. Even then, it's not what you [i]should[/i] do and a singleton should never enter the conversation.
1

Share this post


Link to post
Share on other sites
I am repeating for the sake of reinforcing what has already been said.

I haven’t actually yet made an entirely non-global project, but I fully acknowledge that not only is such a project possible, it is actually desirable.
I almost wish the C++ language prohibited globals so that I would not have had any ability to have made such design decisions in my engine.

There is really no exception to the rule that any globals you have indicate a design problem.


I am not really answering your question regarding how it is possible to avoid globals, but:
#1: Unless you ask specifics, no one can answer that.
#2: The point is no matter what you think, there is a way. Of course to learn that way you will need to refer back to #1, and ask the appropriate question(s).


L. Spiro
0

Share this post


Link to post
Share on other sites
I think the real issue about singletons are global scope for types, not global scope for instances of these types. If you have a type that is global, which must not be instanced more than once (or zero), then you have a problem. That is, someone else can, by mistake or misunderstanding, instantiate too many of them. That is what the singleton pattern will prevent.

That said, the singleton pattern isn't the only solution, and usually not the best. It is easy to understand and use, and the lazy way out. Another solution would be to not make the type global. And one solution, as mentioned above, is to actually redesign the type so that it allows multiple instantiations anyway.
0

Share this post


Link to post
Share on other sites
i've yet to see a place where creating a singleton made sense to me, and "just using one instance" wasn't better.

it might be an issue on how to think about problems, but for me, it never ever made sense.

now i do understand why apis sometimes use the single global-to-you access-point, but even that does not need to be a singleton behind the scenes (it might be once-only for your app, but multiple times existing, say, in the os).
0

Share this post


Link to post
Share on other sites
The "there can only be one" approach is more than a little weird also from a modelling perspective. Object systems are typically designed to model real-world requirements: can you think of anything in the real world of which only one can ever exist?

Instances are unique (for example, all humans are subtly different from each other), but classes are never representative of only a single object (there can only be one sheep?).

Even things that we think of as solitary instances typically are not - the statue of liberty is treated as unique, but there is another one in France, and half a million small ones in gift shops.
0

Share this post


Link to post
Share on other sites
Sometimes, when you do top-down systems engeering using a language like UML to describe the software, singletons pop out when an association between objects is found to have a multiplicity of exactly one (1) in either direction.
[url="https://en.wikipedia.org/wiki/Class_diagram"]https://en.wikipedia...i/Class_diagram[/url]

This means that, during run-time, the software itself would NEVER want to destroy or re-allocate this single object instance. Using the singleton pattern for the implementation ensures (through encapsulation of the "instance pointer" or whatever) that it is not possible to destroy/re-allocate the object instance during runtime.
0

Share this post


Link to post
Share on other sites
[quote name='trasseltass' timestamp='1352397571' post='4998948']
This means that, during run-time, the software itself would NEVER want to destroy or re-allocate this single object instance.
[/quote]

No, it means that there's a 1 multiplicity of the object (in relation to others). That you're only referencing one object. It [i]sometimes[/i] means that you only have one object.

It does [b]not[/b] mean that your software cannot (and will [b]never[/b]) deal with two.
0

Share this post


Link to post
Share on other sites
<p><p>[quote name='Telastyn' timestamp='1352398521' post='4998955']
[quote name='trasseltass' timestamp='1352397571' post='4998948']
This means that, during run-time, the software itself would NEVER want to destroy or re-allocate this single object instance.
[/quote]

No, it means that there's a 1 multiplicity of the object (in relation to others). That you're only referencing one object. It [i]sometimes[/i] means that you only have one object.

It does [b]not[/b] mean that your software cannot (and will [b]never[/b]) deal with two.
[/quote]

Sorry, I do not follow at all.

"The UML representation of an association is a line with an optional arrowhead indicating the role of the object(s) in the relationship, and an optional notation at each end indicating the multiplicity of instances of that entity (the number of objects that participate in the association)."

If a car has one (1) steering wheel it does not mean that the car has an arbritary number of steering wheels, or that it [i]sometimes[/i] has one steering wheel - it [i]always[/i] has one steering wheel. If the produced car would have no steering wheels or 5 steering wheels, then it would probably not be the car that we were designing in the first place.

I'm not saying that the singleton pattern is for everyone, just that it solves the design problem of encapsulating a single object instance.
0

Share this post


Link to post
Share on other sites
Lots of good points made here against singleton, the way it should be. If the singleton's singleness is mere convenience, you're doing it wrong.

IMO there's only one "rule of thumb" you need to know: [b]Everything that can be implemented [i]without[/i] the singleton pattern, should be implemented without the singleton pattern.[/b]
2

Share this post


Link to post
Share on other sites
[quote name='Telastyn' timestamp='1352401263' post='4998976']
[quote name='trasseltass' timestamp='1352400093' post='4998968']
If a car has one (1) steering wheel it does not mean that the car has an arbritary number of steering wheels, or that it sometimes has one steering wheel - it always has one steering wheel. [/quote]

Exactly.[b] It does not mean there is only one steering wheel in the entire universe[/b], which is what a singleton enforces.
[/quote]

If you are designing a universe I could see how that would be true. If your "system of interest" is a bit smaller, for example a car, it perhaps only exists one steering wheel.
0

Share this post


Link to post
Share on other sites
[quote name='trasseltass' timestamp='1352400093' post='4998968']
If a car has one (1) steering wheel it does not mean that the car has an arbritary number of steering wheels, or that it sometimes has one steering wheel - it always has one steering wheel.[/quote]
But how many [b]cars[/b] are there? For there to only ever be one steering wheel, there would also have to only ever be one car.

Your UML scenario indicates that there may be many-to-1 relations [b]between objects[/b]. It in no way implies that there may ever be absolute many-to-1 relations.

[quote]I'm not saying that the singleton pattern is for everyone, just that it solves the design problem of encapsulating a single object instance.[/quote]
The "design problem of encapsulating a single object instance" is exactly that, a [b]design[/b] problem.
0

Share this post


Link to post
Share on other sites
[quote name='Ravyne' timestamp='1352401033' post='4998975']
IMO there's only one "rule of thumb" you need to know: [b]Everything that can be implemented [i]without[/i] the singleton pattern, should be implemented without the singleton pattern.[/b]
[/quote]

I can think of four reasons where this may not hold true. I don't say that the following 4 cases always are true, just that there are situations where they are true.[list=1]
[*]Doing an implementation for a thing that there must be only one of in such a way that the design allows for multiple future extensions takes more effort. Usually you have a limited budget, and the singleton pattern is very quick and easy to implement. The designer of the code maybe just isn't experienced enough, and as a project leader you sometimes have to accept something that works, even if it is not optimal.
[*]Testing the general purpose variant of the design may take more effort. (Yes, I know, using global instances of a singleton may also add to the testing effort, but the discussion about singletons is not the misuse of global objects).
[*]A generalized class can cost more CPU time. I am not saying it will, or that it really matters, just that it may be the case.
[*]The factory pattern is based on the singleton pattern. That is, it usually uses classes with a private constructor to force clients to use the factory methods.
[/list]
0

Share this post


Link to post
Share on other sites
> But how many [b]cars[/b] are there? For there to only ever be one steering wheel, there would also have to only ever be one car.

Sorry, I forgot to mention that the system of interest in this example is the car. We're designing a single car and eventually the goal is to deliver instances of this car, maybe in larger numbers. We're not designing and delivering a composite of multiple cars. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Edited by trasseltass
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0