$Global_Variables

[Rikifive]

How they work?


As far as I know it's like @instance_variable, but it's accessible in the whole game.


Because instance variables are stored in the class etc. then I assume they're getting removed (nil-led) upon terminating/disposing. But what about global variables?


They're stored in the 'game' itself and can be accessed anywhere, which is sometimes extremely handy. They're getting removed after shutting down the game, which is even better.


So my question is:


Is is safe to use many of these variables? Will that cause any issues when I'd be using them in various places and the player would play for hours triggering many of them?


For example in one scene I'd be using few $vars, in another scene even more $vars etc. etc. ~ and what if player will open all these scenes and will have tons of $vars stored in the game, because he will be not leaving for some time? Should I nil them after using them? (in terminate methods etc.)


Example:


Generally I want to use these variables as a really temporary ones.
 
A great example would be a minigame:
 
Let's say I'm making a scene with a minigame.
In the start method I'm putting stuff like
 


$score = 0
$lives = 3


 
 
And later I'm using another variables to store player's position for example:
 


def update_player
#some stuff
$player_position_x = @player.x
$player_position_y = @player.y
end


It would come in handy if I'd be making 'homing' objects like missiles.


So generally it would be only temporary and would allow me to freely refer to variables and it would be reset upon re-entering the scene, so save/load game wouldn't be an issue at all.


That's all ~ a simple temporary variable, that would be accessible anywhere.


And as you can see ~ they're used within a scene ~ let's say in a single run ~ but if I'd have multiple minigames, then some variables would be reset and reused which is nice, but some of them may be not needed and will be floating in game's memory when getting to many scenes with stuff like this.


so I could even set them all to nil in the terminate method if that would help.


Y can't u use instance variables?


Because there are situations, where using global ones would be much better. I know I can transfer instance variables to other classes/objects, but sometimes it would require caution and patience + coding all over the place.


Thank you!

 

[GreyStone84]

I wanted to put my two (amateur) cents in, but I'm not sure if it is right, so... instead...


Hi RIKIFIVE! Long time no see!


Hope someone can give you professional advice!

 

[nio kasgami]

the answer


No


global variable enter in the global namespace and it's pollute it...so it's waste memory and slow the process.

 

[Rikifive]

@GreyStone84 That will work too I guess. ( ͡ᵔ ͜ʖ ͡ᵔ )


                         Hello!! ~ Thanks!


@nio kasgami That bad? What I should do then?

 

[Victor Sant]

Y can't u use instance variables?


Because there are situations, where using global ones would be much better.

There is only one situation where using global variables is 'much better' than unsing instance variables: when you have no other options.

 

[nio kasgami]

using a proper variable and use the attr_accessor if you ultimatly need to access datas from another classes


also the use of a global variable is when you want to init a global class instance for make it accessible to the environemment of your system.


and anyway's Why in the ....eh idea would you need to do this? 


def update_player
#some stuff
$player_position_x = @player.x
$player_position_y = @player.y
end


they already have the x position of a actor in the Game_Actor or Sprite_Actor unsure I don't remember and it's a global classes so it's accessible everywheres


