Back On That Horse

Hey Folks! Feeling a bit better about things today. I think yesterday's realizations got the better of me, and I ended up feeling really discouraged. But some time to (not) think about it has given me perspective, and many of you had some very helpful suggestions and encouragement (thank you!). I think where I am today is a bit healthier.

And, importantly, ready to press on.

I still think this project has a load of problems and risks, many of which are going to require paying-off technical debt down the road. But the most important part, the gameplay, seems like it can still work. And if I can get that to a point where it can be demoed to others and generate excitement, that buys me more time.

So with that renewed hope, I tackled many of the smaller things that ate at my confidence yesterday, and started forging ahead with new work, as well.

First of all, in debugging the broken sleep system, I noticed it was due to a feature I removed from conditions a while ago. There was a whole field that mostly was redundant with other features, and I yanked it from the code. Unfortunately, I missed the case where it was still being used (sleep cycles), and that caused AI to sleep incorrectly (or more often, not at all).

I re-tooled sleeping to use the remaining systems, removed a lot of the confusing old data it used, and also cleaned all remaining references to that now-gone feature. Sleeping works again! Also, as an added bonus, I added the necessary data to allow players to sleep via context menu on a bed.

Next, I dove into the air pump and sensor code to try and patch-up the holes in that system. While testing a longer flight yesterday, the pumps just stopped. The sensors were still in the alarm state (which triggers pumping), but the pumps didn't care.

This was probably due to the way signals are consumed by objects listening to them. Somehow, the signal was consumed and no longer reappeared when I was fast-forwarding. So to avoid this happening again, I changed pumps to no longer consume signals, but just look for them. This means that as long as the alarm is on, the pump sees "alarm" signal, and pumps normally.

And, as an added bonus, this means multiple pumps can now point to the same alarm without interrupting each other. A bug I had hoped to solve eventually. Also, I made a slight improvement to the pump/respire code to account for said fast-forwarding, since it previously drew the same amount of gas each "tick" regardless of the time since last tick. I.e. pumps/human breathing needs now act proportionally when time dilates or fast-forwards.

Next up, UI changes to make it feel more like a game.

The first big one is to add human-readable titles to each interaction, and use those in the context menu. Now, instead of "SeekFriendship" we have "Reminisce." Instead of "SeekIntimacy," we have "Invite for Drink." And instead of "SeekSleepN1" on a bed, you "Use" it.

I think this has an immediate benefit of seeming more like you're dealing with a game. The language used in the commands is more natural, and like tools at your disposal instead of debug messages. And while I was in here, I fixed a couple of issues with the fridge. Including a missing context menu to grab food from it, and the ability for AI to magically access food from it while across the ship.

Finally, I spruced-up the log messages. Now, they have color-coding similar to NEO Scavenger, so it breaks up the sea of white text scrolling by. Green means a good thing happened to the AI, orange is bad, and white is neutral. Things we do, and stuff happening to us is left-aligned. Stuff from other AIs and items is right-aligned, and dimmed.

As you can see in the screenshot, it's a bit easier to parse at-a-glance what is happening. Some good things, some bad things, and some informational things. All easier to scan quickly than before.

Each of these is fairly minor, but as a whole, I think they smoothed over a lot of the experience. As for what's next, I'm thinking of taking a few of the suggestions on yesterday's post and seeing what I can do with those. Namely, can we do repairs? Random item wear and damage? Dirt and cleaning? I think having damaged/dirty states for items is doable pretty easily, just by adding mode switches to them like I already do for open/closed doors and on/off pumps.

However, repairs might be trickier to do. Magical repairing should be easy (just more interactions with mode switches as rewards). I could maybe even filter out AIs based on their skills (no repairs or higher chance of failure if lacking skill).

But if I want to make things like replacing a whole O2 tank with a new one, that's harder. How does AI move big things around? Where do they get them? How are they re-installed?

Also, what about tools? At some point, I'd like items to be like in NEO Scavenger, where equipping vs. possessing items bestows certain flags. E.g. possessing a blowtorch enables patching the hull. But no such system exists in this engine yet. So that could be a lot of work. Might just be worth doing the magic repairs as a first test.

Anyway, glad to say today has been a significant improvement over yesterday's emotional quagmire. Thanks again to everyone who offered suggestions and encouragement. It really helped!

Tags: Ostranauts


ra1's picture

Are you considering porting over (parts of) your NS game engine to handle some of this?

Malacodor's picture

About repairing - don't overthink it. Just let someone fumble around with a tool for a while. Limit moving around stuff to build mode and limit build mode to shipyards.

Instead of simply repairing whatever system starts smoking, have us do a diagnosis first. For example, if the oxygen level is too low, we have to check O2 sensors, cables, pumps, tanks and pipes to find the malfunctioning part. After finding and fixing a problem a check is needed if the problem is completely fixed. Maybe a malfuncion in one spot broke something else that has to be repaired as well.

Make different versions of systems. Some are cheap but break often, some are good but overprized and you have to find the best compromise between affordability and quality. This can also lead to social conflict. If you buy the expensive stuff the crew gets jealous and demands higher wages. If they have to repair the same part over and over again they get angry at the captain for buying such cheap shit.

Give systems and parts a hidden quality stat, which equals the official quality most of the time, but sometimes low quality parts are sold as high quality ones. Then the same system or part breaks way more often than usual and should be replaced. This could also be the reason for a running gag with crewmen making ironic or sarcastic comments about it.

Make systems require regular maintenance to keep the danger of breaking low. This could be another cause for conflict, for example crewmen getting angry about bad timing of toilet maintenance.

Add learning and teaching. To improve skills, the crew has to read textbooks and learns faster if taught by a more experienced crewman, also depending on how much they like each other. Training someone at a specific system sometimes requires shutting it off for a while, so that needs to be planned carefully. If you buy that shiny new engine, the crewmen working with it have to study the manual to operate it at its full potential.

Instead of micromanaging everything or foolishly relying on the AI, let us set up schedules for crew activities similar to sports manager games. Including people getting angry if they have to do significantly more work than others or are put in the same shift as someone they don't like.

Add cooking. Having a real kitchen and someone who is a good cook should significantly increase crew morale on long trips.

To sum it up, keep the crew busy with cleaning, cooking, maintenance, repairing, learning, teaching and other things that might come up.

Ran around with a clown mask before it was cool

ascavone's picture

Nice job getting back on the horse man!

dcfedor's picture

@ra1, definitely. I've already yanked more than a couple code blocks over from NS :) My hope is that I can take what I've learned on NS and incrementally improve it.

Though, in more than one instance, I think I overcompensated. E.g. trying to make a system more moddable, I ended up making it 99% moddable but impossible to understand/maintain. Still working towards a good compromise.

@Malacodor, that's kind of the plan, eventually. At first, a lot of it is getting one or two basic examples of a system working to prove it out. Then gradually refining them and adding to them over time, as-needed. So a lot of what you're describing comes in that later phase of adding variety and more subtle interactions.

That job scheduling suggestion, for example, might be one of the systems needed sooner than later. Even for just a few things like sleeping, eating, and repairs/cleaning.

@ascavone, thanks! I owe more than a little to you guys for reminding me this is worth doing :)

Dan Fedor - Founder, Blue Bottle Games