How to implement a general door system?

Bernd

Hi, I'd like to implement a dedicated scene that represents a door. If the character passes the door the camera should automatically move to the next room. Additionally, the door should have a state like "closed" and "open" and there are buttons (and probably keys) that open a door when you press (or use) it. I am not sure how to implement a convenient scene that fulfills those requirements without technical debts.

I have an idea on how to structure the nodes

A scene tree that represents the door could look like this Door (Node2D) --- | --- Sprite | --- Area2D | --- AnimationPlayer

The Sprite defines the appearance of the door, the Area2D triggers the walk through the door animation (camera moves to the next room) as soon as the player enters it. The door node has a script that handles everything

The AnimationPlayer contains an animation for opening the door.

Now the Node can be used in a DungeonScene in the following way

Dungeon --- | --- Player | --- Door --- | --- Button | --- ...

The Door expects some children. For instance, if there is a button (that can be checked in the door's script) the door knows that it is a door that needs to be opened by a Button and if the Button is pressed by the player it opens up. If there is a key the door knows that it only opens up if the player owns that key. If there is no child the door knows that it is an open door.

Pro: convenient to use. You only have to add the doors to your scenes and connect them with buttons, keys (and probably more) just by adding them as children

Contra: Technical debt? The door scene relies on context information. I am not sure if this is considered an Anti-Pattern.

Is that a viable path or do you have other recommendations?

Thanks

nene

Technical debt? The door scene relies on context information. I am not sure if this is considered an Anti-Pattern.

I think as long as the only "context" that the door needs are its children, you should be safe. In my experience it's a common pattern in Godot to have nodes depend on their child nodes (e.g. the builtin Area2D expects a some CollisionShape to be added as a child).

I personally don't even think of child nodes as a context. For me context would be parent and sibling nodes, i.e. everything outside of the node. Depending on that kind of context is indeed problematic and better to be avoided.

PS. I also have a generic Door scene in my own game, which expects a CollisionShape2D as a child.

soundgnome

Another option might be to have subclasses (ButtonDoor, LockDoor) that include the necessary children. If there are just a few types that are going to be used over and over again that could save time.

Bernd

@nene Thanks for your answer. That was very helpful. I am an experienced web developer but I am totally new to game development and I am still unsure what decision could turn out as an anti-pattern. My thought was that it could be a problem if you have tons of custom scenes in a big project and many of them expect several children but actually, it is the same with methods of libraries who expect several parameters. I think I will go for the additional expected child nodes in my door scene. No child node means the door is always open, a button child node means the door is connected with this button and so on and the script that is attached to the door checks what additional children are added.

@soundgnome
A ButtonDoor could potentially be connected with several buttons. Hence, I don't think this approach totally meets my requirements. How would you handle this if you can have a door that is connected with one button, another door with two buttons, and so on?

soundgnome

Well if the numbers of buttons a door might have is going to vary it might not make sense to do a subclass for that, but in the Door class you could add a node called Buttons and iterate through a get_children call on that inside _ready to set up whatever signals/logic you want. So you'd know that there would always be a Buttons node and if get_children doesn't return any results in some instances that's fine.