Variables as a list?

ID:265897
 
Feb 24 2009, 11:21 pm
What would be the benefits and/or downfalls that you can forsee with making most variables a value in a list rather than having their own var. (For use in an RPG.) Example:

mob
    var
        list
            Variables = new(7)
    player
        New()
            Variables[1] = 7 //HP
            Variables[2] = 7 //Max HP
            Variables[3] = 7 //Strength
            Variables[4] = 7 //Defence
            Variables[5] = 7 //Speed
            Variables[6] = 7 //Mana
            Variables[7] = 7 //Max Mana


And so on. It would save on variable spaces, and potentially bolster editing savefiles. I don't believe I have seen a savefile editor that can edit a list. (I may be mistaken however.) The biggest problem I can see is trying to remember which of the 20 values is which, but, if you simply keep a list written (or printed) up beside you, that would alleviate that problem.

Your thoughts and input are greatly appreciated.
#1 Feb 24 2009, 11:28 pm
You don't have to use numerical references for lists.

mob
    var/list/my_list = list("health"=10,"magic"=10)

    verb/ShowStuff()
        src << "Your health is [my_list["health"]] and your magic is [my_list["magic"]]."


But aside from that DM already stores all variables inside of the 'vars' list, so you can access it like 'src.vars["my_var"]' to get the value of my_var.

As for the savefile editing thing, they can easily edit any value stored in non-encrypted means. The best way to prevent savefile editing is use a hashing method, which uses md5() to create a hash based on the person's variables. If anything is edited the hash will no longer be valid and you'll know editing has been done.
#2 Feb 24 2009, 11:58 pm
In response to Nadrew (#1)
Well, that helped me in a completely different way... I just realized a way to read a list association from within another list association. I have been trying to figure it out for a while, however I swear I tried what actually worked before... Maybe an update made it possible... I dunno...
#3 Feb 25 2009, 6:45 am
As Nadrew stated, you can use text index's instead of numeric. That's a straight advantage of course, I ultimately see no downfalls. In my own game (no more information for now) I use lists also to specify statistics I find it easier to handle as I like to handle lists/arrays, I find them more efficient and less ugly to look at whilst I'm programming. It's a preference thing, some have told me to use simple variables for each thing, and others have said the opposite. I recommend lists though.
#4 Feb 25 2009, 1:28 pm
In response to Haywire (#3)
I am trying to use lists as variables for the first time right now, and I think it is a little bit better when using associations. For example, this is my damage code:

var/dmg = rand(src.stats["Current Strength"]/2*(5/4),src.stats["Current Strength"]/2*(6/4)) - round(monster_list["Enemy 1"]["Defense"] / 2)


monster_list is a list (obviously) of all the enemies in the battle, dead or alive still. What I did was add their stats into the list as an association to, in this case, "Enemy 1". Now, I have (for the time being) up to 4 lists inside the monster_list with the stats of each enemy in the battle.

Personally I find that a little bit easier to read, and potentially less confusing because you always know what is goind on at a glance.

I don't remember what I was trying to say... so I suppose I will stop now...
#5 Feb 25 2009, 4:40 pm
In response to Satans Spawn (#4)
You don't really need to use strings to do that. 
mob/char
   var/list/stats = new(3)
   #define STRENGTH 1
   #define DEFENSE 2
   #define INTELLIGENCE 3
   New()
      src.stats[STRENGTH] = 5
      src.stats[DEFENSE] = 3
      src.stats[INTELLIGENCE] = 3

But then again, you don't really need to store values like this at all unless you have a specific purpose for it.
#6 Feb 25 2009, 8:24 pm
I actually have taken to using datums for a lot of my variables that may change in certain patterns, like stats. At first, when I saw someone do it on the forums, I thought "Why are they wasting their time with that?" However, I later decided it was a pretty good idea! From my Anime source (styled after Naruto):

Stat
    var/value //current value. For example, this may be HP
    var/total_value //total value. This may be the maximum possible HP
    var/mob/player/owner //whatever mob it belongs to

    New(mob/player/P,val,tval)
        if(!P) CRASH("Stat datum with no owner!") //a failsafe, should be removed if you're out of testing
        owner = P
        value = val
        total_value = tval
        ..()

    regain
        New()
            ..()
            spawn() Const_increase(1,owner)

    proc
        Stat_change(n) //adds n to the value and total value, used for stat ups etc.
            total_value += n
            value += n

        Keep_in_bounds() //keeps value from exceeding total value or going below zero
            if(value > total_value) value = total_value
            if(value < 0) value = 0

        Value_change(n) //adds n ONLY to the value! This can be used for stat decreases etc.
            value += n
            Keep_in_bounds()

        Percent_change(p) //increase/lower it by a percentage. This is a decimal! .5 is 50% and so on.
            value = round(value*p,1)

        Const_increase(n) //this will constantly increase the var by n% if it goes below total value
            n /= 100
            for() //for without any args will continue repeating the below indented steps forever
                if(value < total_value)
                    var/a = round(total_value*n,1)
                    value += a
                    Keep_in_bounds()
                sleep(10) //wait 10 ticks
#7 Feb 25 2009, 9:27 pm
In response to Jeff8500 (#6)
A trick I've used for things like this that will always belong to a mob is instead of using an 'owner' variable simply store the datum in the mob's contents list and use src.loc to get a reference to the parent mob.

This of course is only useful for things that will always fallow strict patterns (like stats) and if you're using a generic inventory display it'll probably show up there.

The only reason I say this is because variables that contain references to other datums that aren't internal stuff like the contents list can cause headaches in saving processes making use of Read() and Write(). Best known as 'rollback bugs'.

Making the variable a tmp variable is a quick solution but it's not always ideal if you need the data saved in SOME form.
#8 Feb 25 2009, 9:31 pm
In response to Kaioken (#5)
As far as I know putting the #define and #include preprocessors outside of the top of the file is bad programming practice. The major purpose of #define is to provide easy-to-find and alter constants in your code. The practice I'm used to when doing things of this nature is to use const-type variables.

It's not really a matter of what works and what doesn't though, just a matter of what appeases the programming deities.
#9 Feb 25 2009, 10:08 pm
In response to Nadrew (#7)
Nadrew wrote:
[...] simply store the datum in the mob's contents list and use src.loc to get a reference to the parent mob.

Uh, but you can't do that with plain datums, since contents will not accept them nor do they even have a loc var. >_>

As far as I know putting the #define and #include preprocessors outside of the top of the file is bad programming practice.

Sure, you shouldn't normally do that, what I posted was just an example, of course. I'd put those that are meant to be used globally at the top of a designated file that is named in a way that it's always the first one.
#10 Feb 26 2009, 12:52 pm
In response to Nadrew (#7)
Nadrew wrote:
A trick I've used for things like this that will always belong to a mob is instead of using an 'owner' variable simply store the datum in the mob's contents list and use src.loc to get a reference to the parent mob.

I find it easier to assign things tag variables that are descriptive of them. Then locate() can be used easily and efficiently to reference a datum. That way, the most you have saved is a text string, if that.
#11 Feb 28 2009, 3:54 pm
In response to Nadrew (#7)
I wanted to update this saying I cropped out the owner var, I wasn't using and it was causing runtime errors. I'm sure it would have also caused the rollback bug had I saved more than once.