Saving a game with procedural generation

imjustmike

Hey guys - I'm currently working on a project that has some actors that are spawned into position. A whole lot in fact. I want to have a save game function (in the background, periodically save, and on certain in-game triggers) but am worried that the sheer number of actors is going to make this lag inducing, both during the game and for when the game is loaded.

I'm creating a 2d platform survival game which is generated semi-randomly (spawners generate 1 of 20+ different 'scenery types' when player is near) as the player explores. The game could potentially have 1000+ actors, depending on how long the player survives.

I'm thinking of potentially having a scenery_item attribute, that goes up by one each time an actor is spawned and is assigned to that actor. This could be a row in a table. I could then use add table row to save the actor type, position and a couple other attributes as it is spawned, then update it if it's interacted with / destroyed.

No more than 15 actors will be spawned at once, with 3-4 attributes per, so 45-60 table saves. I'm thinking I should use timers to make sure they're not all triggered at once. Big concern is loading them again... The way they're spawned is if the hero is near a spawner actor (collision with a massive collision box rather than math), that way they don't spawn if the hero isn't nearby. I'm wondering if the same logic can be used to load the game from save? Rather than load ALL the table data at once, load the ones closest to the hero's saved position (the actor's X will be one of the saved data), then in the background, load the rest? Or am I needlessly worrying about the likely load?

Before I start developing the logic I wanted to ask if anyone has done something similar - do you have any pointers on the best way to do this? Potentially in a more lazy (less processor intensive) way?

Hopscotch

@imjustmike

As you are approaching something ambitious, here some pointers:

• Never use "Add row" unless your table is very small, and stays very small. "Add row" does the following: It creates a copy of the current table, then adds the new row, then deletes the original. You can see that this causes huge memory spikes and potential lag in your game if the table is big.

• The same happens if a text cell value gets filled with a value larger than what it contained before. GS again needs to reallocate more memory, thus creating an expanded copy of the table, thereafter deleting the original.

Learnings:

• Avoid text columns if you can achieve the same with integers. Integers occupy a fixed length in the tables and do not cause a reallocation in memory when changed.

• Define a table from the onset with the maximum rows that it may have, don't use "add row". Rather use indicators and pointers to mark how far the table is filled, which rows are deleted, etc.

To be clear, tables are fast; the above really only comes into play if you have huge tables whose values need to change often.

pHghost

@Hopscotch said:
"Add row" does the following: It creates a copy of the current table, then adds the new row, then deletes the original.

Whaaa... I had no idea this is what's going on. I usually juggle quite a lot of table data. Fortunately usually turn-based stuff, so not critical in this sense.

pHghost

On iOS viewer, the memory stats GS shows you, are tables under Other? Never really sure what it is.

Hopscotch

@pHghost

Don't trust the viewer. Have a look at this thread where I give some instructions on how to test.

http://forums.gamesalad.com/discussion/80212/howto-using-xcode-instruments-to-test-your-ios-app

GS has often claimed that the values are not accurate, but I think it is pretty close.

pHghost

@Hopscotch said:
Don't trust the viewer. Have a look at this thread where I give some instructions on how to test.

Oh yeah, I don't use the Viewer for actual proper testing, but give them values a curious look now and then when trying out builds.

Thanks for the link, handy resource; bookmarked!

imjustmike

@Hopscotch said:
Learnings:

• Avoid text columns if you can achieve the same with integers. Integers occupy a fixed length in the tables and do not cause a reallocation in memory when changed.

• Define a table from the onset with the maximum rows that it may have, don't use "add row". Rather use indicators and pointers to mark how far the table is filled, which rows are deleted, etc.

To be clear, tables are fast; the above really only comes into play if you have huge tables whose values need to change often.

This is insanely helpful. Thank you!