Functions cannot be optimized in the same way that global variables can, so it is less efficient to use functions.
Also, you cannot assign to a function, so it is only useful for constants, which already are unlimited.
Unless I'm misunderstanding you...
I'm also not getting the intent here:
The singular point of global variables is that they store values accessible to anything else. You can get around that with arrays, but the larger the array, the more time it takes to read it. That's the painful trade-off.
Functions don't store anything, by nature. You cold probably return a value, and exchange it between two functions, perpetually, which would act like storing it, but that would be horribly limited, convolted, and potentially crippling.
Just an example: I'm not certain that this would work as predicted, and the third function isn't really necessary, but this is a model of how to do this. (You'd need to place these functions in a loop, to continually read their values, between the air, and then call them instead of a global variables, inside other scripts; because they are running as part of a global event.
The fourth function is to insert/change a value:
Well, Fortran is pretty old.
Only slightly older than me'self. This, and COBOL, are the languages that I leanrt at University: The main principals and syntax, are my basis for comprehension of al other languages. It's like a foundation layer, and my mind works in a way, that I interpret new styles, and new syntax, in a way that equates it to one of the two.
That example if for Fortran 77; it would be slightly different in Fortran 90, or 95+.
I could conjure up stuff for Fortran IV, through Fortran 77, in a trance state, but as you say, they aren't extremely common now. Most of what I did, was scientific formulation, and the systems that we were using, ran on Fortran and COBOL, because they were built on an extant system, that started therewith.
Outside of this, the other primary language that I used, was Perl; and that was primarily for interfacing with Unix System IV. I still used Perl on occasion, for BSD/Linux/etc., but not much in a long time.
I'm not certain on how different modern Fortran is, but it is still a current language, with reasonably regular updates.
Still, I think you get the point that I was making, on tokens.
How can you circumvent the limit without static variables?
No promises, but the method I mention above, might work. Because the value being exchanged is happening perpetually, it never leaves memory. This would function as a global variable while in operation, but you'd need to write it to an array, onExit.
You'd need a pair of functions, per value that you want to carry, and an array that can hold all of those values, to store them, for later retrieval.
Again, I say, this is neither optimal, nor fundamentally practical, but it may work, if you need to read, and write, to variables in memory.
int valueExchangeArray[1]={0};
global script onExit{
void run(){
valueExchangeArray[0] = read_exchangingValue();
}
}
global script onContinue{
void run(){
insertValue(valueExchangeArray[0]);
}
}
Zoria's idea, however, would not work. If there were a limit on constants, then it would maybe be helpful. But, that would still need global variables to save data to.
Which idea exactly? I'm starting to lose track here, as I posted a few (rather) different possible solutions.
...quest rules...
Regarding making storing global variables a quest rule, fr games where you need many variables that don't need to be stored, it may be more applicable to create another token type, tempvar that can be used for variables not to be saved.
In doing so, you don't need a quest rule at all. You just declare the token like this:
tempvar int ammunition = 10l;
tempvar float speed = 6.4;
tempvar bool alive = true;
That uses a syntax similar to what I described above (re: Fortran), by declaring the token, then the type. Any variable that has a tempvar token, would be kept in memory while the game is running, but not saved. If the programmer wants to save those values, he can store them to an array on exit, and load them on continue, avoiding array reading during a game.
That would offer a good deal of flexibility, in how to declare variables, without losing the benefit of either method. It would also probably be a nightmare to implement, but because you have a special token for it, it would be fully backward-compatible with older code.