Data Structures and Arrays

One of the biggest things about the 'S' plugin which lucid made for 0.x was the fact that it allowed data structures. Variables on their own are fine and dandy, but structures that store arrays of variables, be it string, integer, boolean or other can make various tasks, especially stuff in RPGs, much easier.

There's other uses, such as save data, and storing conversation data for cutscenes, and stuff like that. That, and we need a good replacement for the Array Object.

Yes, it is early days, I am aware of that, but in the long run, data structures, especially being able to visually create a series of 2D arrays that can be used in a meaningful manner could well be extremely beneficial, and in some ways, could eliminate the need for an ini object as well.

Alright, here's how I think it should work. Say we start out with a new project, we're trying to create an RPG. We want to create a series of arrays for the player's party. In the project bar off to the left, below the Layout, Event Sheet and Objects folder, there's a folder called 'Structures', or 'Supers' or 'Tables' or whatever Ash would think would be most suitable. We right-click on that folder, and click "Add New Structure/Table/Whatever". It'll ask if you want a single 2D array, or a Structure. We'll go with the latter here.

Then, Construct sets aside a new tab, and gives a dialog much like the Instance Variables editor, where you can insert new arrays of Strings, Integers, Booleans, etc. and order them however you wish. For this example, our arrays consist of:

• Name: String
• Level: Integer
• EXP: Integer
• HP: Integer
• Attack: Integer
• Defense: Integer
• Speed: Integer
• Luck: Integer
• Weapon: String
• Armor: String
• Ailment: String

And so on and so forth.

Once you're done, the "Structure Editor" gives you an Excel-like table, which one can adjust the margins like any Excel table, and start entering in information if they so desire. In this case, we can enter in the name and stats for our game's player characters. For cutscenes, you could have an integer for which line in the conversation, a string for the actual dialogue, another string to identify the speaker and an integer which tells Construct which frame for that character's mugshot should show.

For save files, you could save every structure into a single file that the game can load when the player chooses to load a save, along with some other information if need be.

It's not the most perfect of explanations, but... Well, I cannot stress how useful something like this could be, and it could help further set Construct 2 apart from the competition, especially if it's done in a user-friendly manner. It could be used for simple arrays, as well as more complex stuff.

I think that those ideas would be good. I have a similar, but slightly different ideal for such things.

My preference slants more toward regular programming language features, but I think that they would fit well with the object model used in Construct.

I would like to see all variables treated equally, to be dynamically typed, and to be object-oriented. Very much like Python. While I think that this would be difficult to work into Construct that way that I would like it to be, I have some ideas that would come somewhat close, I think. Here they are:

• Global (and local, if available) variables can store any usual datatype, and can be tested with system conditions at runtime to see what type that they currently store.

• Datatypes should at least include integer, floating-point, string, array, hashtable, and boolean.

• It would also be quite useful if a variable could be used as a reference to an object. In this way, one can store a reference to a specific instance of, for instance, a sprite. This would be a way around many common picking problems, as well.

• It would be nice to see some way to use something like classes. I think that a logical way to do this could be to offer a generic object type (without the overhead that a sprite or other object would incur,) that can be used mainly for it's ability to have instance variables and be used like a collection type. The big thing here is that new instances can be created at runtime, making things a lot more dynamic. Hopefully these could be referenced easily by index and/or storing a reference to them in a variable.

• The array and hashtable types should be able to store any of the above types as well. This could be complicated, though, when it comes to hashtables of arrays. Perhaps not nested arrays, but arrays being able to store references to objects would be nice.

• Arrays could certainly benefit from a simple sort method, and stack/queue methods

So, I'm out of time, but I think this is pretty inclusive of most of my wishes.

I'm curious what others may think about the subject as well.

anything else then what we have now i will welcome with arms wide open. Not being able to throw variables into folders or parent-variable, no visiual representation of arrays (i actualy use Exel to keep track what is where) or data sorting really stops me from doing any game with complex game system.

Do they have to be either string or integer?

I mean I can imagine times when you would want to mix them.

Btw you can do arrays in pv's in C^1.... you just cant access specific parts.

However, you can create arrays in your events with {a,b,c,d,} n

[quote:177aib69]Do they have to be either string or integer?

Well, I never said it HAD to be either or, but those are the most commonly used data types. As Silent suggested, there should also be floating-point, array, hashtable, and boolean.

Anyway, I saw someone pledge $75 on Fundry for this sort of thing, but I don't think having it as a separate object would be a good idea, because it just makes it harder to have a visual editor.

Well it looks fairly feasible to have a read only type of array, either inside the main script, or reading from another external js.

But changing the array during runtime looks to be a much more complicated thing.

To start off people will be reading this from an single external host, instead of on their own system.

That means you would need a separate array for each person to either be stored in their browser, or on the server that the game is being read from.

Both ways have some pretty big disadvantages.

Well, I've looked at the javascript array capability and I believe an interface plugin would be feasible. Basically expose all javascript array capabilities as well as instantiate the array itself. Perhaps there'd need to be two plugins, one global (for arrays in expressions) and one instance-based (arrays as objects).

Alas, I have no experience in js development, so I'm only going to develop a very rudimentary array object plugin. All this Construct 2 extensibility is still difficult to figure out, however, so I can't promise anything.

Just to note: HTML5 has the capability to save data locally.

Anyways... I want to bring this topic back because I firmly believe that an accessible system for data structures and visually-represented arrays can make Construct 2 truly stand out amongst its competitors, the applications are endless. From RPGs to cutscenes to save files, keeping track of unlocked content, online and offline statistics... There are so many complicated things that could be vastly simplified and made less time-consuming to create, with a visual array editor alone.

I believe a mixture of what Silent and I proposed (with some changes and additions where needed) could certainly take Construct 2 one major step further in attempting to become the world's best game maker software.