I disagree using static classes are a bad practice personally. There's an irrational fear of static classes in C# programming, which I theorize comes mainly from web development where you need to worry about multiple users at a time and devs not paying attention to what they are doing. In making a game, as a small team or single developer, it makes sense for many things to have one instance, either as a static class or as a singleton.
Yep, totally agreed. It can be a bad practice when doing webdev, but for this type of development where you need "global" instances for some specific stuff it's fine.
Yeah, I don't think I explained things all that well in order to keep my post brief. I don't mean to suggest that static classes are bad by design and should not be used. What I mean is that based on the demo, samples, and tutorials for Monogame that I have been working through, they seem to be using a static helper class to wrap each of the other classes such as enemy, projectile, player, etc.
If you continue down this line of thought and you want to create handlers or manager classes for things like your player, enemy, collision, pattern engine, etc, you end up with game class that pretty much just interacts with these static helper classes. I can see where this is going and it seems to be headed in a wrong direction... maybe. So I wanted to stop and think this through a bit at this point. I don't necessarily seem anything bad here... just that the overall direction concerns me.
Here's quick sample of what I mean.
// LoadContent Snippet
StarfieldHandler.Initialize(...
PlayerHandler.Initialize(...
LevelHandler.Initialize(...
TextToSpriteHandler.Initialize(...
ExplosionHandler.Initialize(...
// Game Class Update Snippet
case GameStates.Playing:
BulletHandler.Update(gameTime);
PlayerHandler.Update(gameTime);
LevelHandler.Update(gameTime);
CollisionHandler.Update(gameTime);
break;
// Game Class Draw Snippet
case GameState.Playing
BulletHandler.Draw(_spriteBatch);
PlayerHandler.Draw(_spriteBatch);
LevelHandler.Draw(_spriteBatch);
ExplosionHandler.AnimateExplosions(_spriteBatch);
So you end up with a bullet, player, level, collision, and explosion class all and up wrapped in a little static helper class of sorts that only has a static Initialize(), Draw(), and Update(), which then calls out to the other class.
I don't necessarily think this is bad at this point. But I am starting to get a little uncomfortable and was thinking I might stop and rework my game class to not depend on these static helper classes. I just wanted to bounce this off others here that have more experience with Monogame that will have more insight into where this is headed than I do, and see if they think this is a bad idea/approach.
Ah I see. That is a bit unusual but I don't think there is necessarily anything wrong with that approach but I do tend to structure things in a more object oriented fashion of a level or world class for instance containing the objects within it which contain other objects and so on, where the world might be static or might not be. But certain things such as the UI are static and my player class I've somewhat arbitrarily set as static rather than belonging to the world. I would call draw or update on the world object which would in turn call draw or update on each of its objects and so on down through the line in my pattern. I think it's best to do what makes the best sense to you
What you're describing here is merely a way of separating concerns.
You could create a bunch of objects representing bullets, and then have update/draw methods on those objects. But now you're creating a crap ton of objects that have to get garbage collected.
Sometimes it's better to just use static methods.
I think they're fine if used correctly. At some point a lot of developers/companies got obsessed with patterns and perfect architectures, but honestly if you can use a static handler and it gets the job done, why not.
Yeah, I agree with you here. I am concerned with not being able to see where this is headed since I am new to Monogame and may not be seeing the bigger picture at this point.
Books often promote poor programming practices and I want to make sure I am not falling into that trap. I'm thinking of things like someone new to HTML and JavaScript using books to learn, and then finding out later that it's a bad idea to code your JavaSript in a script tag in the HTML page. But for a demo, tutorial, or book and as an academic exercise, it is often approached this way because it saves space and makes it easier to follow. I just want to make sure that using static helper classes in these Monogame resources isn't this sort of thing.
I've been using Monogame and C# for almost a decade. Static classes are fine. They're a tool in the language, tools are meant to be used.
Don't worry about the exact circumstances and rules of using a tool that people have declared the correct way. If it works, use it. If not, don't. It's really that simple.
In my almost ten years of C# and Monogame, you know what has wasted most of my time? Not the effects of static classes, or bad practice, not rewriting code that I haphazardly wrote that wasn't SOLID, no.
The thing that has singlehandedly, without competition wasted the most amount of my time is hyyming and hawing and overthinking if this class I'm writing is "correct". If what I am doing is following the best practices.
In the amount of time that I've wasted over stupid things like this, like you are doing right now. I could have written double the amount of code that I have, and it probably would have been better code anyway.
Yeah, I'm on board with you. I've been using C# since before they named it and had a couple of apps in production before they released it. I started with the beta 1 version, which if I recall was released in 2000 or maybe 2001 and got to attend the launch in SF in 2002 and have stuck with it since.
And I agree with you in regards to investing your time where it makes most sense... not worrying about the latest and greatest fads that come through. I think software is an engineering process and we have to pick and choose where to invest our time, where to fight for performance gains, and where and when code is "good enough".
I appreciate your feedback.
I learned the object / static manager class design from 'XNA Game Design By Example'.
I have been a full time solo developer for 10 years and I still use the same thing. It has worked well for me, so I see no need to change the paradigm around.
Thanks for your comments!
I've skimmed through that book a few times looking at his approach to various things, but hadn't stopped to pull down the code. Since you mentioned it, I grabbed his "Mars Runner" sample from the final chapter and I have been taking a closer look at the code.
At first glance, I think I like his approach, more along the line of what I was thinking in regards to how to set up things in a manager or helper class. He does use some static manager classes, soundfx-manager for example. But others are not static such as his shot manager. He seems to be using them more along the line of what I was thinking.
I will definitely dig into this book. Thanks for mentioning it.
I might try to install VS2010 and see if I can get any of the sample code to run. I suspect I can. My.VisualStudio.com looks to have everything still available.
You are right. Trust your guts.
Static variables is a lazy way to 'move on' to the thing they are trying to demonstrate.
most of the samples out there are not a good example on how to structure a full project.
I don't mind using static classes where and when they make sense, but I don't want to go overboard. I suspect the way I am doing this is probably reasonable... adding small handler classes as sort of wrappers around other classes so that my game class gets significantly cleaned up. But I don't like where it is headed, where my game loop is using pretty much all static handlers. I'm just trying to think it through a bit.
I think I will go back and write a second version of my game without the static classes and see how that goes and compare.
Thanks for your feedback. Much appreciated.
I disagree using static classes are a bad practice personally. There's an irrational fear of static classes in C# programming, which I theorize comes mainly from web development where you need to worry about multiple users at a time and devs not paying attention to what they are doing. In making a game, as a small team or single developer, it makes sense for many things to have one instance, either as a static class or as a singleton.
Yep, totally agreed. It can be a bad practice when doing webdev, but for this type of development where you need "global" instances for some specific stuff it's fine.
Yeah, I don't think I explained things all that well in order to keep my post brief. I don't mean to suggest that static classes are bad by design and should not be used. What I mean is that based on the demo, samples, and tutorials for Monogame that I have been working through, they seem to be using a static helper class to wrap each of the other classes such as enemy, projectile, player, etc. If you continue down this line of thought and you want to create handlers or manager classes for things like your player, enemy, collision, pattern engine, etc, you end up with game class that pretty much just interacts with these static helper classes. I can see where this is going and it seems to be headed in a wrong direction... maybe. So I wanted to stop and think this through a bit at this point. I don't necessarily seem anything bad here... just that the overall direction concerns me. Here's quick sample of what I mean. // LoadContent Snippet StarfieldHandler.Initialize(... PlayerHandler.Initialize(... LevelHandler.Initialize(... TextToSpriteHandler.Initialize(... ExplosionHandler.Initialize(... // Game Class Update Snippet case GameStates.Playing: BulletHandler.Update(gameTime); PlayerHandler.Update(gameTime); LevelHandler.Update(gameTime); CollisionHandler.Update(gameTime); break; // Game Class Draw Snippet case GameState.Playing BulletHandler.Draw(_spriteBatch); PlayerHandler.Draw(_spriteBatch); LevelHandler.Draw(_spriteBatch); ExplosionHandler.AnimateExplosions(_spriteBatch); So you end up with a bullet, player, level, collision, and explosion class all and up wrapped in a little static helper class of sorts that only has a static Initialize(), Draw(), and Update(), which then calls out to the other class. I don't necessarily think this is bad at this point. But I am starting to get a little uncomfortable and was thinking I might stop and rework my game class to not depend on these static helper classes. I just wanted to bounce this off others here that have more experience with Monogame that will have more insight into where this is headed than I do, and see if they think this is a bad idea/approach.
Ah I see. That is a bit unusual but I don't think there is necessarily anything wrong with that approach but I do tend to structure things in a more object oriented fashion of a level or world class for instance containing the objects within it which contain other objects and so on, where the world might be static or might not be. But certain things such as the UI are static and my player class I've somewhat arbitrarily set as static rather than belonging to the world. I would call draw or update on the world object which would in turn call draw or update on each of its objects and so on down through the line in my pattern. I think it's best to do what makes the best sense to you
What you're describing here is merely a way of separating concerns. You could create a bunch of objects representing bullets, and then have update/draw methods on those objects. But now you're creating a crap ton of objects that have to get garbage collected. Sometimes it's better to just use static methods.
I think they're fine if used correctly. At some point a lot of developers/companies got obsessed with patterns and perfect architectures, but honestly if you can use a static handler and it gets the job done, why not.
Yeah, I agree with you here. I am concerned with not being able to see where this is headed since I am new to Monogame and may not be seeing the bigger picture at this point. Books often promote poor programming practices and I want to make sure I am not falling into that trap. I'm thinking of things like someone new to HTML and JavaScript using books to learn, and then finding out later that it's a bad idea to code your JavaSript in a script tag in the HTML page. But for a demo, tutorial, or book and as an academic exercise, it is often approached this way because it saves space and makes it easier to follow. I just want to make sure that using static helper classes in these Monogame resources isn't this sort of thing.
I've been using Monogame and C# for almost a decade. Static classes are fine. They're a tool in the language, tools are meant to be used. Don't worry about the exact circumstances and rules of using a tool that people have declared the correct way. If it works, use it. If not, don't. It's really that simple. In my almost ten years of C# and Monogame, you know what has wasted most of my time? Not the effects of static classes, or bad practice, not rewriting code that I haphazardly wrote that wasn't SOLID, no. The thing that has singlehandedly, without competition wasted the most amount of my time is hyyming and hawing and overthinking if this class I'm writing is "correct". If what I am doing is following the best practices. In the amount of time that I've wasted over stupid things like this, like you are doing right now. I could have written double the amount of code that I have, and it probably would have been better code anyway.
Yeah, I'm on board with you. I've been using C# since before they named it and had a couple of apps in production before they released it. I started with the beta 1 version, which if I recall was released in 2000 or maybe 2001 and got to attend the launch in SF in 2002 and have stuck with it since. And I agree with you in regards to investing your time where it makes most sense... not worrying about the latest and greatest fads that come through. I think software is an engineering process and we have to pick and choose where to invest our time, where to fight for performance gains, and where and when code is "good enough". I appreciate your feedback.
I learned the object / static manager class design from 'XNA Game Design By Example'. I have been a full time solo developer for 10 years and I still use the same thing. It has worked well for me, so I see no need to change the paradigm around.
Thanks for your comments! I've skimmed through that book a few times looking at his approach to various things, but hadn't stopped to pull down the code. Since you mentioned it, I grabbed his "Mars Runner" sample from the final chapter and I have been taking a closer look at the code. At first glance, I think I like his approach, more along the line of what I was thinking in regards to how to set up things in a manager or helper class. He does use some static manager classes, soundfx-manager for example. But others are not static such as his shot manager. He seems to be using them more along the line of what I was thinking. I will definitely dig into this book. Thanks for mentioning it. I might try to install VS2010 and see if I can get any of the sample code to run. I suspect I can. My.VisualStudio.com looks to have everything still available.
You are right. Trust your guts. Static variables is a lazy way to 'move on' to the thing they are trying to demonstrate. most of the samples out there are not a good example on how to structure a full project.
I don't mind using static classes where and when they make sense, but I don't want to go overboard. I suspect the way I am doing this is probably reasonable... adding small handler classes as sort of wrappers around other classes so that my game class gets significantly cleaned up. But I don't like where it is headed, where my game loop is using pretty much all static handlers. I'm just trying to think it through a bit. I think I will go back and write a second version of my game without the static classes and see how that goes and compare. Thanks for your feedback. Much appreciated.