Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've seen a lot of rhetoric over the year about not using a Public Static class to store global variables or methods that are used across an application.

I understand the philosophy about code maintenance issues that this might present in business software with a number of developers but is there any real performance issues this introduces?

Specifically if the items that have been made public static are used from most classes in the game and prevent multiple instances of a given class from being created. e.g. collision detection, playing audio samples etc.

share|improve this question

closed as off topic by Tetrad Apr 24 '12 at 21:46

Questions on Game Development Stack Exchange are expected to relate to game development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

Performance issues? None that I'm aware of. Even worrying about performance of function calls at the architecture stage smells of premature optimization, a subject of which you will see even more rhetoric about =) Why do you think that games code is any different from business' in terms of maintenance or number of developers? Much game software is pretty complex compared to business apps. – Patrick Hughes Apr 24 '12 at 20:49
@Tetrad I think this question could be very subjective. Should you choose to leave it open, I suggest you mark it with the "We expect all answer to be awesome" flag – Joe Apr 24 '12 at 20:56
Coding style questions like this are 1) super subjective and 2) not really game development specific. If you have a specific question about the performance of these types of things, you could maybe ask on SO (although really the best thing to do is profile and answer your own questions with your own data sets). If you're asking about style and potential unknown ramifications, you might consider asking Programmers.SE. For example, this question might be enlightening:… But I'm closing as OT for GameDev. – Tetrad Apr 24 '12 at 21:46

Tabs vs Spaces, Static vs Singleton.

Yes, make sure you have maintainable code
Don't worry about optimization of method calls right now
Sometimes it is OK to have static properties and methods
Othertimes it isn't
At the end of the day, did you ship a game?

Now That I am done trying to dodge your question, and have surely guaranteed at leas 1 downvote, I'll try to answer it as best as I can.

I see you have the XNA tag, so I will answer according to that. XNA provides a nifty feature that lets you create an instance of a class and pass it around to whatever needs it. Game.Services is what you want to look at. This is great for keeping a reference to a component that needs to be shared.

I like to avoid Singletons, but that is just me. Sometime they are what is best used. Static classes shouldn't be shunned either. Just look at the MediaPlayer class. I can't think of others, but my gut tells me there are a few others that are static.

Take, for example, a collision detection component. If it is expensive to create a new one and it can be shared without problems, perhaps you make it static/singleton. Maybe you store it in Game.Service and access it that way. BUT I would wager that it is very cheap to new one up, and you really only need to have 1 per scene/level. What would be wrong with just creating a new one for each level? Unless your levels change at the rate of a couple a minute you won't really be accumulating that much garbage. Most likely you will only need to new one up every few minutes or so.

I think the last two paragraphs from the article I linked at the top are very fitting

Simplicity is beautiful. Simple doesn’t mean hard-coding, it doesn’t mean cutting corners or being sloppy – it means building what you’ve been asked to build, not a rocket to Saturn and most of the time it’s a skateboard to the corner store.

Not every application needs to be stitched together from Codebetter posts and Twitter rants. Focus on what’s important – the experience, not what’s under the hood. You’ll change that quite a few times no matter what you think :).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.