Switching between layouts - consistency

My roguelike space adventure game has a layout with a sun in the middle, and several planets orbiting it, all generated using a pseudo-random number generator. There is of course a spaceship that is player controlled. If you click a button sprite on the screen, you'll switch to a different layout: the deck of the bridge of the ship, and you are now controlling a little figure inside the ship. Now if you walk that little figure to the elevator, a control panel with buttons pops up and you can push one that will take you to the main deck (a third layout) On the main deck you can press one that takes you back to the bridge in the same way. If you move the little figure over to the chair at the helm, you'll go back to the sun and planets (solar system) layout.

Problem 1) Now, when I go back to the solar system layout, all my planets and things are different than when I left, because the layout has reset and regenerated the solar system when I switched back to it. How do I make sure the layout continues to run and not regenerate every time I switch layouts?

Problem 2) Each deck layout requires a separate instance of the little man figure in order for the player to be able to interact with it. I suspect that any instance variables for the figure will not be carried between layouts. I'm guessing I'd have to store player character data for the figure in globals and re-apply any changes (armor worn, weapons wielded, etc) each time the layout is switched. This isn't a huge issue for the one character, but for all the data generated for the solar system, it quickly becomes impractical.

I realize the solutions I'm looking for may involve manipulation of event sheets. Currently each layout has it's own event sheet, plus the solar system layout also has a sheet I use for functions that has been included in the main sheet.

What is the best way to handle these two problems?

Problem 1) There really is no solid solution (in my opinion at least) for saving layout state at the moment. Developers are working on it and have said there is something coming sometime in the future. In the meantime, here are few helpful things that might help you to come up with solution of your own: SpriteBank plugin, saves states of sprites and allows you to load them later. You can also set objects global in object settings, so they persist through layouts.

Seems to me like you need to save your generated solar system and put it into desired state every time you move in to solar system layout.

Problem 2) Global switch would probably work here, so stick man persists through layouts. You need to hide him in non-desired layouts though, like solar system layout.

Hope these help :)

Yttermayn If you are using a random number as the seed for your layout, store the number on the first run of the layout in a global variable and then use that number as your seed an consecutive loads of the layout.

— that will help only part of the problem - For instance, I suppose he has the planets rotating, etc.

Have you tried storing this data in arrays? Or is that impractical for your purposes?

If all else fails, (this is a radical suggestion and I haven't thought about many of the ramifications) you might want to think about including everything - all ship layouts, star system view, etc, on the game layout in different 'zones'? If you do it right, you might be able to pull off a cool 'zoom out' effect to star system view when you sit in the captain's seat.

By the way, cool game idea! It should be awesome when it's done!

A little more info about the structure of the game's solar objects- Each planet has instance variables that hold data such as size, orbital velocity, distance from the star, etc. They will likely hold much more as the game developement progresses. I am taking an object oriented approach to the design, basically.

Vee41: Saving layout state would be ideal, but obviously not viable solution at the moment. Thanks for the info though. Looked at sprite bank, also another good idea, but it doesn't sound like it stores instance variables, so that's out. Your solution to problem 2 sounds like it will work. Will try it and post. Thanks!

Bluephaze: By default, all my systems in the game will have a seed saved for them, but that doesn't help with player made changes to objects within the system. Maybe I need to structure in such a way that player made changes are stored globally and re-applied when entering the system. Not as convenient as saving the whole layout state would be, but it might be all I've got. I'll have to think on this a bit. Thank you.

Sqiddster: Saving in global arrays might be the only option at present, though I would prefer to keep each object's data with it for the sake of organizational convenience. If I understand your Zone idea, it would mean having everything all on one layout, basically. That is an option I considered. Could get messy, but ultimately easier. And yeah, I like the zoom out idea. Would take a little scaling and fadeing magic to pull off, but would be pretty slick to see in action. Thanks for the compliment. I've been wanting to make this game since about 1995. I'm a fan of games like Starflight, star control, Weird Worlds, and FTL. However, I've always wanted to be able to disembark to a planet or space station, walk around inside my ship (making repairs, fighting off boarders, exploring abandoned(?) space hulks, and fighting ship to ship combat, all the while collecting and manufacturing upgrades to ship and personal equipment. I don't care for the 4x games, but I love the idea of actually exploring a vast piece of space and crafting solutions to the various scenarios and difficulties you might encounter.

If you are in one particular layout, are objects in another layout inaccessible? Like could I use the same event sheet for several layouts, and then the events that keep the planets orbiting would still be run when you're in the bridge layout? Or would those events simply fail, trying to move planet objects that simply aren't there?

Seems like populating an array with your variables would be best bet for persistence, treat it like a database. If you design with that in mind, it should stay pretty clean and organized. Generation will only happen once. You can your layout load values from that array every start, into instance variables if you want, and upon exiting update the array with current values of each instance. Or you can work directly out of the array.

Instance variables by themselves are transient by nature and don't work well for persistence, especially across layouts.

Global variables are an option, but that will get terribly messy.

For your last question as well, having your data in an array would be best for updating the position of planets while you are in another layout - your logic can keep running and manipulating the array data even when that particular object doesn't exist on the current layout.

I've been playing with merging my different layouts into one huge layout, and using groups to keep my events organized. It seems to be working quite well so far. Thanks again, all. I will no doubt use some suggestions here for when I get to the point in development where the player travels to other star systems.