From 3fc647389c5ce312fb6fd7518289030b10ed3861 Mon Sep 17 00:00:00 2001 From: vilmibm Date: Mon, 2 Jan 2023 22:53:10 -0800 Subject: [PATCH] draft new exit design --- roadmap.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/roadmap.md b/roadmap.md index c251e8d..821bc90 100644 --- a/roadmap.md +++ b/roadmap.md @@ -23,6 +23,22 @@ In tildemush, inter-room movement worked like this: I don't like the exit simultaneously existing in two rooms at once or the special handling at the server level. +I can't actually remember how I ended up with the previous exit design. I think I wanted exits to be owned objects, but in retrospect, that leads to some clumsy code and situations. + +I want exits to be game objects because they should be scriptable. if they are game objects, they have to exist somewhere in the game. They then have to be contained and I think should only be contained in one room. Thus, there is the problem of how to know what exits a room has if one of its exits is in its adjoining room. My proposal for this is as such: + +- add an exits table with columns + - start_room + - end_room + - direction + - exitID +- when parsing an object, ensure it matches the exits table (keep track of what `go` handler it has) +- when checking a room for exits, search exits table for rows in exits where start_room or end_room match the room + +This means that to edit an exit you would need to be in the room where the exit actually exists (start room). i could sugarize this by ensuring that exits technically contained in another room be included in the Earshot list. this would make them behave as if they were contained in two places but wouldn't actually violate physics. + +It's tempting to have the `exits` map because of its simplicity, but it actually reduces scriptability. by forcing the WITCH surface area of exits to be a "go" handler we get a chance as the system to hook into exit creation and a chance as a user to hook into people moving through exits. + TODO draft something new ## server beta