Any Way to Make Local Variables?

[Ace of Spades]

So I started making a new ABS, which will be released to the public once I'm done.  I just started getting into scripting, so I'm still learning a lot of the basics, so please bare with me.  Anyways, here's my question.

I'm in the process of making some enemy events, and I want everything to be very user-friendly.  Now if I'm making health and different stats for enemies, it's going to take up a lot of variables, and be very clumsy and unorganized unless I find a way to use some scripting.  I know each event has local switches, so I was wondering if there's any possible way to make local variables, independent from each event.

For example, I know $game_map.events[@event_id].x will give you that particular event's x coordinate.  My question is would there be an easy way to define something like $game_map.events[@event_id].health to bring up that enemy event's health?  Something along those lines, I'm wondering if anyone could explain how.  Thanks for your time.

 

[OS]

In the script editor, create a new empty script between main and your default scripts. Call it Game_Event 2 or something.

Now, in this script, write the following code:

class Game_Event < Game_Character
   alias game_event_init initialize
   def initialize(map_id, event)
      game_event_init(map_id, event)
      @health = 100
   end
   
   attr_accessor :health
end

This way, you will be able to use the following code to change the Event's health.

$game_map.events[event_id].health += number

Use += to add to the current health, and -= to subtract from the current health.

Now, to add your own new variables, add more names below @health, all preceded by the '@' symbol. Then go down to the attr_accessor line and add either a comma and then the word you added (without the '@') or write an other line starting with attr_accessor :my_var.

Like this:

attr_accessor :health, :my_var_1, :my_var_2

or

attr_accessor :health
attr_accessor :my_var_1

Etc.

I hope this was helpful. Good luck.

~Owen Sael

 

[Glitchfinder]

(Interesting bit of coding)

I hope this was helpful. Good luck.

~Owen Sael

I personally would have used arrays. It just seems simpler, and I could store a lot more that way. I'm not going to go into the details much, suffice to say that you should check out the array function in the help menu, and see if it would work. (That's how I made a script that runs mutiple timers at once, with the ability to add and remove them, as well as check by a number specified when the timer is made)

 

[khmp]

(Interesting bit of coding)

I hope this was helpful. Good luck.

~Owen Sael

I personally would have used arrays. It just seems simpler, and I could store a lot more that way. I'm not going to go into the details much, suffice to say that you should check out the array function in the help menu, and see if it would work. (That's how I made a script that runs mutiple timers at once, with the ability to add and remove them, as well as check by a number specified when the timer is made)

Ya got me, I'll bite . The question is about instance variables. And I think an Array would lead to obtuse code in this case. I assume you mean add an Array that would contain all the custom stats he wants an event to have? If this were to happen you would have something like this:

$game_map.events[event_id].stats[xxx]

Where xxx is a number linked to a statistic and that really isn't intuitive. 0 gets HP, 1 gets SP etc. Besides we use Arrays when we need things grouped together in a specific order. It's not really necessary in this case. If any kind of object should be used I would recommend a Hash. Only because you could reference statistics through a string rather than an arbitrary number.

class Game_Event < Game_Character
  attr_accessor :stats
  alias game_event_init initialize
  def initialize(map_id, event)
    game_event_init(map_id, event)
    @stats = {}
    @stats['hp'] = 100
    @stats['sp'] = 100
    # etc...
    @stats.default = 0
  end
end

But I think what OS suggested is a good path for where he is now.

 

[Ace of Spades]

Thanks guys for the help and the input, especially OS being the first to reply and give me a quick solution.  I honestly think this feature should be built right into RMXP, but at least now I know how to make them.  This will definitely help simplify my project.

 

[Glitchfinder]

(Interesting bit of coding)

I hope this was helpful. Good luck.

~Owen Sael

I personally would have used arrays. It just seems simpler, and I could store a lot more that way. I'm not going to go into the details much, suffice to say that you should check out the array function in the help menu, and see if it would work. (That's how I made a script that runs mutiple timers at once, with the ability to add and remove them, as well as check by a number specified when the timer is made)

Ya got me, I'll bite . The question is about instance variables. And I think an Array would lead to obtuse code in this case. I assume you mean add an Array that would contain all the custom stats he wants an event to have? If this were to happen you would have something like this:

$game_map.events[event_id].stats[xxx]

Where xxx is a number linked to a statistic and that really isn't intuitive. 0 gets HP, 1 gets SP etc. Besides we use Arrays when we need things grouped together in a specific order. It's not really necessary in this case. If any kind of object should be used I would recommend a Hash. Only because you could reference statistics through a string rather than an arbitrary number.

class Game_Event < Game_Character
  attr_accessor :stats
  alias game_event_init initialize
  def initialize(map_id, event)
    game_event_init(map_id, event)
    @stats = {}
    @stats['hp'] = 100
    @stats['sp'] = 100
    # etc...
    @stats.default = 0
  end
end

But I think what OS suggested is a good path for where he is now.

I had been thinking more along the lines of an array for each stat, using the same number to look up the value for each stat in each array. Have a look at my timer script to see what I mean. (I also realize that it is also somewhat inefficient)