Persistent rooms that aren't persistent?

R

rawket

Guest
So I read that having persistent rooms are super awful for memory, so now I'm trying to tackle the issue of how to make rooms seem persistent without them being set as persistent. Turns out I don't know what I'm doing. I wanna make an object that every time a room starts, it has a switch to check the room, and then, per room, has a sort of laundry list of things to check and change every time I load a room. This is proving to be very difficult and so I want to know what a good way to go about simulating room persistence may be. Is it even worth trying to do that? Is the memory load really that bad? It's rare that a room for me reaches 1000 pixels in any direction, and, frankly, so far when I check my memory usage, I don't see any change from there being only one room loaded and having been through all rooms. So I guess I'm also curious if it's even worth trying to set up something like this.
 

CloseRange

Member
When you do room persistent every single thing in that room gets saved even if nothing changed. It remembers every wall object, every tree, every plant and remembers where they are in the room. But if they never move and no variables or anything change about them, then there is no point in remaindering everything about them.

If you don't need to do it with too many objects a quick and dirty way (don't worry it won't hurt performance) is to make the object persistant, but turn off all it's functionality when not in the appropriate room. Make it so none of its code can be run unless it's in the proper room. At the top of each code block you can just do :
Code:
if(room != myRoom) exit;
and then it won't run any of the following code unless it's in that room. This will save every one of the object's properties for use when you return back.
 

obscene

Member
To keep it simple for now, only one question matters: Will you need persistent room across multiple gameplay sessions, ie, can the player save the game and come back later. If not, persistent rooms are find and you don't need to worry about it. If so, that's where you need to come up with your own system. But, you don't need to simulate room persistence. You really just need to decide exactly what it is you need to track instead of everything.
 
R

rawket

Guest
To keep it simple for now, only one question matters: Will you need persistent room across multiple gameplay sessions, ie, can the player save the game and come back later. If not, persistent rooms are find and you don't need to worry about it. If so, that's where you need to come up with your own system. But, you don't need to simulate room persistence. You really just need to decide exactly what it is you need to track instead of everything.
Say I'm gonna have to keep track of layers, sprites, weather a boss has been fought, or a chest has been opened. What if an object gets picked up that was there when the room started. I have no idea how to keep track of all those things in a manageable way.
 
R

rawket

Guest
When you do room persistent every single thing in that room gets saved even if nothing changed. It remembers every wall object, every tree, every plant and remembers where they are in the room. But if they never move and no variables or anything change about them, then there is no point in remaindering everything about them.

If you don't need to do it with too many objects a quick and dirty way (don't worry it won't hurt performance) is to make the object persistant, but turn off all it's functionality when not in the appropriate room. Make it so none of its code can be run unless it's in the proper room. At the top of each code block you can just do :
Code:
if(room != myRoom) exit;
and then it won't run any of the following code unless it's in that room. This will save every one of the object's properties for use when you return back.
A majority of my rooms don't have TOO many individual things to keep track of but by the end of the game, assuming you didn't close you'd have tones of(hopefully invisible) objects on screen except I, not sure how to make them invisible but then visible again when needed. Also would this work if you saved the game, closed, and re-opened?
 

obscene

Member
As far as storing instances between rooms, this is how I did it once. It was convoluted and there are probably better ways.

1)
Initialize a grid. It could have cells like this....
room | object_index | x | y | etc

2)
Also, initialize a list. The list is simply a list of rooms visited.

3)
Parent all your objects that need to be stored to something like "par_gamestate_object"


Then, at runtime, you'll do the following...

1)
When you enter a room, check the list. If you've never been here before, add it to the list.

2)
When you exit a room, loop through all the instances of par_gamestate_object. Save their data to your grid... room,object_index,x,y,etc.

3)
When you enter a room again, check the list. If you've been here before, destroy all instances of par_gamestate_object. For each row that matches the current room, create an instance of the object with your values you saved. Then remove those lines from the grid. (When you leave again, they'll be rewritten if they are still there)

