Equipment UIs, and Business Stuff

Hey Folks! Short dev day today as I had to take care of some business banking stuff. But I think I've figured out where to "jam" next: equipment UIs.

Part of the experience I want to give players in this space prototype is the joy of flipping switches and turning knobs that actually mean something in the game world. I want them to enjoy examining the controls like the owner of a new car, and design/choose ships based on their "feel," and not just stats. Manual override on an airlock is actually by the airlock, not some translucent menu floating in one's field of view. And like Ripley in Alien, if you're going to self-destruct a mobile factory, you'll have to navigate the annoying self-destruct sequence through a series of failsafes, not just through a cascading on-screen menu.

For this to work, AI is going to have to be able to raise a UI when interacting with an object. E.g. if it goes to the ship's helm, it'll show the helm controls. If they approach the navigation console, they'll see the System map, orbital projections, and possibly RADAR/LADAR readings.

To work towards this, I setup a simple bar meter UI to see if I could attach it to the battery to monitor charge. And without too much effort, that's up and running. It's hooked up to a debug hotkey, and has lots of hard-coded values, but it works.

The next step is to find a way to launch the GUI when the AI reaches a control panel. And I'm thinking this will be in the interaction system. I.e. the interaction should have an optional UI it raises while running, and that UI closes when the AI finishes the interaction.

This raises a few questions, though. For one thing, what's the AI doing when using the UI? Can the AI bail out before the user is done with the UI? What if the user switches AIs?

Also, how will UI layouts and data-mapping work? If I want a UI to monitor temperatures around the ship, how to I define all the gauges' positions on-screen, their data sources, and what various buttons and knobs do when clicked? Making stuff data-driven isn't too hard, but what data format to use so it doesn't get too complex is a harder question. Especially for something like this. Which is complex :)

Anyway, that's where I'm headed next. I'll start simple, and hopefully some patterns will emerge that show me how to solidify the system. More on that later!

Comments

Flubberj's picture
Flubberj

I will admit that I'm practically useless in regards to coding, but I will say I do very much enjoy reading these dev blogs whenever I get the chance. I would presume the AI would freeze or be "tending the controls" while the player is reading the UI and most likely wouldn't be able to disengage unless something drastic happened like a fire. If the player switched AIs the AI tending the controls would simply walk away and tend to other matters.

I am that low life scum that hunts down a scavenger, laughs as he tries to surrender, beats him to death with my club, and eats his gummy bears before moving onto the next sucker.

dcfedor's picture
dcfedor

Yeah, that's the deciding factor I need to sort out. Emergencies certainly qualify. And abandoning control of an AI should release them, as you point out.

The other question is about hunger, thirst, cold, etc. At what level of discomfort will an AI disengage?

Of course, there's always the possibility of just pausing the game while using a UI. And unless I can think of a reason not to, that may be easiest.

Dan Fedor - Founder, Blue Bottle Games

Rovlad's picture
Rovlad

Good point. Maybe you could also include pausing at user's discretion, or even auto-pause, akin to Infinity Engine games (AI gets dangerously low on comfort, takes damage, etc. You could also center the camera view on the crew member who triggered the autopause as well)?
That last one would probably only make sense if you're controlling everyone (if partially indirectly), not a single "commanding officer" character though, but I've been under the impression that's going to be the case anyway.

dcfedor's picture
dcfedor

Yeah, the auto-pause is a good suggestion. Then, even if I allow AIs to disengage on their own initiative, the game can pause and alert the player before they do.

Your other point about direct control vs. indirect commanding officer is something I'm still struggling with. I still like the idea of an indirect control over AI, possibly just the captain. But I don't know if that will be fun before I try it, so I'm leaving options on the table for more granular control.

I think a lot will depend on how well the AI handles important tasks, and how interesting they are to watch autonomously. If I fail at both, the fallback plan is to manually control them with some automation for convenience. It's possible micromanagement is still fun when you're jumping between AIs for the more important stuff (firefighting, docking) and letting them handle the small stuff (sleeping, eating).

Dan Fedor - Founder, Blue Bottle Games

Malacodor's picture
Malacodor

The first crewman who leaves a console while I'm trying to use it will be floated. And if someone refuses to push a life-saving button because they have to pee I'll beat them to death with a spoon, after locking the toilet of course. What I want to say is that AI behaviour is a delicate problem that can easily anger players. For now auto-pause is perfectly fine. Later you could force AIs to stay at consoles for at least 10 seconds and 5 seconds after the last click, for example.

Ran around with a clown mask before it was cool

dcfedor's picture
dcfedor

I agree, though if the AI stays at the console past the "point of no return" on some vital stat, that will also anger the player :)

E.g. it takes 20 seconds to walk to the kitchen and eat food, and the AI is 30 seconds from perishing of hunger. If the AI is at the station more than 10 seconds, it's a death sentence. In rare cases, this is desired (like Spock in the reactor), but usually this will annoy the player.

As you're both suggesting, pause may be our friend here :)

Dan Fedor - Founder, Blue Bottle Games

Malacodor's picture
Malacodor

Immedate life threats should be announced by impossible to overlook warning signs. If a player ignores that it's their fault. On the other hand many players seem to be used to being patronized these days. Maybe it's best to let the player decide how independent the AIs should act. I mostly played The Sims with AIs off since I found them too stupid.

If you want to test how it feels to have a directly controlled captain (or to do wiring) you could play Wayward Terran Frontier.

Ran around with a clown mask before it was cool

dcfedor's picture
dcfedor

I really do need to try WTF one of these days. It's enough of an overlap that I could legitimately play it for research, if not also for fun :)

