I have only been working with Monogame framework for about half a year, and I’ve never used XNA before that. In the couple of my first silly games I did not use Services at all. This worked for simple games, but I ended up having to pass a lot of parameters to all my methods in the game (as I had to pass the SpriteBatch, ContentManager, InputManager etc. etc. everywhere).
Now that I’ve discovered (gj Columbus) that I can add the SpriteBatch, ContentManager, InputManager and such to Services, and access them from anywhere in the game, I don’t have to pass so many parameters around. However, at the same time, I’m now relying on these Services very heavily, and I have a need to access them from pretty much every class in the game. Are there any negative implications to that? Or is that simply the way that the XNA framework was meant to be used?
As a game, you should not be using the services components, not only is it fishy, it can remain behind when the game is removed and if not handled correctly, eat a lot of processing power, the last thing you want is controversy over your methods…
My verdict, stay away from that… no other games use it, and I have a lot of games installed, even GTAV… a game which has infinitely more things going on than you could ever put together in the next five years… and yet it does not utilise any services… so avoid doing so…
The only reason you would step into using services is for multiple applications interoperability… such as networked data processing or such… Steam uses it for its client which makes sense…
And the amount of paperwork you will need to write
[If I am wrong about anything here, do let me know]
Other than assuming the completely incorrect type of “Service”? It was a question about the Services property in the Game object. The one that has IGraphicsDeviceManagerService, and any other object that the dev wishes to put in there for access elsewhere.
I was wondering what you were you on about, and then realised you had taken it as a Windows Service. Then I had to chuckle.
As for the original question, there is no right or wrong answer. You use whatever suits your code the best. There’s no “it is meant to be used this way”. It is an option there for you to use if you wish.
i thought he was talking about windows services too ive heard of this being done before as well. Yes actual windows services references but it was beyond me how that works.
Now that I’ve discovered (gj Columbus) that I can add the SpriteBatch,
ContentManager, InputManager and such to Services, and access them from
anywhere in the game,
First time ive heard of this and here i just put static references to them all at the top of game1 in a seperate class and then set those references to them in load i been doing that since xna.
I thought he meant another type of service but no mention of any such specifically so I had to assume WinServices…
Really starting to love this community, we need more humour!!!
But regarding inbuilt services,yeah I doubt there are any restrictions… Same as a user using a cheat controller to repetitively hit a button endlessly…
@MrValentine - Yeah, sorry if my original post wasn’t clear, I was referring to Services as the inherent feature of the XNA framework, not WinServices - I’m an absolute beginner so not in a million years would I think to use WinServices.
@KonajuGames - Thanks for the reply. I know there is no such thing as “right or wrong” in game development, but because I’m new to MonoGame, I wanted to make sure whether the game architecture I’m using does not have too many negative implications.
@willmotil - I actually only learned about that accidentally, while scanning through a book (“Beginning XNA 3.0 Game Programming”). It’s a very convenient feature, but again, I was unsure about it’s implications.
Microsoft’s XNA framework for game development has this pattern built into its core Game class. Each instance has a GameServices object that can be used to register and locate services of any type.
@KakCAT - Cyeah, for some reason I am a bit scared of globals? Probably because I’m still such a pleb when it comes to programming, and it’s hard for me to say exactly when the use of globals is justifiable, and how much is too much.
There is a lot of people out there writing about how anything thats global or static in any way “violates the core concepts of OOP”, and should not be used. It seems to me like a lot of these are just clickbait articles by wannabe programming gurus. If global and static code was so evil, and violated the concepts of object oriented programming, surely it would not become a part of OOP in the first place?
Why? Sorry I’m not really up to date with what’s going on in the world of programming right now so I’m curious as to why C++ people would be salty about static data.
C++ must be backwards compatible with C. So while they can add OOP, they can’t remove statics and globals from the language.
Globals aren’t such a bad thing, when used with care. They do have some extra conditions when used on Android sure to the process/activity architecture, but generally they’re fairly safe. Those articles claiming about how they’re evil are usually written from the view of proper programming practices used in business programming.
Well it’s a double edge sword but honestly i mostly switched back to passing.
There is nothing wrong with statics for instances that are needed everywhere as far as performance goes in c# if used properly though you have to be mindful of things like device resets.
The problem is coupling,
Coupling is such a pain it makes your project ugly as hell it makes you feel like your code is a lumbering beast that cant move, basically its spegetti-fy-ing classes, globals statics this service idea all contribute to that end.
Passing still is sort of coupling.
I mean if a class needs something to work, then it needs it, and it has exactly 3 options.
Rewrite it in place time consuming, bloats the code and decreases clarity / and is sort of against the rules of OOP but now its decoupled.
Pass it what it needs… now if it really needs it, It needs it. So its still sort of coupled just not directly, in cases were it doesn’t need those instances passed in, it might be decoupled.
Use a static use a service or some other gimik now its coupled but tightly. Though its only coupled to one place. If you don’t need something in say class B, now you Do need it, or that class A wont work because it calls to it from within. The thing is you don’t want that static class coupled to a lot of other things or your really in trouble.
So lately i have actually decided 3 is the worst choice coupling is a pain in the ass. The first is overkill to do all the time. So 2 is the best middle ground if you can keep parameters down, if not ill mix 2 and 1.
Yeah, I can see your point completely. I guess I’ll need to figure this out for myself.
I’m only learning programming as a hobby, so I’m not really concerned with “good practice” or anything like that, but if I run into any issues with using Services, I’ll probably switch back to passing parameters around.
