Saving values as metadata and expanding arrays
Monkey Forums/Monkey Beginners/Saving values as metadata and expanding arrays
| ||
| I was thinking about creating a large game, but I wanted to keep track of "zones" by arrays which save the state of the entities moving around my maps. And each zone would have its own data. But I am wondering, can monkey handle infinite expanding arrays or is there a limit, and does Monkey just work directly with XML and ini or can i make up my own type of save files. Anyone know of a good resource or framework for this? Should I get Ignition X or just experiment with saving and loading arrays to files and see what happens? |
| ||
| and does Monkey just work directly with XML and ini or can i make up my own type of save files. There is a json module which works very well and is easy to use. There is also XML here in the forums. But I am wondering, can monkey handle infinite expanding arrays or is there a limit Resizing arrays is the wrong way to go because expanding an array requires copying all current elements. The time for that increases with the number of elements (read: infinite time for infinite large array). Your best bet is probably a similar approach to the binding of isaac were everything is splitted up into small rooms. You could generate and load/store these rooms using a predefined pattern. Also the amount of data that you actually need could be a lot smaller than you think. |
| ||
| this is usually solved by splitting your world into chunks. set each area defined by size and create a separate file for each chunk. if it is too far away from where the player is then save it out to a file and if they start getting closer to it then load that file. then you don't have to worry about an array spanning out to any kind of theoretical limit and it will mean far less memory usage. Unless each zone is small enough that this was already your plan, but either way, try not to think of the whole game world as a single map, it can look that way to the player but you'll thank yourself later if you keep the size of the data you deal with down |
| ||
| And remember that, as Pharmhaus said, the data might be smaller than you think. E.g. if you have 100 entities which need saving per zone, and each needs 100 bytes of state, that's still only 1 MB per 100 zones... Of course, it all depends what you are doing - are zones procedurally generated or pre-generated? The latter might use quite a lot of memory - though again, 200 x 200 of 1 byte terrain tiles is still only 40K, if that's the way you're going. The other issue is whether your game is asset-heavy: do different zones have different environmental and monster graphics? Or can everything in your game fit on a single spritesheet? |
| ||
| @Pharmhaus There is a json module which works very well and is easy to use. There is also XML here in the forums. Thanks I will definately check it out Resizing arrays is the wrong way to go because expanding an array requires copying all current elements. The time for that increases with the number of elements (read: infinite time for infinite large array). Your best bet is probably a similar approach to the binding of isaac were everything is splitted up into small rooms. You could generate and load/store these rooms using a predefined pattern. Also the amount of data that you actually need could be a lot smaller than you think. yes I had thought about approaching it this way, I think it might be best and work with something I have already created and defined with shfting elements. Hmmm @Capn Lee this is usually solved by splitting your world into chunks. set each area defined by size and create a separate file for each chunk. if it is too far away from where the player is then save it out to a file and if they start getting closer to it then load that file. then you don't have to worry about an array spanning out to any kind of theoretical limit and it will mean far less memory usage. Unless each zone is small enough that this was already your plan, but either way, try not to think of the whole game world as a single map, it can look that way to the player but you'll thank yourself later if you keep the size of the data you deal with down I remember reading a blog about this process, and it was similar to I think how Terraria handled loading its zones. Or maybe it wasnt. I will probably look into this as you can make the size of zones quite variable and save alot of performance. @Gerry Quinn And remember that, as Pharmhaus said, the data might be smaller than you think. E.g. if you have 100 entities which need saving per zone, and each needs 100 bytes of state, that's still only 1 MB per 100 zones... Of course, it all depends what you are doing - are zones procedurally generated or pre-generated? The latter might use quite a lot of memory - though again, 200 x 200 of 1 byte terrain tiles is still only 40K, if that's the way you're going. The other issue is whether your game is asset-heavy: do different zones have different environmental and monster graphics? Or can everything in your game fit on a single spritesheet? to first answer the spritesheet question, I was thinking (though not sure) of having a few generic variations to some simple art, and manipulating R,G,B values of the artwork according to my need for the entity/class holding it to make the illusion of there being more gear than available or artwork than is. Not sure if Monkey X supports such sprite manipulation, but either way not many,. The zones would share alot of art, what I wanted to is manage large amounts of unique zone space, and in each space store entity specific data and also transitional data to neighboring zones. |
| ||
| Monkey has ReadPixels and WritePixels functions for direct sprite manipulation, though you don't want to be doing a huge amount of this. You can also just draw a white or greyscale object in different colours, as is done for fonts, to vary the colour of a soldier's shield and helmet, for example. |
| ||
| Wait a moment, Monkey X/mojo doesnt use a camera. So the area or space I render to is an infinite screen surface? I'm trying to make heads or tails of the mojo module's graphicsDevice but it is a little confusing to me, it seems that the surface itself can go on forever? Or is it the object data holding all renderable material is stored in its supposed x and y coordinates which can go off the screen but be held in memory. So suppose I wanted a scrollable camera to go over a zone, I'm actually rendering all graphics at an offset from my single viewport screenwidth and screenheight and just moving all rendered objects in unison? |
   |