Dan Fedor - Founder, Blue Bottle Games

Anase Skyrider's picture
Anase Skyrider

(This comment has felt really clunky, and I've been constantly rewording and rewording it, and I'm bored of that. So I've removed all the crap. Here's the simple version:)

I'd prefer to be the captain of the ship, as my character, instead of as the floating disembodied intelligence that puppeteers everything.

I like this because it allows the game to take some control away from you for its hardcore difficulty and rogue-like themes. One of your crewmembers is acting up? You can't just control him and then not interact with the crew to avoid making things worse. You have to go around managing your people, but they're still strong independent crew members who don't need no captain. And if walking around to communicate with your crew realistically in order to do things like tell them to get back to work, or to do some other job (or to move to XYZ position in combat) is a pain, then a possible solution is to build different kinds of communication, and include radio in that list (but perhaps make it into equipment you have to build or scavenge).

Which, in a short tangent, might be neat in combat. You can yell your orders, revealing your position, or whisper quietly into the radio (or whisper when next to each other). Mechanically, it's neat. Implementation might be awkward, though.

I dunno how the game is planning on feeling exactly, though. You could have a main character, but still be free to move your view all-about like in the first NEO Scavenger. Or your camera is fixed to your character, and so what you can control, and where you can order your crew to move, would be limited to your view. And maybe you can or cannot switch to controlling (and thus recentering the camera) one of your crew... but you're still the captain. Stuff like that. There's a lot of potential variation and room for changes. But all in all, I'd like to see a main-character-esque thing attempted, and things be built around that based on what's fun and what serves what you're going for.

dcfedor's picture
dcfedor

I like the captain-only idea for similar reasons to the ones you state. It feels like it could be the coolest role-playing experience of all options.

I think what concerns me is the AI aspect of the rest of the crew. E.g. if an incident comes up where the mechanic has to jury-rig a system, or the pilot has to man a control panel, will I be able to make the AI do these things better than (or even comparable to) a human? Particularly if my UIs are very button-and-knob-centric.

An even more specific example, to help illustrate. (And this is pretty off-the-cuff, so bear with me.) Suppose your main thruster is shot, and any thrust you can generate retrograde will help you deorbit until you can airbrake into a crash landing on a planet.

A dumb AI would immediately try to solve the problem by increasing thrust on the main thruster. (No effect. Thruster's broken.)
A less-dumb AI might realize the thruster's dead, and start repairs on it. (Too slow.)
A smarter AI might repurpose monopropellant maneuver jets to create translational thrust. (Helpful.)
A really resourceful AI might rig a decompression or explosion on the leading side of the ship to impart retrograde impulse. (Helpful, particularly after monopropellants are expended.)

Without writing very specific state detection and resolution matrices for every possibility, AI is going to let down the player in critical situations. Indeed, the very situations that make for suspenseful action in a sci-fi show would be insurmountable with my AI in charge of saving the day :)

Dan Fedor - Founder, Blue Bottle Games

Anase Skyrider's picture
Anase Skyrider

This is why I've been tossing around the idea of being able to order your crew to do stuff. But to be able to get them to perform complex actions would obviously be a pain in the ass to develop. At that point, the game turns into an RTS but with a champion. Which might be fun and just plain more practical.

And here's a thought to mull over: If you're playing as a captain main character and stuff, what happens when you die? Game over? Well, this is the future. What if you have some pretty rad healing technology. Like let's say you're not dead, but you take the type of injury that another crew member could heal from, but it incapacitates them from battle. So you're not allowed to be saved by this tech because artificial difficulty? Then I guess you gotta cross your fingers and hope your AI can solve shit. Or maybe you temporarily take control of another crew member in order to get shit done, rescue you, and then you take back control. Or maybe while you're passed out, you can still command them in a kind of RTS way without taking control.

There's so many possibilities for control schemes for the player and other AI; you've got a lot of options to explore. Like is it gonna be point and click? If it's real time, then point and click would be the worst possible way to control this on a PC (and probably impractical on a controller, but at that point it's not point and click, it's just running with a joystick, so you might as well use WASD on a keyboard). Or is it gonna control like a top-down shooter (I'm sure you know how that controls; I don't need to describe it). And how is that gonna work with tile-based stuff? Is this even real-time, or is it turn based? Can you pause to plan things out, or are you gonna get fucked and have to think quick in the heat of the moment?

And for that matter, if this is realistic, then what about cover? How is that gonna be handled from a top-down perspective? Because otherwise you either die incredibly easily out in the open, or you have to tank damage like a military shooter.

So I guess that's a lot of food for thought.

You're in "Game Jam Mode", though, so why not pick what you think would be best (if you could get it to work right), and then rough-program the shit out of it like you've been doing? I'm eager to see what's next ^_^

Good luck and happy programming.

dcfedor's picture
dcfedor

Yeah, I think the short version of the answer to this is "just jam it out, and see what feels best in practice." It'll be easiest, I think, to start with manually-controlled tasks for the complicated things (e.g. driving the ship), but let the AI auto-self-care (since they already kinda do).

Then, if this turns out to feel boring or tedious, I can add AI to handle the more complex interactions on top of this basic stuff.

To answer your other questions, the current thinking is point and click to move around, and real time with pause. A super important rule for me in the design is no time pressure on the player, and no manual dexterity pressure either. So the player should be able to sit back and relax while playing, savoring each moment as long as they want. No twitch controls, no dodging, no fumbling with UI.

So this could mean AI pauses the game when important decision points are reached (e.g. evasive maneuvers, fire suppression, etc.).

But yeah, back to the original point: whatever feels "best" :)

Dan Fedor - Founder, Blue Bottle Games