The Prototype Level and Next Steps

Alright, so since last post, some really solid progress has been made. About a week ago, I had a sort of impromptu meeting with my art guy Aidan (who you can find on Bluesky) to discuss parameters, especially as we start to move towards a point where he will start actually creating models for the rooms. We set out some parameters with the intent of creating a design space we can have a lot of flexibility with while also making sure we have consistency.

The room parameters from my brand new internal gitlab wiki

As you can see, these are basically just size requirements to maintain when designing rooms. That said, the only rules here that are really hard rules are the wall sizes and the minimum sizes. The walls need to maintain a specific width so that doors fit into them properly, of course. The minimum room size was defined through testing, with anything smaller than that feeling too small to constitute a whole room. The door and hallways minimums are so that the player can actually fit through them. Everything else here is mostly a suggestion that can be broken, with good enough reason. That said, we’ve defined some guidelines for what constitutes a good enough reason as well. Rooms we design fall on a spectrum of purpose. This spectrum is from “travel room” to “destination room”. In general, rooms that fall closer to being a “destination room” are more allowed to break the above rules for impact. For example, the 4 way intersection piece is about as travel as a travel room can get and, as such, should stick pretty strictly to the rules. On the other hand, a unique room either as a focal point of a floor, part of the secret hunt, or otherwise, is very much on the destination room side of things, and can just about break all the rules if it wanted to. In the middle is where things get a little tricky. For example, a room that I’ve wanted to have (and can’t remember if I’ve talked about in the past, nor am I going to go look it up to find out) is an elevator shaft room. This room would be a unique room within the floor (or 1 of 2, maybe), but its primary purpose is to create a connection point where the level can spread out from. This plants it very firmly in the middle of the spectrum. For this room in particular, I think it would be reasonable to break the maximum size parameter, specifically in the height department, since that would create good impact and makes sense for the room type.

Now, with all of that out of the way, we decided it would be a good idea for me to create a prototype room using these parameters in order to test them out and demonstrate the capabilities of the generator system after I rewrote it in the last post. Here’s the parameters we set out for that:

As you can see, my todo list continues to grow

I’m happy to report that this undertaking only took me about 4 or 5 days. Not only that, but what I made actually exceeds the requirements laid out in this part of the todo list.

The first thing I’ll talk about quickly is that point talking about detecting what door is in a doorframe. Part of the reason I rewrote the generator to use sockets is I wanted to create a system that could use multiple door types in differently shaped doorframes. However, this means that the rooms themselves need to be able to detect what door got placed where and enable the appropriate geometry to match it. To accomplish this, I’ve done a couple of things. Firstly, I created a sort of prefab that I can just plop down in doors instead of having to create several components, tag them appropriately, etc. each time.

This not only makes it way easier to quickly add new doorways to rooms, but also makes configuring each doorway a lot simpler. Each part of a doorway that needs configured is now a variable connected to a construction script that is instance editable. As you can see, this includes 2 box colliders. The top one is for the loop creating system and has existed like this for ages. The bottom one is new and related to the doorway system. This box’s responsibility is to detect when a door spawns in its doorway, identify it, and then tell the room which doorway geometry to enable. To pat my own pack a little bit, I think the way it does this is a bit clever. So each socket that doorways can use has a data table entry that defines what types of doors can spawn in that socket. When this collider detects a door, it grabs the data table row for its socket and searches for that door’s class. When found, it grabs the index in the array and passes that to the room. This is because the data tables are defined before runtime and don’t ever change afterwards unless I make a change to them, so this means for the purposes of this, the index of a door in this data table is a sort of ID number. The last step of this is each doorway has a structure of scene components and geometry that defined each doorway’s set of door frame geometry. When the doorway tells the room which door is where, the room enables the appropriate geometry accordingly.

2 doorways in the same room with different sizes

As you can see here, this allows us to have doors of different sizes and shapes on the same socket. The rules for that particular socket just need to be defined ahead of time so that rooms can be built appropriately with them in mind. Now, lets check out some more of the prototype floor.

Since I was designing this floor as if it could possibly end up being the actual first floor of the game, I thought it’d make sense for the first room right outside of the elevator to be a sort of reception area that then leads off to the rest of the facility.

