Best way to implement doors?

The Thimbleweed Park blog has inspired me to try to code up a simple point and click engine. I’m currently thinking about connecting rooms.

The obvious solution seems to be to go with room doors/exits as explicit placed objects that the engine manages. However, after reading a few of the early dev blog posts it looks like implementing doors and exits by lashing together an Object, some metadata and a few script fragments might be the way to go. I guess this would allow the doors to be much more flexible, and allow special cases such as the Forest, Elevator and Vista to be implemented easily in script with no engine changes.

Having said that, it would seem that the engine does need some behind-the-scripts knowledge of the concept of a door, which has left me a little confused about the best/simplest/most-flexible way to implement them.

In the Wimpy blog post it looks like bankToAStreetDoor is just an Object without an image. Then the Scrolling Rooms post shows a bit of script for the Bank containing:

bankToMainStreetDoor =
{
  name = "Door"
  quickExit = true    // Actor exits before fully reaching the door
  walkTo = function()
  {
  }
}

Putting two and two together it seems that doors are not built into the engine as “first class objects” but are just implemented as Object + script. In this case to make the bank door functional I guess the scripter (David Fox) might just add a call like enterRoomFromDoor(MainStreet.mainStreetToBankDoor) inside the (verb)walkTo function which would be called when the selected character touches the hit box. (see the ThimbleScript Wiki on Rooms)

However I guess that actual physical doors must be special case objects so the engine can automatically open and take you through them when they are used, and change the cursor when you hover over them. Perhaps this could be achieved with a property on the door Object, maybe simply it’s name containing the string “Door” maybe?

I’d love to hear a bit more about how rooms are connected in Thimbleweed Park and why.

1 Like

You are right that doors are not first class objects, they are just objects, but they do have animations (the opening). The code you’ve posted in pretty old, the actual code is:

bankMainStreetDoor =
{
	name = NAME(26036,"doors")
	flags = DOOR_LEFT
	defaultVerb = VERB_OPEN
	enterWalk = 50
	autoDoorSounds(soundGlassDoorOpen, soundGlassDoorClose)
	verbWalkTo = function()
	{
		exitRoomFromDoor(this, mainStreetBankDoor)
	}
	verbOpen = function()
	{
		openDoors(this, mainStreetBankDoor)
	}
	verbClose = function()
	{
		closeDoors(this, mainStreetBankDoor)
	}
}

The exitRoomFromDoor() is a script function that does all the fancy stuff, like closing the door behind the player, etc.

All this is done in the script code, then engine doesn’t know anything about doors.

4 Likes

That’s great thanks. So the DOOR_LEFT flag is a hint to the engine to change the cursor when hovered over, and I guess the verbWalkTo is only executed when the actor reaches the use-pos.

Apropos of nothing much and just because I like thinking about this sort of thing, one of my never finishing projects is a 2D point-n-click engine+game (by which I mean I’m writing it in such a way that I can swap out assets and resources and reconnects rooms etc at any time, but the engine creation is driven by what the game needs next).

Here’s a room transition, in beautiful ogv format (using a couple of example images, which I think are harmless enough to count as fair use):

I’m doing this by having each room contain regions of interest. Clicking a point in the room causes a check to see if that region is a region of interest. If it is, then the region (which is owned by the room object) is quizzed for a point to walk to and the player object receives an instruction to walk to that point. If it’s a door, a room transition is triggered upon arrival. The hardest things to think about have been how to model things like movement and room transition. The ogv shows what happens if it’s a different kind of area of interest too; the sign has a walkto point and upon arrival the pklayer object is triggered to say something.

Ordering an object to walk to a point is clear; the object representing the player is simply given a new destination point, as if the player had clicked that point themselves, and the player object can then be trusted to organise moving the the right pace by itself. I ended up making room transitions the responsibility of the main window, in effect; since the main window is what loads rooms and tells a room to render itself (in my design), it was the most natural thing to do. The hardest part of all of this is definitely a sensible design, but so far it’s working out; as I need to make it deeper and more featured, the right place for everything added is clear and intuitive.

1 Like

So, presumably, you could call exitRoomFromDoor() from any object and magically make it into a “door” (like a “teleporter”), right?

Correct. I do stuff like that when debugging. I don’t want to walk all the way to the Mansion, so I make the cash register in the dinner a “door” that takes me to the library.

3 Likes