Understanding Data Structures

[chidsuey]

I'm still trying to wrap my head around data structures, and would appreciate further elaboration. As far as I can tell, they seem to basically be arrays that have more functions available for quicker and easier access to points of data in them. But they also come with a memory warning. I don't understand the purpose of creating one (often the example is for an inventory) and then destroying it. What good is it if it just has to be destroyed so you don't run into memory issues?

I was thinking about using a ds_grid to keep track of my position in rooms on a map (think LoZ:LTTP) and also to help with spawning enemies only when I enter the room they're in, but if I have to keep destroying the grid, it doesn't seem like it's worth.

I know there's something I'm clearly missing, and as always, I appreciate the help. Thanks!

 

[whale_cancer]

I'm still trying to wrap my head around data structures, and would appreciate further elaboration. As far as I can tell, they seem to basically be arrays that have more functions available for quicker and easier access to points of data in them. But they also come with a memory warning. I don't understand the purpose of creating one (often the example is for an inventory) and then destroying it. What good is it if it just has to be destroyed so you don't run into memory issues?

I was thinking about using a ds_grid to keep track of my position in rooms on a map (think LoZ:LTTP) and also to help with spawning enemies only when I enter the room they're in, but if I have to keep destroying the grid, it doesn't seem like it's worth.

I know there's something I'm clearly missing, and as always, I appreciate the help. Thanks!

You are somewhat correct (at least in my estimation), but you are not thinking of some more creative ways of using data structures.

Re:

I was thinking about using a ds_grid to keep track of my position in rooms on a map (think LoZ:LTTP) and also to help with spawning enemies only when I enter the room they're in, but if I have to keep destroying the grid, it doesn't seem like it's worth.

I am not sure _exactly_ what you mean here, but I think I am doing something similar. However, I actually store the map data (tiles, location of objects, etc.,) in grids which I write to a file (ds_map/grid_write and _read are your friends; they are an excellent way to store data).

Also, those memory warnings might sound a bit more dire than they actually are. They are more so that you don't create 100s of data structures in loops and forget about them. For instance, I use lists, grids, and maps in various combinations to store enemy, item, and character information; I then load those into objects which use the loaded data to determine behavior and statistics. I've never had a ds_ related memory issue.

Put another way, data structures let you manage information much more easily once your project starts to get bigger. If I had to create new pickups or enemy objects for each one I wanted in my game... yikes! Not only that, but they would be harder to edit later on.

What kind of project are you working on (if any?)? I could suggest some uses then. I think data structures are some of the most important things to learn once a GML dev gets past the basics.

 

[SyntaxError]

You have the idea. Data Structures (DS) are powerful but easily misused.
Destroying the DS isn't required. If you need to keep it, do so. The warning is there to ensure you don't keep creating the same DS if for instance, you change rooms and then change back. If every time you do this without destroying the DS, and may potentially create the same DS in some objects create event, the old reference id is over written and the DS hasn't been destroyed (and is no longer accessible) so you'll get a memory leak.

Does that help?

 

[chidsuey]

Yes thank you both for the help!

I'm working on a classic zelda style game, and I'm trying to figure out the best way to store all of the rooms (not like GM rooms, but each little area a dungeon separated by doors), so that I can keep track of the players position on the minimap/inventory map, and when to spawn enemies and items.

 

[whale_cancer]

Yes thank you both for the help!

I'm working on a classic zelda style game, and I'm trying to figure out the best way to store all of the rooms (not like GM rooms, but each little area a dungeon separated by doors), so that I can keep track of the players position on the minimap/inventory map, and when to spawn enemies and items.

Hey! I am doing something very similar (at least as far as how the data needs to be structured goes). I wrote an in-engine map editor that relies on ds_grids to store data. I have 4 ds_grids for each map; these grids handle my tiles and collision. One grid stores what background my tile is from, one stores what the left origin of the tile is, one stores what the top origin of the tile is, and the final one stores if the position is solid or not. For objects, I use (what I call) a dynamic .ini file. Grids are stored in a text file.

This seems to me to be the best way to approach storing level data in this kind of game. Of course, there is a lot of stuff to consider around this, and if you are trying to just get a simpler project off the ground to sharpen your programming skills, this system might be overkill.

 

[chidsuey]

Any tips are appreciated! I'll consider this and see what I can do. Thanks!

 

[Yal]

Don't forget that there's not just lists and grids, there's also queues, priority queues, maps and stacks... all of them work very differently from arrays. Queues and stacks are important for searching and procedural generation, priority queues are handy for sorting data, maps can be used to store data with huge "holes" in it efficiently as an alternative to arrays... I generally don't care too much about the memory issues, I generally create global data structures once at game start that never needs to be replaced. You CAN run out of memory by creating arrays as well, it's just harder since GM removes them automatically when you remove references to them (e.g. destroying an object that had a local array).