Then when you save or load, you can easily read and write the grid using ds_list_read(), ds_grid_read() and ds_list_write(), ds_grid_write(). There are other caveats you may run across, but that's the simplest version of it.

In my current project I'm only dealing with treasure chests so far, and so I've done something similar. But at game start I initialize the contents of all treasure chests in the game and what they contain into a single grid, and then at run-time I'm just updating those quantities when you open them. The big difference is that I initialize all the information in a script at game start instead of placing stuff in the room editor and then reading it into a grid later. You could something similar to track your chests, and what bosses have been fought.
 
R

rawket

Guest
As far as storing instances between rooms, this is how I did it once. It was convoluted and there are probably better ways.

1)
Initialize a grid. It could have cells like this....
room | object_index | x | y | etc

2)
Also, initialize a list. The list is simply a list of rooms visited.

3)
Parent all your objects that need to be stored to something like "par_gamestate_object"


Then, at runtime, you'll do the following...

1)
When you enter a room, check the list. If you've never been here before, add it to the list.

2)
When you exit a room, loop through all the instances of par_gamestate_object. Save their data to your grid... room,object_index,x,y,etc.

3)
When you enter a room again, check the list. If you've been here before, destroy all instances of par_gamestate_object. For each row that matches the current room, create an instance of the object with your values you saved. Then remove those lines from the grid. (When you leave again, they'll be rewritten if they are still there)

Then when you save or load, you can easily read and write the grid using ds_list_read(), ds_grid_read() and ds_list_write(), ds_grid_write(). There are other caveats you may run across, but that's the simplest version of it.

In my current project I'm only dealing with treasure chests so far, and so I've done something similar. But at game start I initialize the contents of all treasure chests in the game and what they contain into a single grid, and then at run-time I'm just updating those quantities when you open them. The big difference is that I initialize all the information in a script at game start instead of placing stuff in the room editor and then reading it into a grid later. You could something similar to track your chests, and what bosses have been fought.
So I understand how to use the grids. What I don't understand is, how do I have something like a chests extra value being open or closed, and a door, being broken or whole. Even worse is I have some objects that reference other objects by their ID as part of their creation code in the room editor. If I destroy and recreate objects at the beginning of each room, how ill I account for that? Idk how much this making sense I do better explaining through showing an example
 

Nidoking

Member
All of those things you mentioned would be stored in the grid. Chest open or closed? It's a variable; store it in the grid. Door broken? Store it in the grid. Instance IDs of other instances? Well, those you'd have to determine afresh each time. Really, you're probably better off just making the rooms persistent at this point, because you can't possibly be saving much memory trying to do this.
 
R

rawket

Guest
All of those things you mentioned would be stored in the grid. Chest open or closed? It's a variable; store it in the grid. Door broken? Store it in the grid. Instance IDs of other instances? Well, those you'd have to determine afresh each time. Really, you're probably better off just making the rooms persistent at this point, because you can't possibly be saving much memory trying to do this.
Ok so I guess what I'd have is like any object in that array instead of having true/false, i should have it like just sate = "value"? then How do I create those objects with those values? because doing - with instance_create(obj_object){state = grid[x,y]} - that won't change that value will it? because that object won't have the grid. Or can I do instance_create(obj_object).state = grid[x,y]?

Side note IDK how to put the code in those little boxes on here to make it clearer
 
R

rawket

Guest
Ok so I guess what I'd have is like any object in that array instead of having true/false, i should have it like just sate = "value"? then How do I create those objects with those values? because doing - with instance_create(obj_object){state = grid[x,y]} - that won't change that value will it? because that object won't have the grid. Or can I do instance_create(obj_object).state = grid[x,y]?

Side note IDK how to put the code in those little boxes on here to make it clearer
Wait no! ds grids aren't exclusive to the object that created them are they? That's how I can make new instances using a grid ok NOW I think I get it.
 
Top