GameMaker Rooms for a turn-based game?

[Selek]

Do I need more than one room for a turn-based game? I'm prototyping a deck-building card game, and there are only a few screens: the main "card battle" screen, a strategic-map screen, a game-menu screen, a tech tree, and a couple of "pick rewards" screens. It's tempting to make all these screens simply by creating more and more layers in my original room. When I try to add new rooms, I have to create new instances of everything, which isn't what I want. I also have trouble transitioning from one room to the next, as new instances of objects re-initialize them, which is not what I want.

The manual suggests using persistent rooms, but then this video says "thou shalt not use persistent rooms" because they may not save my data reliably.

Thanks in advance for any suggestions and advice on how to make different screens for a turn-based game.

 

[woods]

have to create new instances of everything

maybe have your object persistent and not the room? ;o)

 

[Nidoking]

I use a parent room for the common parts and then make child rooms if there are things that need to change from room to room.

 

[Selek]

maybe have your object persistent and not the room? ;o)

Thanks for your reply. Is this the best practice, then? I have several objects with data that has to persist: the entire set of cards; the cards in the player's deck; the cards that have left the game; the player's stats; etc. I don't need most of this stuff while the player is making decisions on the main map or the tech tree, but I need to return to it when the player returns to deck-battling.

I use a parent room for the common parts and then make child rooms if there are things that need to change from room to room.

Thanks also to you for your reply. I'm not sure whether to go this route or to use "persistent objects". My rooms don't have a lot in common: different GUI, different objects. But I need my data to persist. I'm inclined to follow your lead and try parent/child rooms, but I'm curious if there's a generally-accepted practice for turn-based games, which tend to have lots of persistent information having around quite different game screens.

 

[RefresherTowel]

Use either global variables or a single persistent "controller" object to store data that needs to exist through room changes. You don't need a new object for each of piece of that data you are talking about storing, you should only really have a single object containing all of that (as in, "the entire set of cards; the cards in the player's deck; the cards that have left the game; the player's stats; etc"). That's all just data and you should store it as data in either a single persistent object or global variables/data structures. Objects are best used for "actions" (i.e. player characters, buttons, UI parts, etc), data doesn't need an individual object for each piece.

EDIT: Also, about the rooms, once you have a way to maintain data integrity through room swaps, why would you not use rooms? It's less work to make a new room and just worry about what happens in that "area" than it is to try to get your whole game working in the same room.

 

[Selek]

Use either global variables or a single persistent "controller" object to store data that needs to exist through room changes. ... why would you not use rooms? It's less work to make a new room and just worry about what happens in that "area" than it is to try to get your whole game working in the same room.

Thanks for your reply. I do in fact have a controller object that contains most (though not all) of the data I mentioned. I'll try making that persistent.

I did experiment with creating a new instance of a new object on a new layer, and yuck, it was a mess, because then I had to "turn off" all the other code in the same room. So, new rooms it is.

Thanks again for your help.

 

[Rob]

A state system will solve most of your dilemmas.
I don't really know when the "best" time to use a new room is, compared with using the same one.
When I was a beginner I used to think "new screen = new room" but a state system is a better way to handle that stuff most of the time in my opinion.
For menus, you can switch the state to Menus, so that none of the other code will run, create your menu objects and then when it's time to close the menu, destroy the menu objects and set the state back to what you need.

 

[Selek]

Thanks for your reply. I have been using a state system, but I hadn't centralized it in my game-controller object; I just finished doing that. I'll try it your way with a simple screen (e.g., pick new cards), but for the strategic map that overlays my tactical layer, I'm inclined to think I should use a new room. Many thanks.