Risks to using a master object?

[OdicHastings]

I've been working on a game in my spare time, and I reached a point where I've decided to throw out all my current code and restart fresh. I had kind of just been doing whatever before as I felt out how exactly I wanted this game to work, and while I'm proud of what I managed to put together, I'm also aware my code base is a hilariously disorganized mess.

So I restarted! And it's gone pretty well. I'm experimenting with Macros and scripts that exist outside of objects. I'm pretty much rocketing towards being right back where I was development wise in no time, with a much cleaner code base to boot!

There's one potential issue I'm worried about though...

I use multiple objects, but most objects only contain their collision masks and creation code. The creation code only contains variables of course.

There is a special object called "Master". This is the only object with any actual programming inside it, and it's the only one that calls on scripts. This thing essentially puppeteers other objects, performing their actions for them. It's even responsible for drawing them and will eventually be responsible for handling their animations (this project follows a lot of old school roguelike philosophies, notably being played on a grid with turn based gameplay, so I don't really need animations yet).

I like how organized this master object has kept me. I'm not bouncing around between objects, and everything is just so well organized. I love how all of this game's... everything really, cascades out of this one objects code base.

But I'm also aware most projects aren't really made like this. I don't have a great deal of experience yet. I haven't encountered any pressing issues, but development is still young.

So what I'm asking is essentially, is there something I don't know? Am I going to be trucking along ok for a while before hitting some unknown wall that's going to make me realize, "WOW, this was a TERRIBLE idea! I really shouldn't have done this!" ?

Thanks in advance for any replies n_n
(Sorry if this is the wrong thread? I wasn't sure if something like this belonged in programming or design?)

 

[TheouAegis]

Most projects aren't structured like that in game maker because most people don't have programming experience. As your project is now, it's completely fine. if you can work with all the code inside one object and a few scripts, then knock yourself out. A lot of people can't work with that much centralized code. Been another reason at least in gamemaker people actually use multiple objects with separate codes is because gamemaker is already allocating a ton of memory to each object so it makes sense to actually use that memory that has been allocated.

 

[Homunculus]

I agree with @TheouAegis , as long as having a single centralized object that handles all your logic helps you making your code more maintainable and clear, I'd say go for it. I use a similar structure frequently for GUI management, where GUI elements like buttons etc... are essentially "dumb" containing only variables and the draw directives, while all the logic resides in a controller object.

I do tend to split the logic of the game into multiple controller objects though based on the scope of the code and the size of the game. Having your main gameplay logic in a single object is fine, but I wouldn't mix that, for example, with the screen / resolution management or menu / GUI properties, which could benefit from their own controller object.

 

[OdicHastings]

Alright, thanks for very much for your replies!

 

[spoonsinbunnies]

game maker used to have an object limit so I used to do exactly this, now my objects usually run 4 or 5 scripts and 10-12 loose lines of code for activating them, but yeah theres no problems with having a master object, in theory your game could use only one copy of one object , it would just mean making new collision scripts, which most people don't feel like doing.

 

[OdicHastings]

game maker used to have an object limit so I used to do exactly this, now my objects usually run 4 or 5 scripts and 10-12 loose lines of code for activating them, but yeah theres no problems with having a master object, in theory your game could use only one copy of one object , it would just mean making new collision scripts, which most people don't feel like doing.

Using literally just one object was actually something I thought about doing, but I wasn't really sure how to go about it.

I need to be able to have variables for multiple instances of certain actors. I thought maybe I could use a 2d array in place of objects? And each index of the first axis would be an actor's id. And the second axis would be variables.

So it would be like [0] = HP [1] = AP [2] = Speed etc, etc,

But I know that I'd be constantly checking my own documentation to remember what each index represented. It's a lot more convenient to look at the code Monster.AP += Monster.Speed, and immediately know what that all means.

Also on some level I have to ask myself, "Is it really worth it to reinvent the wheel, just to prove I can?"

 

[kburkhart84]

I for one LOVE using parent/child objects and same objects with instance creation code where possible. One common usage of it for me has been with GUI buttons. I use one object for all the buttons. They share the same sprite and animations, and only need to call some script when clicked on. In the instance creation code I put the text to render and the script to call in variables...and then I can put the animation, event response, etc... all in the single button. Another common use is with enemies that collide with bullets, or the player. I make them have child objects, which handle the stuff that makes each enemy different, but I put the collisions in the parent object so it is all in one place.

 

[TsukaYuriko]

Haivng a central master object orchestrate how all the others should behave is exactly how my projects are usually structured. Containing everything in a single object (or script) is something that was slightly popular on the old GMC, more so for the "because I can" factor than any practical benefits, though... and I wouldn't recommend going that far, as the disadvantages outweigh the advantages (which are already few and far between).

A central mastermind lets me take full control over the execution order of... well, anything. This means I no longer have to rely on re-arranging the resource tree to get specific things to execute before other things. The same goes for drawing. The same two advantages are the reason why I switched over to structuring projects like this by default - execution order messing me up one too many times, resulting in a "you're doing it wrong, give me the controller".

 

[Cameron]

Personally I like to take advantage of how GameMaker is structured and use objects to contain code for systems. For example, if I want to manage parallax layers, I create an oParallaxLayerManager or if I want to manage the views I create an oCamera, etc., If the object is a system object then that means it likely won't be using any draw code so then I toggle visible = false and the object becomes relatively light way. However, at the end of the day, it's really about personal preference so if you want to keep all your code in one object then more power to you.

In regards to your array []=HP [1]=AP, etc., you can use an enumerator for the naming so:
enum Attributes{
HP,
AP,
Speed,
}
and then when grabbing data out of the array
[Attributes.HP]=100
[Attributes.AP]=10
Etc.,

Or you can also use a macro
#macro HP 0
#macro AP 1
#macro SPEED 2

Then
[HP]=100
[AP]=10
[SPEED]=99999999;

This will keep it from being as confusing as having "magic numbers" in there

 

[OdicHastings]

Haivng a central master object orchestrate how all the others should behave is exactly how my projects are usually structured. Containing everything in a single object (or script) is something that was slightly popular on the old GMC, more so for the "because I can" factor than any practical benefits, though... and I wouldn't recommend going that far, as the disadvantages outweigh the advantages (which are already few and far between).

A central mastermind lets me take full control over the execution order of... well, anything. This means I no longer have to rely on re-arranging the resource tree to get specific things to execute before other things. The same goes for drawing. The same two advantages are the reason why I switched over to structuring projects like this by default - execution order messing me up one too many times, resulting in a "you're doing it wrong, give me the controller".

I get exactly what you mean! A big part of the push was that on my old code base for this project there was just a little too much uncertainty to how everything actually linked together. I love that having one master object means I know-with absolute precision-how everything will play out. In theory.

@CameronScottCreations that's really interesting! Enumerators were a thing I briefly looked into, but my entire thought process when I saw them was just, "What on earth are these even for???"

If I did decide to have literally just one object, which I probably won't and shouldn't, I'd probably keep using what I'm doing now where I have a list that holds the ids of all actors, but instead of holding object ids, they'd be 1d arrays. And then I can just use enumerators and macros like you showed me to make it nice and readable.