Design Mechanics: List/variables

ID:1420948
 
Nov 13 2013, 2:09 pm
(See the best response by Ss4toby.)
 
//I was wondering, is it more efficient to create a bunch 
//of variables or store is it better to store a lot of strings 
//inside a list? I.e.

mob/player/var
 list/traits = new

mob/player/proc
 addTraits()
  traits.Add("Hero","Exp whore","Businessman","Sharp Eye","\
... and etc until I hit over 20 strings")

//OR

mob/player/var
 Hero = FALSE
 Businessman = FALSE
 Exp_Whore = FALSE
 Sharp_Eye = FALSE
//v
//v
//v
//until i hit over 20 variables


Problem description: Later on I will call the list to check if the player has that string in their.

Or later on I could check if the variable is TRUE for that player

I am trying to implement traits in my game.
Nov 13 2013, 2:28 pm
I'm not entirely sure I understand what it is your asking, so this will be an educated shot in the dark.

mob/proc/addTraits()
  for(var/v in traits)
    if(!(v in vars))
      continue
    vars[v]=TRUE


Honestly, I'm not entirely sure why you are using both variables and a list? It seems to me like one or the other should be enough. If the code I've posted is not at all what you were wanting, or you are in need of more. Please comment back.
Nov 13 2013, 2:34 pm
In response to Ss4toby
Oh no all i'm asking is, which method is more efficient. Using countless variables or storing a bunch of strings inside a list.

So I have a list of traits right. All of them have their own effects and I was wondering is it better to make a variable for each one or store them as strings inside a list?

It's most likely that I will be checking if a mob has that trait.
Nov 13 2013, 2:46 pm
Best response
I think using a list would be your best bet. At least, it would make creating buffs entirely easier. Both methods however, essentially are the same when you think about it. But furthermore, using variables could prove to be a worse idea if you add a lot of different options because that would cause memory to sky-rocket if there were a lot of mob/player's in the game.

You've got me stumped on which would be more idea, but if it were me I'd use a list.
Nov 13 2013, 2:49 pm
In response to Ss4toby
Yea I understand what you're saying and I too believe a list is the better option. Thank you.
Nov 13 2013, 3:23 pm
If all these vars are just TRUE/FALSE, it would be better to store them in one var as bitflags.
Nov 13 2013, 3:27 pm
In response to MisterPerson
What do you mean? Like a global variable or booleans? I will be checking if the player possess these traits almost always. During battle, movement, even if they're idle. I'm quite unclear about bitflags.
Nov 13 2013, 4:34 pm
In response to Luchasi
Here's a pretty good article on bit flags.
Nov 13 2013, 5:00 pm
Maybe I'm simply not understanding this, but honestly I don't see how bit flags and what I'm trying to do go hand to hand. I could sure use some more explanations if possible.

-Regards
Nov 13 2013, 5:46 pm
Think of it this way

#define HERO 1 << 0
#define BUSINESSMAN 1 << 1
#define EXP_WHORE 1 << 2
#define SHARP_EYE 1 << 3


This is the same as saying

HERO = 0001
BUSINESSMAN = 0010
EXP_WHORE = 0100
SHARP_EYE = 1000


(For the record, the vars are 1, 2, 4, 8 respectively. But don't worry about that.)

Let's define a var under whatever called var/flags = 0 (same as 0000). Flags is going to store which flags are turned on and which are off. Think of each bit as a variable but they're all slammed together.

Here's how you turn flags on. Anything | 1 equals 1 and anything | 0 equals anything. If we do flags |= HERO (0000 |= 0001), we're activating the HERO bit by flipping the last number to 1. We wind up with 0001. Each bit is independent so you can later do flags |= SHARP_EYE (or 0001 |= 1000) to wind up with 1001.

Now that's great, but how do you check if a flag is on? Well that's easy. The other bit operator you care about is &. Anything & 1 equals anything and anything & 0 equals 0. So we simply ask if(flags & HERO) (ie if(1001 & 0001)). Since they both share a bit (0001), you get if(0001). The check returns TRUE. If you asked if(flags & BUSINESSMAN) (if(1001 & 0010)), neither share any bits, so you wind up with if(0000), which returns FALSE.

If you want to turn a bit off, that's pretty simple too. You have to take flags & ~HERO. ~HERO is the same as 1110 (every bit on but HERO). So if flags was 1001 (HERO | SHARP_EYE or 0001 | 1000 which is 1001), saying flags &= ~HERO is 1001 &= 1110. This winds up with 1000 (SHARP_EYE).
Nov 13 2013, 7:48 pm
In response to MisterPerson
After reading this and the article posted by LordAndrew, I think I've come to a conclusion. I just need to define those traits and turn them on for players that have achieved them.

I'm still a bit unclear but here is a try.

#define Survivor 1

var/switch_ = 0

mob/player/proc
 activateSurvivor()
  switch_ |= Survivor

//check if its on
if(switch_ & Survivor) return TRUE
else return FALSE

//switch off

switch_ &= ~Survivor


So this is a lot better than doing.

for(var/i in traits)
 if(i == "Survivor")
  //stuff happens
Nov 14 2013, 7:44 pm
Looks about right to me, yeah.

If you only do an 'if("Survivor" in traits)' check every once in awhile the difference is not really a big deal. If this is something that's being done every tick, every movement, or over a large number of objects (ie everything in view) the speed increase will be quite major but still potentially irrelevant. Don't sweat it so much that you refactor any old code unless the procs doing such checks are causing delays.