When should I use global, instance, local, and constants in event systems?

[PK8]

Okay, I've a question. It's been bugging me for quite a bit. I plan to take advantage of global variables, instance variables, local variables and constants when making Event based systems. I know a teensy bit about them but I'm trying to learn more about them using RMXP's help file.

I would like to know how to use them correctly and when should I use them in event systems.

[PoisonedV]

global variables are the sign of a novice programmer.

[Floyd]

Punkster, global variables, as they are memory hogs, should very rarely be used. ESPECIALLY in RMXP's system - as it's got everything you need already in some. Should you need to store data temporarily that can be accessed from anywhere in the game, I reccomend adding it to the $game_temp object. :)

[DerVVulfman]

Well, he's gotten past using $global variables in his event systems. Talked to him today. But for an event system, he doesn't plan to add any new instance values through added in scripts. He's going pure 'event' system.

Least I think he is.

[Charlie Fleed]

Isn't $game_temp a global too?
I would be interested in a detailed explanation of the motivations for you to suggest the use of $game_temp . I'm particularly interested in performance issues, more than in design ones.

[Zeriab]

Global variables are not resource hogs. I wonder where you found that myth.
I just tested putting 100 000 global variables in my anti lag test bench. No noticable difference. The only difference was an increase in memory usage. With 100 000 global variables it is significant, with 10 000 it is not.
In practice its the design issues rather than performance issues which causes problems.
One could naturally imagine global variables being created in some dynamical way and then leak out in such a way that there keeps getting more global variables. But that is really an unlikely situation.

*hugs*
- Zeriab

[MARBLES]

Global variables will allocate the same amount of memory as any other variable type.

In OOP, a global variable is a highly unmanaged piece of data that can be hard to keep track of especially as your program grows. It would be better to define member variables for each class that would use that data. Globals aren't BAD THINGS but you should reserve them for data that would best be global (a counter for debugging purposes, defined constants).

Tell me what an event system is. Is it just making customized content using events? Not really sure what you're trying to say in that post.

[Zeriab]

I would call an event system for a well-defined system which is expressed with events.
For example. Say you have implemented a dash system with events. Then you have an event system.

[MARBLES]

oh well aren't all the variables global in rpg maker events? (except the map specific variables that in a sense are still global to the events w/in the map)

[DerVVulfman]

Global variables are not resource hogs. I wonder where you found that myth.

Obtained from...

General Scripting Conventions
By Trickster
Proofreading by Yeyinde and Kurisu

Global Variables should generally not be used. Global Variables are not an Object Oriented construct and violates information hiding. You do not want all of the scripts knowing about a variable, you only want your variables shown to methods/classes/scripts that need to view and perform operations on it. The only global variables that should be added are new $data_ and $game_ objects. System global variables created by RMXP (ex. $DEBUG and $scene are allowed). Global variables also consume more memory since they are not removed until the program terminates. The use of bad global variables is frowned upon, because you are cheating yourself, your script, and the users of your script.

oh well aren't all the variables global in rpg maker events? (except the map specific variables that in a sense are still global to the events w/in the map)

When you consider the class variables such as $game_temp.map_bgm, you are not really using global variables, but instance variables created for that class. You may refer to or change the value of map_bgm from another class (be it a window or scene class) by the use of the $game_temp prefix. It uses the prefix so the system knows what class the value was created and stored. On the other hand, the value can be used throughout the Game_Temp class by referring to the @map_bgm instance value alone.

So I can call $game_temp.map_bgm from any class, or just @map_bgm in the Game_Temp class as it is an instance variable for that class.

Likewise, RMXP variables called from events are class variables too. You refer to the $game_variables[i] value, but when you do, you access the @data instance value (an array) that was created on the class's initialization.