[Suggestion] Arrays/'Lists' of 'Objects'

Discussion and feedback on Construct 2

Post » Sun Oct 06, 2013 10:27 am

This might seem a tad complicated, and I'm not sure if there's actually a way to do this already, but let's see:

Considering families are akin to classes in traditional programming, when working with classes, not only can you create singular objects, you can also create arrays of them, or lists. Each object in an array/list has its own named methods/functions and variables, and the array/list can then be modified and sorted, and interact with other objects/lists of the same class.


However, to my knowledge, C2 lacks similar functionality. To get a better idea of what I'm asking for, let's look at an example, from, say, an RPG with any number of possible party members, such as Pokemon:

- Say you have a 'List' object that has to be associated with a Family. The Family, and by extension, the List, describes Party Members, with all their relevant variables, such as their name, stats like HP, attack power, etc, stuff like equipment, EXP, level, and so on.
- During play, each object's variables can be accessed by name, rather than the designer having to remember which index number is associated with a variable like they would an array. As well, objects can be deleted from a List, the List can be sorted by a specific variable with limited hassle, and an object can be transferred to another List, like, say, you want to put a party member in 'storage' and swap them for someone else.
- In-game, each object in a list can be associated with a visible object in-game via events that graphically represents the party members.


This would also do wonders for stuff like inventories, for example. I imagine there's some things I'm missing from this that would make List objects even better, but I think I've gotten my overall point across. Arrays and Dictionaries are neat, but they do have their limitations.Candescence2013-10-06 10:28:09
B
94
S
37
G
11
Posts: 404
Reputation: 11,275

Post » Sun Oct 06, 2013 11:40 am

Couldn't you do stuff like that with instance variables and picking stuff based on those?

For example:
Each of 'person' objects would have variables like name, stats, inventory. You can reference these objects by using these variables, you can sort them, no index numbers or anything needed.

Lets say you'd want a list of your strongest characters printed on text object, you could do something like this:

for each person(order by person.strength descending)
.. text.append person.name & newline
B
24
S
9
G
7
Posts: 756
Reputation: 7,312

Post » Sun Oct 06, 2013 2:45 pm

That's really only workable if you're only working with a single layout, anything more and things start becoming a hassle. This is especially true if you want any kind of 'storage' system for party members you're not using at any time, and you don't want to have those party members active all the time.

The main advantages of a "List object" are convenience, being able to keep track of multiple "Lists" (even multiple lists associated with the same family) at a time, organize and add to them, and keep them active across layouts without having to muck about too much with events.

Say you want to add a new item to an inventory list object - just tell the list to check if the item isn't already there, and if it is and you've got a 'quantity' value, just increase the value by one, and if there isn't any in the list, just add the the object to the list. Simple.
B
94
S
37
G
11
Posts: 404
Reputation: 11,275

Post » Sun Oct 06, 2013 5:36 pm

This is going to be a very messy post but hopefully you'll get something out of this :P
(Edit: This is all kind of pointless if you already understand how stuff works, my main focus on writing all of this post was that it's pretty straightforward to do without "lists" and using what we already have.)
All this is totally possible with Arrays and Instance Variables (and webstorage for saving). When using Arrays, the information in the Array is global, so can be accessed in all layouts. I guess the 1 'eh' thing is that yeah, with Arrays you have to remember the index number for things rather than using words, but I don't think it's too big of a deal, it never bothered me really. Also, I'd have multiple Arrays for different things, such as Character attributes (however, In my own project, I didn't make an array for this, I stored it in webstorage and loaded when I needed, can't remember why I did that way), Inventory items, Skills. I set my Arrays out like so:

Inventory Items
X (Character ID, every character in-game has a unique ID assigned to them)
0= Bob
1= Fred
2= Bum
3= Jesse

Y (Inventory Slot. Where the item will be placed in the list(nothing needs to be entered into these parts of the array))
0
1
2
3

Z (Item attributes)
0=[Name of item]
1=[Description of item]
2=[Level required]
3=[Str]
4=[Dex]
5=[Int]
6=[Luk]
(so for example)
0=Super mega sword
1=This sword is the most mega awesome sword ever.
2=50
3=20
4=10
5=-6
6=0

And there you would have your item in an inventory that can be accessed and placed correctly in a list by using the right events :P making "sorting" and whatnot isn't too hard as long as you know what you are doing and know a bit about arrays (I barely know much about arrays and probably use a stupid method)

I remember storing the player attributes like so:

If a player's stat changed (for example, level up), I'd do a webstorage event to write an expression like this:
["Char" & Player.CID & "Level"] to Player.Level

"Char" is to tell the webstorage that this is to do with Character stuff.
"Player.CID" is an instance variable that is storing the ID for the character (so that webstorage knows which characters level it is changing)
"Level" just lets it know what attribute we are dealing with
"Player.Level" is the players level which gets set into the location of the expression.
So the expression ends up looking sorta like:
Char3Level= 69

This is very easy to load back in a later time. Upon creating and assigning the ID onto a player, you can then "Set instance variable" to the players "Level" to ["Char" & Player.CID & "Level"]. And Volia, you have a saved attribute unique to a specific character! I did this for all attribute stats like HP, MaxHP, MP, Level, Str, Dex, ect.

Sooooooo yeah this was probably the most confusing post ever, and I don't mean to explain stuff you may already know, but yeah I'm mentally exhausted but wanted to try and help nonetheless, since I love RPG's and know how annoying they are to deal with!Jase002013-10-06 17:37:44
B
51
S
20
G
10
Posts: 571
Reputation: 9,819

Post » Sun Oct 06, 2013 6:19 pm

[QUOTE=Candescence] That's really only workable if you're only working with a single layout, anything more and things start becoming a hassle. This is especially true if you want any kind of 'storage' system for party members you're not using at any time, and you don't want to have those party members active all the time.

The main advantages of a "List object" are convenience, being able to keep track of multiple "Lists" (even multiple lists associated with the same family) at a time, organize and add to them, and keep them active across layouts without having to muck about too much with events.

Say you want to add a new item to an inventory list object - just tell the list to check if the item isn't already there, and if it is and you've got a 'quantity' value, just increase the value by one, and if there isn't any in the list, just add the the object to the list. Simple.[/QUOTE]

I still don't see anything that could not be done rather simply without arrays/lists. You can use arrays as traditional linked lists if you wish to have that kind of functionality. 'Deactivating' party members is quite simple to implement too.
B
24
S
9
G
7
Posts: 756
Reputation: 7,312

Post » Mon Dec 16, 2013 2:01 pm

Revisting this thread...

While it is technically possible to achieve such results, I really think that such useful functions shouldn't need so much work to set up - when programming languages include proper dynamic arrays/linked lists as standard functions, surely it would be worthwhile to implement them. Sometimes it's just better to get better tools for a specific purpose rather than try use existing tools that'll make solving the problem more difficult.
B
94
S
37
G
11
Posts: 404
Reputation: 11,275

Post » Sun Mar 23, 2014 9:22 pm

B
68
S
22
G
14
Posts: 1,485
Reputation: 16,561


Return to Construct 2 General

Who is online

Users browsing this forum: Yahoo [Bot] and 9 guests