We Be Jammin'

Still trying to move quickly through features, with an eye toward getting stuff up and running, even if crude.

Today, I finally wrote room-detection code. It's not very sophisticated, and basically treats walls like doors. Small openings/bulkheads are ignored, so rooms will pass through them. Unclosed rooms that adjoin empty space are also "rooms." However, each separate room has an object to track data, and it can set properties on the tiles it covers. I've even ported my tile-based gas exchange over to room-based gas exchange.

For the unclosed rooms, I've just added a boolean flag to say "yes, this room is unsealed." I'll see if it needs more than that later. For now, I'm thinking all it'll do is tell us whether to do a regular gas exchange or treat this room as an infinite volume into space.

In the process, I also finally fixed an AI pathfinding bug. Since there may be tiles that are both walkable yet unreachable, I needed to do a pathfinding check in the AI for such cases. If found, they'll bail out instead of setting it as a pathfinding goal.

I've also started implementing some rough code to swap out closed doors for open ones, and vice versa, when they're clicked in the crew sim mode. It's just for testing purposes, but it might be how I'll handle mode-switching items like doors. Just delete mode 1 and add mode 2 in exactly the same place. (Like NEO Scavenger's item mode switching.) The benefit of this is that I can piggyback on the ship's code which handles tile data for adding/removing parts.

It doesn't work yet, however. Doesn't crash either, though, which is weird. Monday, I'll have to see what's up, and then start pumping air into rooms to see if toggling the doors does anything.

Until then, have a good weekend, all!


Malacodor's picture

I was thinking about double doors (aka airlocks) as a single object. It could be made as small as 2x2 tiles, on the sides had to be walls - or it would be 2x4 tiles including walls. The actual doors could be 1-2 pixels thick instead of a full tile (similar to The Sims). If we assume that 32 pixels = 1 meter, then 2 pixels of steel is already quite a massive door. Double doors should be as small as possible to avoid discouraging their use. Opening one of the two doors would automatically lock the other one, and as long as one door is closed the other one can also be opened to a depressurized room.

Single doors should have the auto-lock-on-depressurization feature (to avoid that the crewmen on both sides of the door die), that double doors don't need. If you also want single doors in the game, you could make single and double doors as two different objects, but then two combined single doors would work differently from a double door, which could confuse players. This problem could be solved by only having single doors and adding a tool to manually link two doors to form an airlock. Alternatively, rooms could be defined as airlocks which would allow only one of its door to be opened at a time. That would allow for customized airlocks with more than 2x2 tiles between the doors and more than two doors, but would also make ship building more complicated. Or the ship editor could auto-detect nearby doors and ask the player if an airlock should be created. However, there had to be additional technical overhead to keep track of which doors work together as airlocks.

Light suggestion:
Red: The door is locked (depressurization / malfunction / the captain doesn't want you to leave the room since you broke his favorite coffee cup).
Purple: The door is temporarily locked because it's part of an airlock and the other door is already open.
Yellow: The door is closed but unlocked and can be opened.
Yellow blinking: The door is opening.
Green: The door is completely open.
Green blinking: The door is closing.

Ran around with a clown mask before it was cool

Malacodor's picture

For pathfinding I'd make a graph with doors as nodes and paths between doors as edges. It might be more intuitive to have rooms as nodes and doors as edges, but that won't be very useful, there wouldn't be a good way to weight the edges. Navigation inside a room works with regular tile-based pathfinding, if the target is in another room a combination of our graph and heatmaps is used. This is how I imagine the preparations:

- Detect rooms, create a data structure for storing room-related things like air pressure (let's call it 'room data')
- Detect doors, put them in a list
- Check for each door which rooms they are adjacent to it, if there's fewer than two rooms adjacent (space counts as room), remove the door from the list, since it obviously leads nowhere
- Add info about the doors to the room data, so that each room knows which doors it has
- Create heatmaps for all doors, those heatmaps only need to cover the two adjacent rooms, not more, but the doors adjacent to these must be included (for door-to-door navigation)
- For each room create edges between all adjacent doors
- Weight the edges with the distance between the doors, this can be easily done by looking up one of the doors coordinates in the other door's heatmap for each pair of connected doors

Now we have a nice weighted graph and an assortment of heatmaps. Let's say Carl wants to go to the fridge, which is in another room, then the following happens:

- Find out which room Carl is in
- Find out which room the fridge is in
- If both rooms are identical, use tile-based pathfinding and skip the rest, if not go on
- Ask Carl's room for available doors, remember them as starting doors
- Look up the distance from Carl to each door on the respective heatmap
- Ask the fridge's room for available doors, remember them as target doors
- Look up the distance from the fridge to each door on the respective heatmap
- Find the shortest paths between all possible pairs of starting and target doors
- Add the respective distances between starting doors and Carl as well as between target doors and fridge
- Find the shortest path, tell Carl the sequence of doors to use
- Carl navigates from door to door using their heatmaps
- The path from the last door to the fridge can be found by reversing the path from the fridge to that door

If, for example, Carl is in the dormitory, which has two doors A and B, and the fridge is in the kitchen, which has two doors X and Y, we first need the shortest paths between A<->X, A<->Y, B<->X and B<->Y. Then we add Carl<->A to A<->X and A<->Y, Carl<->B to B<->X and B<->Y, fridge<->X to A<->X and B<->X, fridge<->Y to A<->Y and B<->Y. Finally, we compare these paths to find the shortest one and tell Carl where to go.

Ran around with a clown mask before it was cool

dcfedor's picture

I'm thinking I'll probably start with single doors as a proof-of-concept, and consider double-doors later. It's possible that there is no practical difference between two single doors and a double door.

For example, if all doors close and lock if there is a pressure difference across them, then two single doors will still behave as your double door would. You'd just have to have some controls in the room between the doors to adjust local pressure, and when enough pressure changed to match one of the rooms on the other side of either door, that door would open (or at least unlock).

As for indicator lights, I think the original idea of just red or green may be best. Simpler is better, especially when it comes to emergency equipment. Green means "safe" and "unlocked," and only happens if the room you're in, and the other room are both pressurized. Any other situation and it's red and locked.

As for pathfinding, you're a step ahead of me :)

I'm hoping there's a way for me to just use the existing tile-based heatmap to navigate from A to B. I might be able to just add some arbitrary weight to any tile with a closed door to account for the extra time spent opening it. This way, paths using doors would inherently be more expensive than paths through open doors.

Of course, doors can close mid-trip, and that's where things get tricky. Might have to add code to increase a tile's value if the door closes, and force AI to recalculate a path heatmap.

But yeah, way ahead of me :)

Dan Fedor - Founder, Blue Bottle Games