ID:272841
 
In my current project, I've run into two very similar scenarios both involving large amounts data, and I'm wondering which is the most efficient way of handling them.

The first question is in the leveling system. I'm trying to make my game as close to the source game as possible, and instead of having several EXP equations that determine how much EXP is required to reach the next level, there is a single stat (from 1-32) that corresponds to a list containing a different EXP level for every level (1-99). Thus, this leads to 32 different lists, times 99 values in each list... it's alot of data. (Plus, a similar system is used for another stat system of the game)
I've already gotten all the information, but right now I have the 32 lists stored as global variables. Is this bad? Would it be more efficient to create the correct list every time someone levels up, or is it more efficient to simply create them once and then access them when needed? Or does it even make a difference.

I have another similar issue. This time, I'm using datums to store combinations. (There is one datum per result, not one datum per combination) Since I need to initialize each datum to get the information inside of them, would it be more efficient to initialize them all once, and save them in a list (or several), or would it be more efficient to simply loop through typesof() and initialize them one at a time? (Each one only stores three variables, two of which may or may not be lists)
If it's relevant, this will be used much less than something like leveling.
For the first question, I'd have to say that creating them and having them stored would be better than recreating them each time someone levels. Given the situation I would define the global list, containing the 32 different lists rather than 32 separate variables.
I can't recall the current list limit (65535, higher in 4.0?), but I can't imagine you'd come anywhere near it by doing it this way. I'm not really a fan of massive data lists like this though, are you sure it wouldn't be more convenient (or efficient) to use an equation for it?

For your second question, again I'd assume that saving them would be the most efficient way to go.

Wouldn't mind hearing some other opinions on either issue
however.
In response to Ephemerality
The data I'm using doesn't really fit to any particular equation, it fluctuates up and down somewhat erratically. So, in this case it's easier to simply use the original data (now that I've gotten it all copied in) rather than spend ages on a graphing calculator trying to find an equation that models the data properly, and then deal with the decimal answers and such. Yes, having a screen of numbers on the code is annoying, but I'll probably just put it at the bottom of the file when I'm done with it.

As for the second example, currently I'm just instantiating the 20-30 combinations that I might need (instead of instantiating them all every time) using a for(var/ctype in typesof(...)) loop.
It wouldn't be possible (or a good idea) to use static here, would it? I've only seen static a few times and I don't have a good idea of how it works, but could I put a var/static/ctype in a for loop?

In response to Chessmaster_19
Not sure what you mean on the second bit there, I think you're mixing up languages. DM doesn't have any "static" declarations as far as I remember. C uses statics, but they just refer to the scope/storage of the var...
In theory it shouldn't be too much of a problem to have a list containing 32 associative lists, each with 99 elements, in memory at all times. You might try instead to make a single list of 32 elements, where each element is the result of list2params() on that particular list (giving you 32 strings. When you need an EXP list:
proc/GetExpReqs(i) // 1 <= i <= 32
return params2list(master_exp_list)


Then for a mob needing to determine its new EXP requirement:

mob
var/exp_req
var/exp_stat
var/level

proc/SetExpReq()
var/list/exp_reqs = GetExpReqs(exp_stat)
exp_req = exp_reqs[level]

Then it shouldn't be too hard to call your SetExpReq()-like function when level or exp_stat change. Likely, this has the benefit of better memory usage, and negligible speed impact (unless you call SetExpReq() very often).
In response to Ephemerality
Ephemerality wrote:
DM doesn't have any "static" declarations as far as I remember. C uses statics, but they just refer to the scope/storage of the var...

Partially correct. The keyword "global" amounts to the same thing as static does in other languages.

The following is an example of a function that keeps track of text for you, allows you to update it, and, every time it is updated, returns the previous value. Notice that, in the C version, myTextUpdater(char*) will return a garbage value the first time it is called.
// C version
char* myTextUpdater(char *newText)
{
static char *text;
char *oldText = text;

text = newText;

return oldText;
}

// Byond (DM) version
proc/myTextUpdater(newText)
var
global/text
oldText = text

text = newText

return oldText

The only difference in effect between the two is that Byond guarentees that myTextUpdater() will return null the first use instead of a garbage value.
In response to Loduwijk
True enough, although if you use "static" in reference to a global variable in C, it means that the variable is only available within that file... so it depends on the context.

In terms of CM19's question, he was probably referring to the /global/ keyword as you posted... in which case, I'd assume it wouldn't be of much help. I'd say initializing them and saving them from the start would be the way to go.
In response to Ephemerality
Actually DM does have static. I've seen it in use before, though I haven't seen it documented anywhere. I only use it once in my code, right now, but it does work.
(See the word static turns blue)

The BYOND static is pretty strange, which is probably why it's not widely known
In response to Chessmaster_19
Hmm, that's pretty interesting. Be nice to get some specific details on it's implementation in DM...
In response to Chessmaster_19
Yes, it has static, it's just another name for the global var modifier.