I’m working on a game that has a world consisting of a lot of tiles that can be manipulated. I need to save and load all of them individually since the game saves automatically and going through every tile while the game is running, to save the entire world in XML or as one string is too expensive on performance to do. By saving them individually, only the tile that was manipulated needs to be saved. Unfortunately, this means that at every start of the game, all the individual tiles need to be loaded. Would it be possible to increase the speed of the two commands in the runtime itself or are readLocalData and saveLocalData already really efficient? Thanks for any answer 
@Simeon
@Elias The easiest way to find out is to take one of your tiles and save it as many times as you need and then run timings on reading them and saving them.
@dave1707 So, you suggest analyzing how fast readign/saving is? I know how long it takes for the game to read/save the data of all tiles - and it is quite long. Thus I wanted to ask whether the implementation of reading/writing in the Codea runtime itself could be further optimized or if it is already very fast and I have to work around it.
@Elias I would say it’s as fast as it’s going to get. As mentioned in the past for other programs that were reading lots of data at startup, I think the solution was coroutines. That way the program was able to do other things as the initial read of all the data was being done. For instance, you could be displaying instructions or startup images or whatever as the data was being loaded before the actual game was started.
@dave1707 Thanks! I’ve never used coroutines but that sounds like a decent solution. I’ll look into that
@Elias @dave1707 - could you give us a little more detail -
How many different tiles are involved?
How many tiles do you display at once?
What format are the tiles in?
Do you use a terrain map?
It also raises a number of question which the developers may be able to answer - tools etc for assessing the system - how much memory is available in the current system? What OS is present? What screen size/format is present.
A list of routines for these and code management needed to ensure the best cross compatability of your code is available would be useful.
@Bri_G
The map is 24x24 tiles on weaker systems, 48x24 tiles on newer ones. This leads to loading times of 10-15 seconds on an iPad Pro 2018. Since the loaded data needs to be processed, not all of that time is spent on readLocalData.
As far as I know, readLocalData only supports strings. As a result, I built the save feature around that. Basically, every tile has a couple of attributes that decide what it looks like. Those are put in a string, all the attributes are separated by a symbol.
I’ve already posted a video of the game on this forum. I’ll quickly try to find the link and paste it here. Maybe that helps a little more in regards to what I’m trying to achieve.
Edit: Here is the link: https://codea.io/talk/discussion/10720/forestlife-create-your-paradise-working-title
For example, if you plant a flower in the game, it needs to save that the tile now has a specific flower that needs to be displayed. If you water it, the tile needs to save that it is watered. If you e.g. plant a tree, which can grow over time, the tile needs to keep track of when the tree was planted. Every time you e.g. water a flower, the game saves the new state of the tile to ensure that no progress is lost. A lot of stuff depends on this way of saving and loading. I don’t think that switching to e.g. XML is feasible now, so I’m trying to make the best of it now… Theoretically, displaying the start screen before the loading begins would be possible. I don’t think my current system of loading/writing can be enhanced unless it is replaced entirely.
@Elias - suggestion, not sure how many actual different sprites you are using but one option would be to make a grey scale map. Values 0 to 255. Each pixel represents a tile which you have in your sprite library, so you can read location - then grey scale value so you can print the sprite at the position calculated from the x and y coordinates of the pixel you read. As a tree grows you can change the value held in the pixel and change the sprite accordingly. You could also hold all you sprites in a sprite sheet which you can extract and number when loaded.
Also, if needed you could have a separate grey scale image for conditions such as watered etc.
@piinthesky It probably is. However, to really take advantage of it, you’d have to store all the information in one place instead of encoding/decoding the information for each individual tile, right? Otherwise I run into the same issue again. I’m not sure whether it would still be possible to save individual tiles when they are changed then. I’d like to avoid the situation where the state of all tiles has to be encoded as that would either cause the game to lag or potentially even crash it on weaker devices.
@Bri_G In general, this sounds like a nice approach, but there are already around a 100-150 (if not more) different decorations/plants/etc. and I’d like to keep it scaleable. It sounds interesting nonetheless, I’ll look a little more into it, thanks!