PV = nRT

Hey Folks! Hope everyone had a good weekend. We visited some friends for the first time since leaving Edmonton, and had a great time eating and playing board games. I think we are all set to do that again sometime soon. We had all but written-off board games since the little one was born. But it appears to be possible to wrangle and play at the same time!

Back on the space frontier, work continues on the room system. Last week, I almost got the rooms hooked-up in such a way that they could talk to each other and exchange their gases when I clicked on the door between them. Of course, it turned out not to be that simple. Clicking on the door did nothing.

Once I sorted that issue out, it opened up a new can of worms. It turns out the rooms didn't actually see each other through the doors because the doors acted like walls until opened. In essence, that's all they were: walls that magically vanished when clicked, so the room detection script didn't notice anything special about them.

I decided to create a new object type: portals. This way, the game could understand the special nature of the door when it encountered them during room calculations. Each room now stores a list of doors it has, and each door lists the rooms it connects. Thus, rooms can check doors for being opened or closed, and simulate gas exchange accordingly.

One problem down. And in fact, this worked pretty well. I was able to get rooms to fill with a gas, and spread it to adjoining rooms when the door between them opened.

However, this didn't account at all for different room sizes. If a supply closet had 1 atmosphere of pressure in it, and it opened into a giant cargo bay with no atmosphere, the closet and bay would end up at about 0.5 atmospheres each. Not really accurate. Plus, I'd like to work temperature in here somehow. Even if it doesn't figure into the gas exchange (which it would), I at least want there to be a danger of freezing to death or overheating if environmental controls fail. And this temperature issue should be able to move into adjoining rooms if there are no sealed doors.

So I've started working on that now. And I've actually got it running! Except, the math is pretty wrong, as it turns out. I have a few calculations in there that cause gas to be spontaneously created and/or destroyed when doors open, and I have to find out where.

That's all for today. See everyone tomorrow!

Comments

Malacodor's picture
Malacodor

Ah, the ideal gas law! But is there even information available about how damaging which temperatures are way below normal atmospheric pressure? I guess the ideal human body temperature might be different then.

I don't think it's necessary to recalculate paths when doors open and close. Firstly, crewmen don't know about the state of doors they don't see. Secondly, doors should automatically close when not in use for safety reasons, so open doors should be rare anyways. Thirdly, you only have to simulate human pathfinding, which isn't perfect and can easily fail in edge cases.

If you want airlocks to automatically adapt their pressure to neighbouring rooms, there has to be a tool for defining rooms as airlocks or some kind of auto-detection. That's the same problem shifted to a different spot. Also, if two rooms have normal pressure and both doors of the airlock between them are open, then a hull breach in one room would evacuate both rooms, which is exactly what airlocks are meant to avoid. Sorry for bugging you with that, but you are the one who wants the game to be realistic. :-b

I thought about a system for tagging tiles, no idea if it makes much sense. Each tile is either tagged as walkable, permanently blocked, temporarily blocked, removable or hostile.
- Walkable are empty tiles or low obstacles like beds or prone crewmen. (no movement cost increase)
- Permanent blocks are obstacles that won't go away anytime soon, like walls, wall-mounted furniture or locked doors. (infinite movement cost)
- Temporary blocks are obstacles that will disappear or change to removable within a short time, like airlock doors or a crewman carrying a load of beer crates. (moderate movement cost increase)
- Removable blocks are obstacles that can be removed quickly, like a closed, unlocked door, a chair or a crewman. (little to no movement cost increase)
- Hostile tiles are tiles that are walkable, but should still be avoided, like fires, contaminated or evacuated rooms, space, rooms with an angry captain/girl friend inside or tentacle monsters. (infinite movement cost or moderate movement cost increase for AIs with an appropriate protection)

Temporary and removable blocks are still treated as impassable, the movement cost increases represent the time that is necessary to wait until an obstacle disappears or the time that is required to remove the obstacle. The basic idea is to avoid that AIs take another path when being blocked by a temporary or removable obstacle if waiting/removing would take less time.

PS: You forgot to mention that NEO Scavenger is on sale on Steam.

Ran around with a clown mask before it was cool

dcfedor's picture
dcfedor

I think there is info on human exposure to extremely low temperatures and pressures. The Air Force and NASA both have a lot of test data on this, and at least the latter is public domain. E.g. hypoxia and pilots, decompression sickness, rapid and explosive decompression, etc.

Yay for NASA! :)

You're right that I may not have to recalculate paths whenever a door changes state. I may just have the AI stop when it realizes a door in its path is closed, and defer the recalc until then.

As for tile tagging, I may need even more states/flags. I've been running into limitations with item/wall placement on the ship due to limited flags, so I may need tiles to have arbitrary lists of flags for things like wall, door, walkable, hot, etc. That may be next, if atmo simulation runs out of quick wins.

As for the NEO Scavenger sale on Steam, I'm not in a hurry to mention it since it's on sale a lot these days. I may do a reminder towards the end of the sale, though. Or when it hits a new low price.

Dan Fedor - Founder, Blue Bottle Games