• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Newbie question: Best way to store state for off-screen objects

A

axialgentleman

Guest
I'm new to GameMaker and very excited! For my first little project, I'm creating a classic first-person escape-the-room game. The room has four "walls" -- four separate screens that the player can switch back and forth between at will, manipulating objects and solving puzzles.

I'm trying to get a handle on how to store and access information about the objects in the room, including ones the player isn't currently looking at. For example, when the player faces the North wall and presses a keypad, I need to check whether they previously flipped the circuit breaker on the South wall.

From what I've read, there are a few options:
  1. Each wall is a separate room. The objects on the walls are persistent so I can access their state at any time (e.g., check the value of the `flipped` variable on the circuit breaker object). I only draw them when the player is looking at the appropriate wall.
  2. Each wall is a separate room. The objects are destroyed whenever the player switches rooms but I store information about their state in a global data structure so I can check it at any time, and re-create them in the right state when the player is looking at them again.
  3. The entire game is in one room that contains all four walls, and I switch between them using different views

I'd appreciate any advice on the right way to think about this! Are any of these approaches considered better practice, more effective, or less likely to cause me trouble down the road?

[I'll also happily accept RTFM responses, especially if you can point me to the appropriate term or concept to look for]

Software: GMS2 Runtime v 2.2.1.287 on Mac OS 10.13
 

samspade

Member
I'm new to GameMaker and very excited! For my first little project, I'm creating a classic first-person escape-the-room game. The room has four "walls" -- four separate screens that the player can switch back and forth between at will, manipulating objects and solving puzzles.

I'm trying to get a handle on how to store and access information about the objects in the room, including ones the player isn't currently looking at. For example, when the player faces the North wall and presses a keypad, I need to check whether they previously flipped the circuit breaker on the South wall.

From what I've read, there are a few options:
  1. Each wall is a separate room. The objects on the walls are persistent so I can access their state at any time (e.g., check the value of the `flipped` variable on the circuit breaker object). I only draw them when the player is looking at the appropriate wall.
  2. Each wall is a separate room. The objects are destroyed whenever the player switches rooms but I store information about their state in a global data structure so I can check it at any time, and re-create them in the right state when the player is looking at them again.
  3. The entire game is in one room that contains all four walls, and I switch between them using different views

I'd appreciate any advice on the right way to think about this! Are any of these approaches considered better practice, more effective, or less likely to cause me trouble down the road?

[I'll also happily accept RTFM responses, especially if you can point me to the appropriate term or concept to look for]

Software: GMS2 Runtime v 2.2.1.287 on Mac OS 10.13
Any of those options would work. Personally though I would either do:
  • 1 room, 1 view, multiple objects (not on your list)
  • separate rooms, global variables (option 2 on your list)
I use the first option a lot for menus, which are basically what you're describing. Same room, same view, just different object set ups. It does take a little more conceptual head room though and would be harder to use the room editor to design. Second option would also be fine. For something like a full game, I would probably do that. Different rooms with key variables being global. Probably a lot easier to keep straight and design as it would be easier to use the room editor.
 
S

spoonsinbunnies

Guest
  1. Any of these methods will work, people here tend to say things like if it isn't broke don't fix it, or if it'd bad code but works it's not bad code, I would personally do b or c. B would be the easiest on the players machine as one object with 20 extra variables is less data than all the variables that are prebuilt into each object. but early optimizing is its own demon. I'd say pick with your gut which you think would be easiest for you to make. If you understand persistance well use A if your an effecincy nerd you only need one object persistent(technically you don't even need the variables global) and if your iffy on both just make it one really long room and toggle veiws, all the answers are fine.
 
A

axialgentleman

Guest
Thanks for sharing your thoughts! It sounds to me like #2 is going to be a good middle ground between using an approach I intuitively understand and getting some practice with new gamemaker concepts.
 
D

Danei

Guest
I like to make switches and triggers a global scope DS_map where the key is the name (e.g. "door_A1_0", "button_D2_4") and the value is the state of the switch (i just use numbers for that). That makes it easy to check and alter the values regardless of room and without having to worry about object persistence or passing IDs back and forth.
 
A

axialgentleman

Guest
Thanks! I find that approach appealing -- my one worry was that I'd end up having to remember to keep everything in two places and have problems where they get out of sync (e.g,. when the player opens a door I need to act on the door object, and also update the door_status variable on the DS_map). Do you ever run into issues like this, or are you able to keep one source of truth for everything?
 
D

Danei

Guest
I mean, you do have to remember to change the values or you risk running into that issue. In my case, my objects have a variable, mySwitch, that is one of the keys in the map. Inside each instance, I add the appropriate value in the creation code in the IDE, and part of the script for activating an object includes advancing the value of the key that is equal to mySwitch. I have mySwitch initialized to -4 in the object create event, which gets overwritten by the instance creation code, and some code to throw up a debug message if mySwitch == -4 (just in case I forget to give an instance a matching key).

My instances determine whether they're open/active/triggered etc. based on reading the DS_map as well, so the instance just decides how it looks or what it's doing based on the value of the corresponding map entry.
 
Top