SOLVED: Best Practices: Room States

[Cerno]

Hello all.

Using the search I found a few interesting entries but none answered my particular question, so here goes:

Assuming in the course of the game, an event happens which causes a room's state to change (a new character appears, new dialog options arise, objects appear or disappear). I was wondering which would be the best way to implement such a change and two possibilities came to mind:

1) Have one room and script out the different states (before and after the event)
disadvantages:
- more error-prone in case of scripting bugs
- possibly difficult not to get confused in case of many states
- possibly more difficult testing all the states

2) Have one room for each state each with the necessary modifications (additional characters etc.)
disadvantages:
- larger number of rooms (room limit, game size)
- lots of redundancy in hotspot descriptions, dialogs, etc. potentially leading to inconsistencies

Originally I was planning to go for option 2) since it would make testing much easier and generally be less error-prone. However, reading the forums, I am getting more and more inclined towards option 1)

So, from your experience, what is the best way to go?
Are there situations in which you prefer variant 2) or do you always take the scripting path of 1)?
How do you generally handle the complexity of rooms that have multiple states?
How do you properly test the different states to prevent any game-breaking scripting bugs?

Thanks in advance for your input and experience.

[Intense Degree]

Personally, the only situation in which I think I would use option 2 would be if everything in the room changed so dramatically to basically make it another room, i.e. a room where a bomb has gone off changing the background, walkable areas, hotspots etc. Otherwise it seems like a massive amount of hassle and duplication. You would also have to have alternate code in every other room from which you can enter the room(s) in question to ensure you entered the right room.

Option 1, for the things you have mentioned (character, dialog, objects), is much simpler and doesn't require much scripting at all - changing a character's room, adding dialog options and turning objects off and on are simple, as is checking if they are present or not. If there are several states the room might be in that are specifically very different (rather than just is a character there, is an object present) then set a variable or two to keep track of what state the room is in which can be checked where necessary. As long as you plan well enough it shouldn't be a problem.

Also, don't want to be "that guy" but wrong forum?

[Andail]

You would never go with #2. (Edit: Unless the room as a whole has changed, as Intense Degree points out)

Frankly, you're over-complicating and over-thinking what is the most fundamental part of AGS (and adventure games), namely that things change.

You achieve this in a number of ways, so it's hard to sum it all up in one answer. You will always have the option to set global variables, and when the room is loaded, you check if the variable in question has the necessary state for a change to take place.

Other times, you simply execute the change in your current script, and it will take place the next time the player character enters the room. Things like moving around characters and adding dialogue options are independent on what room is currently showing.

If you have a specific scenario in mind, please describe it, and we can walk you through it.

[Cerno]

Thanks for the input.

I am currently writing the detailed design document and implementing some parts of the prologue.
Based on your suggestions I will have to rewrite the document as I already planned to do it using separate rooms.

I haven't done much scripting in AGS yet since I am more in the planning phase but I feel that it was a good idea to ask this question at this point in time so that I won't have to rewrite the whole design document.

So one use case I was thinking about was a day/night change. But from your suggestions it might actually make more sense to use the same room and just replace the background image for the night version. That way, I could keep all the areas and scripts in place.

Thank you very much for the offer of a walkthrough, however, I think it would make more sense to gather some more experience with scripting before going into details.

Thanks for your thoughts.

PS: Sorry if this is the wrong forum, please move if necessary.

[Andail]

Already moved the thread to beginner's technical.

Yeah, a day and night effect is easily achieved by importing a second background picture to the room. You then disable the default background animation by locking the frame with

Code: ags

SetBackgroundFrame (int frame)

If you search the forum you will find it described more thoroughly.

[Khris]

Seconding everything said so far by IntenseDegree and Andail.

I just want to add that option 2 might be the better choice if you were to use another engine. But one of the beautiful things about AGS is the powerful scripting language, and implementing even complicated room changes is quite manageable, provided some planning ahead is done.

[Crimson Wizard]

I would, perhaps, add a small comment, in response to the first post:

Assuming in the course of the game, an event happens which causes a room's state to change (a new character appears, new dialog options arise, objects appear or disappear).

Not everything you listed there is strictly room-connected in AGS.

Characters are not room-connected, they exist in the "universe" of the game, not single room, and may travel freely around all rooms.
Dialogs and dialog options are not room-connected, similarily they are shared by all game, and one dialog may be started in many rooms, in theory (I am not sure this is something people do often in practice, though).

So, the state of the game is not defined only by a state of rooms, but by a combination of states of rooms, characters, dialogs, inventory items, as well as global script variables.

[Cerno]

Thanks again everyone for the help.
I have rewritten what I had so far and it becomes much clearer and better to handle (on paper so far).

I actually do have the case of a room that dramatically changes (similar to a bomb going off) and I will take your advice and model that change as a separate room. Mind you, I do not have anything implemented, but the planning has become much clearer with your help.

Hopefully around Easter I can present the first prototype.

[Slasher]

similar to a bomb going off

There are a few ways you can do this: Changing the background frame and changing the object sprites etc etc and using variables.

Of course if it's THAT dramatic then maybe do another room.

Good luck with the project