ShadowRx
patreon
Rooms, Sub-Rooms, and Tags...
🕑 Added 2019-04-20 20:43:09 +0000 UTCSub-rooms... how the hell do I handle those? We're not talking full-rooms that are only accessible from another, we're talking about subdivisions within a room... like how the Gym and S-Mart work.
I suppose I could try to make the definition of a room a bit more flexible, I have to for outdoor zones anyway. Perhaps rooms could have a property as to whether they are walled/fenced off, and what the cover/obstruction % of that wall/fence is for anything that needs to estimate how much sound and light passes (like whether you can see & hear someone on the other side).
The data-structure for instancing is simple enough, we just use longer IDs. Navigation between depth-layers should be automatically available, but sibling rooms require a connection entry of some kind. And, while we're planning this, we should probably reserve little bits like where sibling rooms are located (which wall, and what portion of the wall), in the increasingly probable event that you decide to make your own doors... (something I was/am planning to feature in The Rescue)
If we include the coordinates and scale for rooms, we could later incorporate a floor-plan/map system for buildings. We could probably also reverse that system to allow us to design them in the CMS, or build RNG generator functions to allow the game to add new houses, etc., dynamically. (which is a planned feature for when you start tracking down NPC homes)
We also need to decide how to handle being in 2 rooms at once, particularly as some rooms are too small to fully enter. (like most closets/cabinets) And where do we draw the line between rooms and furnishings that provide similar functionality?
I suppose we can state that kitchen-cabinets are a fixed-position/nailed-down furnishing, but closets are still very much separate rooms or sub-rooms; even when they are just enclosed pantry shelves with zero walking space, though that example may be more suited to be treated as a cabinet furnishing, despite affecting walls. Does this mean we need to allow furnishings to affect walls? What do we do for alcoves and windows?
There is still a lot to plan for rooms, so for now the old-UI will keep using passages for locations and/or allow each to directly manage its zones/pseudo-rooms, rather than converting them over to a full room-system.
The new-UI, however, does not have a choice in this matter, it must use a room system, even if that system has locations define their rooms manually for now. So, what I really need is an approach that is compatible with both... or to figure out how to handle the sub-room problem systematically, including whether parent-room actions are still available.
Perhaps we can treat the entire building as a series of nested rooms, give each room a set of coordinates and the ability to define it's walls/doors/etc., and to decide which actions/properties to share with sub-rooms/parents?
We could create handler pseudo-passages for each entry into the rooms table, similar to how the scenes table works, and that would solve the old-/new-UI compatibility issue, but it does leave another...
How do we make this compatible with room-prototypes? Do we need to manually define every room in every building for now, or can we have some rooms generated dynamically (such as bedrooms for housing)?
The room-handlers should be separated from the raw room structure/properties, but be able to utilize that information at runtime. In this way, many room instances could share the same prototype handler: perhaps, for example, all bedrooms behave in essentially the same way, no matter how big they are or how they are furnished or what other rooms/sub-rooms they are connected to.
But then, what truly IS a bedroom, perhaps we need assignable roles for rooms. Any room with a bed can be used AS a bedroom, and in the case of motel rooms & studio apartments, the same room may serve many such purposes. This would be a good case to use undivided sub-rooms/zones to make such housing work.
Many houses have had their "bedrooms" converted/repurposed as studies, offices, storage-rooms, etc.; so, regardless of the designer's (architect or game-) original intent, we must acknowledge that the nature/purpose of any room can be changed. And while said purpose may be clear and definitive in the Astral Plane, it's rather a bit less so here in the Mortal Plane. To solve this, we need to subdivide rooms into sections that may or may not (at their own discretionary property/trait) share actions with the parent room, and thus other/sibling sections. Much of which can be handled with a tag-system and some kind of inheritance (in one or both directions). Perhaps we can solve this by having cascading inheritance of tags in all NON-DIVIDED sub-rooms, so the alarm-clock is available to the entire bedroom, no matter which section of it you are in.
Does all this mean we decide on room roles/etc. purely based on what tags they contain? Perhaps, but likewise some rooms have native tags that may define what furnishings CAN be added, thus what other tags it might accept. For example, you'll have a damned hard time adding a sink or shower to a room without access to water/plumbing. (a tag that technically should belong to one of the walls in most cases, though it can be run through the floor, or even the ceiling as well)
v0.27 can work without answering some of these questions, but v0.3 must incorporate solutions to all of them, in order to unify the old and new designs.
I present them for discussion/feedback, and because I occasionally need a sounding board outside my own head to work things out. Please feel free (and even encouraged) to comment on this.
(P.S. I am still working to get an update out this weekend, at least a beta if not a full public release, and need to add the outdoors areas to the current locations.
In particular, the Look for Change passage needs to become part of using the explore/search action while in the parking lot of S-Mart and other locations.
I also need to incorporate a special handling for using a vehicle for housing... specifically, the location of the vehicle and what that means in terms of entering and exiting it. This will mean Cindy will have to return to the location of her car, and that it may be parked in places other than just outside S-Mart.
And we're converting the menu's over to a much more compact and unified system, which will free up a bunch of UI space and the bottom row of hotkeys. The menu will be called up with the [TAB] key, since I'm keeping the tilde/backtick key reserved for a possible console window and/or dialogue system.
Pressing [TAB] will bring up a master-menu listing all the available sub-menus, much like most JRPGs do. Eventually the save/load, settings/config, and help/guide menus will be moved in here; as well as the status-information from the sidebar, completely freeing up that space.)
