Globals persistent across game runs
by Minty Hunter · in Torque Game Builder · 02/11/2007 (3:43 pm) · 5 replies
As a long-time Flash and Director programmer, I'm struggling with some things as a TGB newbie!
One is that global variables seem to persist each time you do 'Run Game'.
For instance, if I had this:
Then it will increment each time I run my game, stop it and run again. I had figured that each time I ran the game, I'd be starting with a clean slate (in the same way as when you publish a swf).
Is there a 'clearglobals' or similar command? I had a look and couldn't see it.
Or do you really have to reload your project each time you want to clear your globals to an undefined state?
Thanks for any help that anyone can offer!
One is that global variables seem to persist each time you do 'Run Game'.
For instance, if I had this:
numRuns=numRuns+1; echo(numRuns);
Then it will increment each time I run my game, stop it and run again. I had figured that each time I ran the game, I'd be starting with a clean slate (in the same way as when you publish a swf).
Is there a 'clearglobals' or similar command? I had a look and couldn't see it.
Or do you really have to reload your project each time you want to clear your globals to an undefined state?
Thanks for any help that anyone can offer!
#2
To be clear, I was choosing Project>Run Game from TGB's menu. The game appeared, I looked at console output, then pressed the square stop button overlaid in the top left of my game. As I could see in the console that my scripts are being read in and recompiled (and any changes are included), I would have thought that all variables would be initialised too. From what I can see, that's not the case. But as I gather from your comments, regardless of the script recomp, the game instance is persistent, and so are global vars.
There's no 'clear globals' is there? Could I hack it by loading a new level somehow? (Reloading the entire game is a lengthy process!).
I agree with you:
>> you should never just increment a value without first initializing it, in any programming language, regardless of whether it "lets you" or not ...
but there were two reasons I did.
One, I was aiming for a barebones example.
Two, the real script creates a series of 'array' variables using this format: $check[%otherVar], where %otherVar is a string. Because these are being created dynamically on the fly, I didn't see an easy way to initialise them.
It was to solve a problem posted here:
www.garagegames.com/mg/forums/result.thread.php?qt=57702
If you look at the comments of my final script post down the bottom, you'll get an idea of why I was making creating vars dynamically.
>> so if your startGame simply has "numRuns++" (which is a shortcut for your "numRuns = numRuns + 1", btw)
Heh. Yeah, I'm still coming up to speed with TGB, and having been surprised that there are no string < > comparison opps, I was being conservative in choose other shortcut operators...
Thanks for the tips: I'll keep TGBing away and learning its own quirks and intricacies :)
02/11/2007 (4:41 pm)
@Dave -- Thanks for the quick and comprehensive reply. To be clear, I was choosing Project>Run Game from TGB's menu. The game appeared, I looked at console output, then pressed the square stop button overlaid in the top left of my game. As I could see in the console that my scripts are being read in and recompiled (and any changes are included), I would have thought that all variables would be initialised too. From what I can see, that's not the case. But as I gather from your comments, regardless of the script recomp, the game instance is persistent, and so are global vars.
There's no 'clear globals' is there? Could I hack it by loading a new level somehow? (Reloading the entire game is a lengthy process!).
I agree with you:
>> you should never just increment a value without first initializing it, in any programming language, regardless of whether it "lets you" or not ...
but there were two reasons I did.
One, I was aiming for a barebones example.
Two, the real script creates a series of 'array' variables using this format: $check[%otherVar], where %otherVar is a string. Because these are being created dynamically on the fly, I didn't see an easy way to initialise them.
It was to solve a problem posted here:
www.garagegames.com/mg/forums/result.thread.php?qt=57702
If you look at the comments of my final script post down the bottom, you'll get an idea of why I was making creating vars dynamically.
>> so if your startGame simply has "numRuns++" (which is a shortcut for your "numRuns = numRuns + 1", btw)
Heh. Yeah, I'm still coming up to speed with TGB, and having been surprised that there are no string < > comparison opps, I was being conservative in choose other shortcut operators...
Thanks for the tips: I'll keep TGBing away and learning its own quirks and intricacies :)
#3
But hey ... one of the things I usually do, is I code in Torsion, and I test in the level builder -- once I've laid out my level, most of my work is "play testing" and making sure my code works ... as code isn't written in TGB ... I usually just close TGB all together and re-launch it ...
I simplified this process by adding TGB and Torsion to my Quick Launch Bar in Windows ... so I can just click the TGB Icon, and since it auto-loads the last project .. poof ...
Anyhow, thats a process I'm familiar and comfortable with due to my many years of development without tools like TGB that required such things to be done ...
But yeah, to simplify your play-testing ... you can simply reset all your globals in the endGame ... in your game.cs ...
02/11/2007 (4:58 pm)
@Minty, there is an 'endGame' method, at which point, you could reset all your variables to 'square one' ... as far as 'clear globals', I don't believe there is anything to do that "out of the box" ... But hey ... one of the things I usually do, is I code in Torsion, and I test in the level builder -- once I've laid out my level, most of my work is "play testing" and making sure my code works ... as code isn't written in TGB ... I usually just close TGB all together and re-launch it ...
I simplified this process by adding TGB and Torsion to my Quick Launch Bar in Windows ... so I can just click the TGB Icon, and since it auto-loads the last project .. poof ...
Anyhow, thats a process I'm familiar and comfortable with due to my many years of development without tools like TGB that required such things to be done ...
But yeah, to simplify your play-testing ... you can simply reset all your globals in the endGame ... in your game.cs ...
#4
I think I've been spoiled by Director and Flash (especially the former, where you could make variable changes and call functions manually _during_ runtime), and have to come to grips with the real game toys where you reload the entire project to intialise it!
Nice idea, but as my variables are being dynamically created, the possible permutations are 26*26*26 (possibly more if case and punctuation are used). Well, nested loops would do it fine, but the whole idea was to avoid a performance hit! Perhaps I just need to do a speed check and see whether it only takes TGB a millisecond or two to initialise 17,000+ variables...
02/11/2007 (7:44 pm)
@David, looks like I'm going to have to pony up to sort out my expired alpha of Torsion ;-)I think I've been spoiled by Director and Flash (especially the former, where you could make variable changes and call functions manually _during_ runtime), and have to come to grips with the real game toys where you reload the entire project to intialise it!
Quote:But yeah, to simplify your play-testing ... you can simply reset all your globals in the endGame ...
Nice idea, but as my variables are being dynamically created, the possible permutations are 26*26*26 (possibly more if case and punctuation are used). Well, nested loops would do it fine, but the whole idea was to avoid a performance hit! Perhaps I just need to do a speed check and see whether it only takes TGB a millisecond or two to initialise 17,000+ variables...
#5
Like I said before (I think I said this, haha) ... the Level Builder "is" an instance of your game ... this may change in future releases, but as of 1.1.3 it is currently the "game" and "tool" all in one ...
Basically, and your best to restart the engine, rather frequently ... especially if you create lots of scene objects and stuff ... as the engine has no concept of "garbage collection", so it will not implicitly delete objects your no longer using -- any objects dynamically created in script, are still resident unless they've been explicitly told to delete themselves -- adding this code to work-around restarting the engine seems fairly pointless ... it's added work to be done prior to the game existing, rather then just stopping the game and letting it do its own internal 'object cleanup' through C++ (much faster)
02/11/2007 (8:08 pm)
@Minty, not really sure ... but I'm gonna go on a wild guess that if you have 17,000+ globals ... you might want to play-test your game by restarting the engine each time anyhow ... Like I said before (I think I said this, haha) ... the Level Builder "is" an instance of your game ... this may change in future releases, but as of 1.1.3 it is currently the "game" and "tool" all in one ...
Basically, and your best to restart the engine, rather frequently ... especially if you create lots of scene objects and stuff ... as the engine has no concept of "garbage collection", so it will not implicitly delete objects your no longer using -- any objects dynamically created in script, are still resident unless they've been explicitly told to delete themselves -- adding this code to work-around restarting the engine seems fairly pointless ... it's added work to be done prior to the game existing, rather then just stopping the game and letting it do its own internal 'object cleanup' through C++ (much faster)
Associate David Higgins
DPHCoders.com
Globals do not persist across executions, but they do persist while the engine is still running --
If you completely close the engine, and restart it, the value starts from what it was declared as -- when you "Play Level" from the Level Builder, you are technically still running inside the same instance of TGB that was running when you last tested it ... so if your startGame simply has "numRuns++" (which is a shortcut for your "numRuns = numRuns + 1", btw) ... you will increment numRuns each time you test-play your level from Level Builder, unless you restart the engine ...
This logic, however, is fairly flawed -- you should never just increment a value without first initializing it, in any programming language, regardless of whether it "lets you" or not ...
In your startgame, numRuns should be initialized to 0 ... in your custom "load level" or "start a new game" method (which should technically be different then the game.cs's "startGame" .. you would then increment the value --
the built-in "startGame" is fairly misleading, as it's not really supposed to "start your game", it's more or less designed to launch your mainscreen ui ... which would then have options for starting your game ... think of game.cs's "startGame" as "initEngine" or "initialize" or something like that ...
Anyway, your problem is not that TGB is persisting across game runs, it's that your not actually ever "ending your game" as the Level Builder "is" technically an instance of the game ... and your simply just re-running the "startGame" every time you test-play ... something I feel was never clearly identified in any of the current tutorials --