This is the hallway section of the floor. As you can see here, these hallways don’t generate “doors” between them, but the gates on the left as well as the boxes on the right are both “door types” that the hallways can generate between themselves. This is what I was referring to when I said I actually exceeded my parameters, because both socket types used in this floor have more than 1 door type. The inspiration for “doors” like this come directly from SCP: Secret Laboratory’s new Heavy Containment Zone, which has “doors” like this that are not actual doors you can interact with, but just create obstructions that you need to figure out how to navigate.

This room is very much Lethal Company inspired. I wanted to make sure the prototype floor had a place where you could fall to your death, so this room is that. This also gave me the idea of having objectives that are suspended from the ceiling, above the pit, encouraging you to jump up on the railing.

This room is meant to be a sort of server room — I didn’t really have a good material to give off that vibe so I used the closest thing I had for now. The idea of this room was to be a sort of longer “hallway” while also being a claustrophobic room (pushing this minimum hall-size parameters).

In level design, usually you want to have some kind of focal point. I figured a big office room would be a good one for this potential-first-floor of the game. They’re mostly unused here, but this room actually has 6 potential doorways and I created a new feature for the floor generator to assist it. This new feature is a “force spawn” condition that can be enabled on rooms. Due to how the generator works, large rooms have a disproportionately high chance of colliding with an existing room and failing to spawn. This means that a lot of the time, large rooms end up shaking out to the fringes of the floor. In this case, I didn’t want this to happen, as this rooms is supposed to be a big focal point and also a hub that the floor can continue to generate off of. When force spawn is enabled, instead of picking a new room if it fails to spawn, the generator will just keep attempting to spawn this room until either it succeeds or the generation is deemed a failure and it restarts. It’s not super smart quite yet — it still just randomly places the room instead of methodically going through each exit — but for now it works well enough for me.

So with the prototype floor complete, I had another meeting with Aidan to show it off to him and he was very impressed by the progress. In terms of testing parameters, there was one I did end up changing as I built this floor — the minimum room size. The one you saw before is what I landed on as a minimum, but when we originally wrote them out it was 500 x 500 x 500. I tried out this size originally but it felt just too small for anything interesting to be made at that size. With that in mind, I upped the minimum size by 250 in the lateral directions. The rest of the parameters we laid out were pretty much right on the money first try, which was good to see. Now, onto next steps.

So next up on my todo list is coming up with some more interesting objectives than “press E on pipe”. I was thinking a little bit about potentially having some objectives require certain items to complete, but I didn’t like that something like that introduces the potential for a softlock. In terms of items being used for objectives, my current thoughts on the matter is maybe certain items can make certain objectives easier or faster, but an objective should never require an item.

Now, while I was thinking about what kinds of objectives could be cool, ADHD brain did what ADHD brain does best and got sidetracked. I was starting to realize that just randomly spawning objectives everywhere willy-nilly with no regard for where they are could be incongruous — imagine a big pipe spawning in an office block or a big objective spawning in a space only big enough for a small one. This lead me to the logical conclusion: objectives need sockets. This would allow us to indicate not only the size of a spawn point but also the theme of it, to allow objectives to spawn where they make sense, both physically and thematically.

Luckily this is an extremely easy feature to implement and already exists as of writing this, since it basically works exactly how the door sockets work. However, while I was working on this, ADHD brain struck again and started thinking about the idea of room objectives. I was thinking about the potential for having a really big objective that only spawns in 1 room type, but doing that with the existing system always would have the potential to spawn the room but not the objective, making a really lame empty room. The solution, I realized, is just to manually place the objective in the room. This means that whenever the room in question spawns, it would always have its cool big objective in it. Now, just doing this as is would work, but it’d sort of mess with the generator a little bit, since it would have no idea these additional objective points already exist in the floor. The solution is pretty simple luckily. We can create a new scene component to hold pre-placed objectives that the generator scans when it spawns a room. If it finds any, it can add their objective values to the variable it uses to track that. Then, when generation is complete, the objective spawning portion of the generator is sort of filling in the gaps of points. For example, maybe the generator is trying to generate 250 points of objectives for this floor and gets 170 through pre-placed objectives. The objective spawning part then only needs to spawn 80 points worth of objectives rather than the full 250.

This pre-placed objectives part hasn’t been implemented yet, but honestly it’s probably simpler than the sockets system, so I hope to report next week that it’s implemented and working. I’m also hoping to start getting some more interesting objectives in place, so look forward to that!

The Prototype Level and Next Steps

The Great Generator Shift