Technical Design Question

I’ve got a very general question but I’m putting it here for the outcome might be different in e.g. an Adventuron game.

How would you technically set up the rooms in a game that has a day/night cycle? Like, there’s indoor and outdoor rooms, and the outdoor rooms would need a different description, there’s less details to see (and some of the visible ones would look different, too), and there’s less to do (e.g. shops are closed). Also, depending on the progress a distinction is necessary here and there, like persons/objects present/not present.

Two rooms with copy&paste for what’s identical? One room with [if night is 1][else][end if]? A clever solution I didn’t think of yet? What’s best depending on which circumstances?

I lean strongly towards the single-room plan with lots of “[if…]” blocks. Takes some testing, but so does everything.

The advantage with the single-room plan is that if the player drops something there at night, it will still be there in the morning.

Also, if you add some scenery and forget to put the “[if…]” in its description, it defaults to being present both day and night with no change. That’s often good enough, really.

4 Likes

Definitely single rooms, imo. Keeping separate rooms in sync is always a pain.

For my ECTOCOMP entry (The Enigma of the Old Manor House), this is the core of the light system:

A thing can be lightbound, darkbound, or unbound. A thing is usually unbound.
To decide whether there should be light: [game-specific code]

“Unscopable” is from Scopability by Brady Garvin, and keeps the parser from recognizing something.

To rearrange the set:
	if there should be light:
		now all lightbound things are scopable;
		now all lightbound things are not undescribed;
		now all darkbound things are unscopable;
		now all darkbound things are undescribed;
	otherwise:
		now all darkbound things are scopable;
		now all darkbound things are not undescribed;
		now all lightbound things are unscopable;
		now all lightbound things are undescribed.

For some more reasonable error messages:

Before doing anything with an unscopable thing:
	now the latest parser error is the can't see any such thing error;
	carry out the printing a parser error activity;
	stop the action.
Rule for printing a parser error when the latest parser error is the can't see any such thing error and there should be darkness: say "You feel around, but can't find any such thing in the dark."

Then you just have to rearrange the set at appropriate moments:

Every turn: rearrange the set.
After going: rearrange the set; continue the action.
Before looking: rearrange the set.
When play begins: rearrange the set.

The overall effect is that “lightbound” things are only accessible when there’s light, and “darkbound” things when there isn’t, but they’re still part of the world model and don’t forget their state or where they’re supposed to be, even when they’re inaccessible. For your purposes, you could make it “daybound” and “nightbound”, like the Magic the Gathering keyword that inspired my terminology.

5 Likes

I’d suggest boning up on regions and backdrops:

For instance, for things, this suggests moving a backdrop in or out of a region. (While people can be scenery, 'cause that’s really a property, not a kind, people can’t be backdrops.)

Note that regions can be nested, so you might have Indoors and Outdoors as your big regions but then have any number of others within them.

And then for things related to organizing passage of time, check out

1 Like

Thanks, so I’ll go with single rooms.