(ah no wait I think it's Game_Map)


and Game_Temp is a global instance ...WHO serve for store temporary datas it's a garbage sections for temps data who aren't kept in the whole save.

 

[Rikifive]

@Victor Sant Okay, okay I got it!


@nio kasgami May I ask for more information?


Hmm ~ I just mainly want to easily 'read' them in other classes, so yeah...


"They" you mean who? I'm not talking about the player on map, followers or anything like this that is created by default, but a completely custom sprite on a completely custom scene, where Game_Map and 90+% other default scripts don't have anything to this.


Let me extend the code to give a better example.

class Scene_Definitely_Not_Game_Map_And_Stuff_Like_This < Scene_Base

  def start
    super
    create_player
    @homingobjects = []
    @timer = 60
  end
  
  def create_player
    @player = Sprite.new
    @player.bitmap = Cache.example("Player, duh!")
    @player.x = 300
    @player.y = 240
    @player.z = 200
  end
  
  def update
    super
    update_player
    update_homingobjects
  end
  
  def update_player
    @player.x -= 4 if Input.press?(:LEFT)
    #etc. etc.
  end
  
  def update_homingobjects
    @homingobjects << Sprite_Homing_Object.new(@viewport1) if @timer == 0
    @timer = @timer > 0 ? @timer - 1 : rand(30) + 30

    @homingobjects.each_with_index { |object,i|
      next if object.nil?
      object.update
    }
  end
  
  #let's skip methods like terminate etc....
  
end


class Sprite_Homing_Object < Sprite
  def initialize(viewport)
    super(viewport)
    setup
  end

  def setup
    self.bitmap = Cache.example("Object")
    self.x = rand(Graphics.width + 30) - 15
    self.y = 500
    self.z = 100
  end

  
  def update
    super
    self.x += #maths and conditionals, that will move that object towards player
    self.y += #and the player position will be needed
  end
   
  def width
    self.bitmap.width
  end
  def height
    self.bitmap.height
  end
  
  def dispose
    super
  end
  
end

What would be the efficient way to transfer player's position to class Sprite_Homing_Object?


Putting variables after calling update method? Or something else?


Great, but I'm not a pro scripter, so an example would be more than great if you kindly could give one.


And please forgive my lack of scripting knowledge ~ if you want to laugh because of this then please keep it for yourself. Instead of that you can just tell why it's bad and suggest something else. Thank you.


Also, spoilers have weird behavior after the update and they broke again, I'm just going to not use them, sorry.

 

[Shaz]

I wouldn't use them.  


If I want something that will be saved with the player's progress, I'd determine which of the existing $game_... variables it would fit best in (for example, a journal would go into $game_party) and add it as an instance variable there, along with the methods needed to use it.  If I want something that doesn't need to be saved, I'd put it into $game_temp.

 

[Rikifive]

Then $game_temp seems to be (at least one of) the best solution(s) there ~ could I ask for more information about this?

 

[Shaz]

Just have a look at that script and see how it defines its variables, what it makes public, and what it provides methods for.  Then see how other scripts refer to it.  You can do a global search (control + shift + f) for $game_temp to see where it gets used.  Find something that's already similar to what you want to achieve, and take a close look at how Game_Temp handles that.

 

[Rikifive]

Hmmm ~ I think I got this ~ I'll start toying with this and see what happens.


Sorry if it will sound stupid or lame, but what exactly is the difference between having that variable set in the Game_Temp and having it set 'wild' as a global variable?


If I'll set a wall of variables in Game_Temp, wouldn't that affect performance anyway? These variables need to be stored after all, unless they're getting removed when changing the scene - that would make a lot of difference.


What's the deal there?


Or would it be possible to make instance variables, that could be accessible anywhere like global ones and would exist until the scene is changed?

 

[Shaz]

$game_temp exists until you exit the game.  It does not get cleared/refreshed when you change scenes or change maps.


The difference is that you don't have dozens of global variables hanging around.  Yes, they will still exist at all times like global variables would, but it's good practice to not use globals unless you absolutely have to.  If you put these into $game_temp, you are declaring that they don't need to be saved, they are temporary variables.  It says they don't belong to any of the other classes.


Ask yourself why Enterbrain did not just make all the variables within $game_temp global variables and be done with it, because that's what you're talking about doing.  

 

[Rikifive]

I see... More or less...


That's why I'm asking, because I just don't know. Generally it's pretty the same if you look at it, however it seems to be a different thing when taking a closer look apparently.


Besides, what Enterbrain did or not did is sometimes a mystery for me ~ and I'm talking about the software itself.


Thank you for explaining and your time. I'll see what I can come up with.

 

[Rikifive]

So if I'd like to store temporary variables in a better way, then I should create something like this?


class Game_Temp
attr_accessor :var1
end


and then using~


$game_temp.var1 = 46


draw_text(x,y,w,h, $game_temp.var1)


etc...


And if I'd like to make variables, that I would like to store in save file like controls or something like this, then I could make them in Game_System, for example?


---------------------------------------------------------------


if I'd create Game_Controls class and:


~ set the variables there by attr_accessor


~ set some methods like def set_default


~ add stuff in DataManager to include these variables in a save file


would it be okay?