What's the smartest way to deal with variables?

Create active objects for each category. Such as 'Interface', 'Global', 'Stats', 'Enemies'. Edit the active animation and paint the name on using text and a white background, this will help with coding. Position the active out of the frame, turn off visible, fine collision and destroy if too far from frame (not sure if these help, but can't hurt).

Then just add variables to them as you need them.

Although this may seem ineffecient at first glance, someone ran a test regarding retrieving values and it turns out getting a variable from an active is faster than getting a global value.

I agree that using separate objects as managers of variables for certain groups is handy. But Global Variables are most helpful when you are working with values across frames. You can make an active "global" but then you have an active object looming in places you might not need it. One suggestion for you if you plan to use lots of Qualifiers... reserve specific variables for specific things the qualifiers will share. For example, always reserve Alt Val A for "ID" or for speed and health values. Now that MMF shows qualifier variable names, you need to make sure all the naming is identical across all qualifier members. Otherwise it will default back to "Alterable Value Blah".

I've moved to a much more object-oriented programming approach in Fusion and it's simplified things so much compared to how Fusion encourages application design.

The most powerful internal objects, from worst to best:

INI
*Array
Active
List

*for programs that directly match the structure of an array, you should use that. So, timer-based or grid-based games, you'll have the best performance using an array.

The most efficient internal objects, from worst to best:

INI
List
Array
Active

I don't recall which post had the benchmarks for this in it but it shouldn't be more than a few pages back.

Object-oriented programming approaches for the list object and active object will make your life so much simpler and more flexible. You can create as many lists as you need, each with their own variables, and assign those objects directly to active objects and the whole process is amazing to work with.

Volnaiskra Globals are only slower by a few dozen milliseconds, it's probably not going to matter unless you're actively seeking absolute optimal efficiency. The 26 limit was lifted in a more recent version, and global variables become a bit of a pain if you want to copy code from one game to another, if your next game doesn't have the identical global variable format, all your references are going to become messed up.

Snail I have to disagree with List. Run a fast loop to add a hundred lines to list and compare it to adding 100 lines to an array. List is painfully slow for data storage (writing has a heap of overhead, not entirely sure why), and IMO list should only be used for visual interfaces where you actually need to display the list.

The only thing lists are good for is doing a search and pushing/popping items off the list, but I'm sure there's a 3rd party extension that can do both searches and list style data storages, or if not someone should program one. Maybe clickteam can create a 'Data List' that's identical to list except it never displays and doesn't have the undesirable overhead whenever adding an item.

I must be wrong about the 26 limit, I thought I read it got fixed, but I just looked into it and it's not the case. Currently I'm just making more actives if I need more variables, and calling them Interface Vals 1, Interface Vals 2, etc.

I thought about List some more and it's actually quite handy because of the preloading data-input you can do in the level editor, it's great for creating quick lookups like list of days (monday, tuesday, wednesday... etc...).

But for anything larger than a few dozen lines and I stay away because of the unexpected freezing when loading data in. Depending on the game this may be acceptable, but for my projects it's not.

You can now have more than 26 variables but only if you refer to them by indexes, adding more than 26 named variables in the editor requires more changes, it will be done later.

Quote

Although this may seem ineffecient at first glance, someone ran a test regarding retrieving values and it turns out getting a variable from an active is faster than getting a global value.

Err, not at all, global values are faster. I'll try to give more precise numbers. EDIT: Alterable values are about 1.5 times slower than global values.

Ok, there was a list posted (by nivram if i remember correctly???) stating that actives were faster, it's a few years out of date though. Would be good if clickteam could post some official numbers on the speed of their features/extensions... i'm very interesting in highlighting the list box/edit box trap I fell into about 6 months back that had me rewriting huge chunks of code, this would help future developers.

Snail
can you upload a small example of your object-oriented way of developing? it doesn't have to be functional.. I like to see how various fusionérs work.

Yves
thanks for the info, good to know.

I collected the data from the original forum post years ago and updated it with new data from more recent posts:

Quote

Speed comparison for accessing data (time taken for 40k operations in hundredths of seconds - lower is better):

Active Object's Alterable String = 15
String Object = 16
Data Store 2 = 19
MagicDeque = 22
Global String = 28
Dynamic Array = 31
GlobalStoreX = 33
Binary Array - 35
Array = 39
AssArray = 44
NamedVar = 50
String Parser 2 = 59
Static Text = 356
List = 506
ListView = 1106
Combo Box = 1197
INI = 3892

Display More

In the latest build (284.0) the INI object got a major update, so it could be much faster. (Or no change on PC runtime?)
If someone has the chance to update this list, that would be a great share.

Quote from Ryan

Snail I have to disagree with List. Run a fast loop to add a hundred lines to list and compare it to adding 100 lines to an array. List is painfully slow for data storage (writing has a heap of overhead, not entirely sure why), and IMO list should only be used for visual interfaces where you actually need to display the list.

The breakdown I gave represented this fact. It's one of the least efficient objects you can use for data in terms of speed but it's one of the most powerful ones you can use for all sorts of designs, both in its capabilities and its simplicity. I couldn't elaborate on some of this yesterday because I had to leave with the half-written post. While you dismissed

Quote from Ryan

The only thing lists are good for is doing a search and pushing/popping items off the list, but I'm sure there's a 3rd party extension that can do both searches and list style data storages, or if not someone should program one. Maybe clickteam can create a 'Data List' that's identical to list except it never displays and doesn't have the undesirable overhead whenever adding an item.

I actually find both of those points to be extremely useful and something that the array object, for example, has no ability to do without a lot of manual work. In addition to those two points, you can create as many list objects as you want and associate them with all sorts of objects at runtime, which is something that the array object cannot do. While the usefulness/efficiency of this can be debated, it makes the actual design of your programs so much easier to work with and come back to later since you don't need legends for hundreds of different arrays.

Gustav's list I think is the one that I remember from a few pages back. Nivram definitely posted in that thread, so you should be able to find it by searching Nivram's posts.

I limited my post to the internal objects because I haven't things like Matt's Ass Array before. I'm sure we have much better objects today that were made by users but I haven't spent much time looking at them, so I'd like to leave that discussion to more knowledgeable people.

Here's the list I was referring to: Please login to see this link.

A really robust way of dealing with lots and lots of variables is something I've wanted for the longest time in the click series.. global and alt. variables work, but they just aren't good enough my view, specially when the amount of variables are getting up into the many hundereds, which it will for a more complex game.

Preferably, a built in "Variables" object should be present in all frames. Using this object, different sets of variables can be set up, named, ordered and sorted. A variable can be a number, string or float and can be local to the current frame or global to the whole application. Variables can be added and deleted during runtime and can be traversed in a loop using an index. If a variable in a certain list is removed, the other variables can be automatically "moved up" to fill the empty slot or be left as an empty slot. Lists of variables can be saved and loaded to disk using common formats.

To my knowledge, no extension can do all this, some can do some of these things, but no single extension can deliver the "whole package" and provide a really robust variables feature set, without the need for any other systems. Would be really cool if someone would make such an extension, and even better if it were to be built into Fusion. Pretty plz!

What you just described is exactly what the list object can do. I agree that for performance, it's nowhere near the best, but for functionality, it's hard to beat and it also runs on all platforms. I would definitely like to see a more efficient version of it that has no display overhead but I'm not going to recreate Clickteam's extension without the source code.

Snail - On the point of List object, I have to agree with your point. Secondly, LB made an 'Internal List Object' a few years ago. It removes the need for that slight performance overhead. It runs 10x faster than the standard CT list object which has more overhead due to it mainly being a windows control.

I highly recommend you check it out. Whilst not cross-platform compatible (only in Windows), I'm sure he wouldn't mind sharing the sources if you was wanting to elaborate on it?

Quote from SirEatAlot

To my knowledge, no extension can do all this, some can do some of these things, but no single extension can deliver the "whole package" and provide a really robust variables feature set, without the need for any other systems. Would be really cool if someone would make such an extension, and even better if it were to be built into Fusion. Pretty plz!

The Named Variable object should do everything you want. It's the best "array" I ever worked with in Fusion and should be integrated as feature for all runtimes.

+1 for a variable system that's intuitive, however I would suspect this is already a planned update in Fusion 3.