Nested data structures

[Mark Ryan]

Hi,

So I'm used to programming in Python and I've played around with a lot of other languages.

When looking at GML it seems to suggest I should only nest data structures ie a map in map when building a JSON.

However, when looking at various vids people suggest that nesting data structures is fine. I would find it odd if GML only supported nesting for JSONs and not everyday use.

After a few days searching I cannot find a definitive explicit answer.

Thanks in advance.

 

[Alice]

Nested data structures are perfectly fine for many use cases in GameMaker. However, there are a few things you need to keep in mind.

First, you need to mark them properly when building the nested structure so that when the parent structure is deleted, all underlying structures are removed, too. Check manual for ds_list_mark_as_list, ds_list_mark_as_map, ds_map_add_list, ds_map_add_map, ds_map_replace_list, ds_map_replace_map for reference (and yes, these functions are pretty annoyingly inconsistent...). Also, marking items as list/maps seems to affect functions for replacing/removing items as well (i.e. if a child structure is replaced/removed from the parent structure, it is destroyed or something?); I don't know about the exact behaviour, though.

Also, once an item is added to the structure, you have literally no method of determining its purpose in the structure; so if you store a non-negative integer in your list or map, GM provides no way of telling whether it's supposed to act as a nested list, as a nested map or just as a regular integer.

It is not a problem when you simply know what the given structure is supposed to be; if you operate on a list of lists, you wouldn't treat one of them as a map, and if you expect map entry "health" to be an integer, you won't try to access it as a list. However, it becomes more complicated if you operate on generic, pretty arbitrary structures; GM provides no easy way for handling these.

Finally, currently GM supports these cool data structure accessors, like list[| index], map[? key] or grid[# x, y]. However, it cannot parse nested accessors just[| like[? these]] or chained accessors just[| like][? these], so that part is a bit of pain.

So yes, if you keep those things in mind and they aren't a problem for you, you should be fine, I think.

 

[Surgeon_]

You can nest any data structure within any other data structure. The thing is that your only reference to a created data structure is an integer, which we usually call a numerical handle. For example, when you write something like L=ds_list create(); the variable l will become some random integer, like 3, or 148 or what ever (though generally the numbers go higher as you create more data structures without freeing them). The point is, when you want to reference that particular list, you need to use the number stored in the variable L, for example ds_list_add(L,"text").

So with all this said, nesting in GM may not be what you're used to. If you were to create another ds_list and store the contents of the aforementioned variable L somewhere in it, we'd call that a nested data structure. Of course, since L is just a number, you could store it within the same list multiple times, or even across multiple data structures. But you still only have one list "pointed" to by L, which is in its own place in memory.

This all works fine until you want to write nested data structures to a string or file, because suddenly you need a way to know which numbers are just numbers, and which are numerical handles of some other data structure. My advice would be to create your own consistent format, or use one of the extensions users around here have built for that purpose.

EDIT: With what Alice said in mind, you don't have to use mark_as_* functions in order to nest data structures. They may make your life easier or harder, but ultimately it depends on where you're going with this. I personally keep track of what goes where and there's always a rule as to which numbers are handles and which aren't, so I never use those functions (and yes, this goes with manually destroying nested structures).

-Surgeon_

 

[Mark Ryan]

Outstanding thanks to your both that is much clearer.

It seems I'm fine as long as keep track off what each value is. Think my documentation will be key and keep tight control of what goes in and out of the structures.