• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Quick stupid question about global variables

Psycho_666

Member
Hey.
I am not sure and it's pretty much yes or no question, so I'm just going to ask.
If I set a global variable in an object, does it transition from room to room and do I need to have the object persistent in every room, or once set, I don't need this object anymore?

Thank you.
 

Simon Gust

Member
The room would come first anyway as you need to drop the object in it so perhaps room settings would be a better idea.
The room creation Code runs after the instance creation Code.

I don't think it's generally a good idea to put global variables in the room creation Code because of this.
I do however suggest that global variables that persist throughout the game should be in an object that is marked persistent to not accidentally reset These global variables.
 

Mike

nobody important
GMC Elder
I normally do an initialisation room and have a control object that's persistent and run in the first room. It then creates all globals etc then moves to the next room.

Also lets you change window/surface sizes etc pre-game.
 

TsukaYuriko

☄️
Forum Staff
Moderator
When you say that you "want to be able to see the data before I open the room"... not a lot would be happening before you enter said room, anyway, right? Unless, of course, you're declaring global variables in any room aside from the first one. If that's the case, I urge you to reconsider that.

Having declarations of global variables spread out across multiple rooms can easily lead to adding various pitfalls to your game which may limit you or trip you up later on. For example, if you store any data structure indices or other dynamic resources in a global variable, it implies that you should not return to the room it happened in during the run time of the game (unless you're using a Game Start event, but that would only work in the first room anyway). Doing so would cause a memory leak, unless you include code that checks whether the globals have already been declared... but that's just additional hassle that you shouldn't force yourself to have to deal with.

I personally prefer "init room"-type setups as mentioned by @Mike - way less error-prone and no hidden pitfalls. Once you leave it, there will be no sane reason to ever return to it, anyway, so you don't have to give it any second thoughts.
 

Mike

nobody important
GMC Elder
Also.... having an object means you can setup fading... or use a timer to delay starting for a couple of frames as the resolution changes or detect a key press for debugging etc...

Having an object instead of just creation code, makes life much simpler, and has a lot more possibilities down the line.
 

Psycho_666

Member
The room would come first anyway as you need to drop the object in it so perhaps room settings would be a better idea.
That doesn't really matter.
The room creation Code runs after the instance creation Code.
Again, that doesn't really matter. That sort of granularity if execution I try to avoid.
When you say that you "want to be able to see the data before I open the room"...
Here's the thing.
Its a map data. What is where.
When I say I want to be able to see the data before I enter the room I mean I want to see a presentation of the map before I start the game. So I need the data set.
I am thinking of eventually external files savings for that data, but maybe not, I am not really sure about it. First I want to be able to play the game before doing those kinds of optimisations. And if I do external files those global variables will be just read from the file, so I won't even need the object anymore... That is why I say the execution order in this case just doesn't matter.
 
Top