Taking inventory – Door solutions

As one of our current simulations will use building data to generate buildings that can be traversed by agents, who will need to be able to use doors – some with keycode/dongle or keys and others only lockable from the inside (like toilet doors) – I’m starting to check out what solutions are already present online.

The buildings are graphs with nodes of different types.

In my first prototype I used Dungeon Architect to create a sort of campus building just to figure out what it might look like, as well as to learn more about the limits of buildings generation. That said I’m still learning the ropes and I might come back to the drawing board many more times before I get this done.

I aim to make a building generation tool that can make several types of buildings, so that many more buildings in the town populated by my agents will be accessible for the agents as well as the player.

When it comes to agent homes I’m leaning towards prefabricated buildings that can have their internal walls redecorated with new paint/wallpaper textures and some different styles of lamps, carpets, furniture – think Sims and you’ll get the picture. I want my agents to have preferences and allow for them to refurbish their homes to match their personality, traits, interest, work/hobbies and relations to other agents. So those kinds of buildings present a much larger challenge than making more work related buildings.

Aside from special cases such as military bases, prisons or industrial buildings and sport areas where I might fall back to prefabs and only open up a small part for interaction, I find that schools, hospitals, libraries, campuses, labs and regular offices as well as malls may be approachable to a higher degree of automation.

Doors are used to connect rooms to corridors. Corridor doors that do not lead to other rooms may Doors also connect to stairwells, that allow traversing to other floors. Elevator doors are not handled as separate doors, but will be handled by the elevator controller in charge of the specific instance as it knows on what floor the elevator is.

Entrances/exits are starting/end-points to the buildings graph (they are the same kind, but some are fire exits that only allow for exit and otherwise trigger an alarm if opened).

The nodes in the graph know their ID and configuration (availabeFrom {inside, outside, both}, locked, primed, automated, keyType {none, physical, code, card, biometric}). A passage control system is in control of issued cards, codes and users (agents). tutorials seem promising as a starting point.

How to determine what is inside and outside, a corridor is considered to be the outside and a room the inside. For an entry/exit whatever room from the graph is connected to that door is on the inside, forcing everything else to be on the outside of the building.

But I’m drifting off into design space … let’s refocus on getting our doors to move.

The one above uses physics simulation with hinges. The one below depends on scripts and triggers. I’m probably going to extend the latter after digging through it’s design. The hinge solution looks promising for unautomated rotating exits that only allow spin in one direction, but I’m not sure if the limit to rotation can be made to rotate along with the object or not. If not, it’ll have to be another script.

LlamAcademy’s door tutorial looks like a great starting point for lockable doors, with hinges, that can be made realistic or always open away from the player to allow for a better flow. I think my agents will have to suffer realistic behavior – at least that’s where I’ll start.

The solution for the doors could be used to make windows that can be opened/closed too. A special case will be to handle windows that can have two different hinges but only one active at any time (depending on if the handle is vertical or horizontal when in the open position). Down is closed. Up tilts the window with a hinge at the bottom. Left/right depending on which side the handle is placed on uses a hinge on the opposite side to handle rotation.

Could the extra stuff be added when needed at runtime to keep the scene from being flooded with details, or should I just build smarter prefabs? I still have to figure this out, but it will take some time as writing is painful and slow. All the more incentive to make prefabs as smart as possible, thus reducing the total lines of code to write.

Coming up next (aside from posting the result on this page when done) – elevators, escalators, automated stairwells.