• Hey! Guest! The 40th (!!!) GMC Jam will take place between February 25th, 12:00 UTC to March 1st 12:00 UTC. Why not join in this very special anniversary jam! Click here to find out more!

GML One object for manage all or one object to manage one thing?

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?
 

kburkhart84

Firehammer Games
In general, I prefer to have one object handle one thing. The only exception would be if the object is managing other objects, which is still technically one thing.

The reason is because you should be able to add and remove objects as needed, change them as well, and not have this affect too much. Just as an example, if you store something like how many lives your player has on the same object that is the player, then you can't destroy the player. You are also dependent on that player object, so you can't make a different player object if the game-play changes styles for some reason(like Contra games had two different game modes on the NES and SNES for example).
 

Mert

Member
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.
 

rytan451

Member
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.
 
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.
 

kburkhart84

Firehammer Games
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.
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.

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 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.

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.
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.

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.
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.
 

Xer0botXer0

Senpai
Usually I have an object for time, object for stats, object for player, object for monster, object for slime.
When it comes to monsters, you could have multiple objects with similar code, or one object that in the create event will choose a path, by path I mean choosing what kind of monster it will be and then run the relevant code.

There's also GUI objects, maybe a popup GUI that says "Accept Changes or Cancel Changes" two buttons, you can create the object instance when saying save, but what if you've got many things in different menus that you want this popup for, for that you can either have one accept/change object or multiple, if you have one you just feed the popup object a parameter so it knows which case of a switch statement to run, or you can have multiple objects and just create the relevant object.

I don't try not to stress about organizing objects, but I've to say it's really part of the process and one can imagine..somewhat important.

It's like looking for butter in the kitchen, some people leave it in the fridge, others in one of the many cupboards, luckily it's your project so you choose what works for you, and as with everyone when it comes to organizing, what works for us is organizing so we can remember which improves workflow.

Now where the heck did they leave that butter!
 
Top