F
FranciscoJGamer
Guest
I have a simple question, is better to have 1 object that manage the camera, grid, HUD, etc. or have a object that manage the camera, other the grid, other the HUD?
Yes, objects are heavy...but if you are using GMS in the first place, you aren't going to be pulling the fastest performance anyway. IMO, the benefits of cleaner and better organized code far outweigh the performance cost of extra objects. Note that we aren't talking about trees in a forest(where yes, it could be thousands, and that adds up), rather, we are talking about a few helper objects, not likely more than 10 to 20 if even near that. I don't see that heavily affecting performance, especially since these objects are only created once for the most part. And the code is going to have to be there anyway, so the extra variables objects have isn't going to affect it that match for this kind of thing.It's better for you to have one object to handle everything. In Game Maker, objects are too heavy and carry a large amount of unnecessary data with them.
I can't fault this advice. I personally believe having multiple objects is better, and I've explained why...but if you or anyone else personally is going to prefer to do it as one big object...if it gets the thing done and you feel better that way, so be it.The correct answer is to design the game the way you feel the most comfortable with and that makes the most sense for what you're doing. Anything else is well-meant advice, but not a very comprehensive answer.
I agree with this. The principle came about more with OOP, and GMS is not exactly OOP, but a lot of what OOP is, we have here in different forms. I see no reason to not apply many of the same principles here.It's preferable for a single object to have a single responsibility. It's possible, but less maintainable, to have a single monolithic manager object, but I wouldn't recommend it.
For example: let's say you have a single object managing both the HUD and the grid. What if you want to change your grid to a chunk-based model? Then, you'd have to have many grid objects, but you can only have one HUD object. It's a nightmare for code maintainability.
The Single-Responsibility Principle is a good guide for these matters, in my opinion.
This is another point I hadn't mentioned earlier. It's easier to copy over a single object that does a single thing than to mess with copying bits and pieces of a massive single object that does tons of things that you don't need for all projects.I'd encapsulate them in their own GM object, for all the reasons already stated. It's also easier to reuse from project to project (and test projects) that way.
Evenually you'll end up with your own little "marketplace" of assets, which will cut down on developement time by a lot.