The Oolite NPC ecosystem (and other questions)

[JazHaz]

How about something like Restricted-<type>, where only ships of a certain defined class go to?

Yes. It might be sufficient to have simply "Restricted", which by default all ships actively avoid

Ooh! I would then have a Restricted station plonked down in the middle of the main space lane, and sit back and watch the chaos!

[Tricky]

How about something like Restricted-<type>, where only ships of a certain defined class go to?

Yes. It might be sufficient to have simply "Restricted", which by default all ships actively avoid

Ooh! I would then have a Restricted station plonked down in the middle of the main space lane, and sit back and watch the chaos!

What, like a Death Star? Been meaning to texture that weapon (emmission maps).

[Norby]

Towing them back as salvage is a possibility

Now it is possible with the Towbar OXP, thank you for the idea!

[cim]

What do you think of this classification for stations?

This is now in with the suggested amendments. One further change: "Neutral" stations positioned within the main station aegis default to "Galcop" instead, to stop smugglers who've too much bounty to feel safe going to the main station picking something like a Superhub or Casino station right next door.

Some more questions that are coming up from trying to get the whole thing to work, to do with allowing the AI to assess the player's behaviour in a way that it can do very easily for other AIs.

First one: detecting fleeing. For AI vs AI this is easy: the AI can just check if its target is in a fleeing AI state. For the player it's a lot trickier. For easy testing purposes I'm using "weapons online" as the test: if the player takes their weapons offline, they're considered to be fleeing. It won't work as it is for release, though. Options so far considered.

1) Weapons offline. Too easy to exploit by setting weapons offline, then turning it back on to attack.
1a) That, but add a 15-second warmup before you can bring weapons back online. Still a bit exploitable if you were just going to use those seconds to let your lasers cool anyway, and any longer a reactivation time is going to get seriously irritating.
1b) That, but have the game track if the player exploits it, and stop believing the player signalling surrender this way if they do. We'd have to be quite careful with the expiry time: how long before it stops being dishonourable behaviour in one encounter, and is just a separate fight? Another problem: we don't want the player to get one "free" fake-surrender against every ship/group they meet, which implies some sort of magic global honour tracking for them.

2) Explicit sending of an "I surrender" message (which they may or may not trust, of course!). Major drawback I can see is the need to implement player-to-NPC comms in the core game, find keys for it, etc. which we've not needed up to now.

3) Some sort of heuristic based on time since last shot, relative speed, facing, etc. Disadvantages: could be inefficient to calculate, and once the player has military lasers, injecting away from a fight while not firing might be surrendering or might be backing off to shoot from outside of the AI's range.

4) Cargo dumping as means of surrender. The problem is that quite a few ships which will accept a surrender (e.g. traders) don't have any interest in collecting more cargo, so it only really works for surrendering to pirates. Also, the Asp is a playable ship.

[JazHaz]

First one: detecting fleeing. For AI vs AI this is easy: the AI can just check if its target is in a fleeing AI state. For the player it's a lot trickier. For easy testing purposes I'm using "weapons online" as the test: if the player takes their weapons offline, they're considered to be fleeing.

Hmmm. Not sure about this. I've never used the weapons toggle. What does it do, does it make recharges happen quicker whilst weapons are off?

[cim]

I've never used the weapons toggle. What does it do, does it make recharges happen quicker whilst weapons are off?

All it does is disable your weapon systems. The only current benefit to it is that you won't accidentally fire them at the wrong time, e.g. while docking.

[Cody]

... but add a 15-second warmup before you can bring weapons back online.

I rather like that idea, but as you say, it'd probably need to be longer, which would become irksome.

[Cody]

Could the warm-up be made suitably longer, but get instantly reset if the player takes a hit?
Just seen your next post - a good idea, is that.

[cim]

... but add a 15-second warmup before you can bring weapons back online.

I rather like that idea, but as you say, it'd probably need to be longer, which would become irksome.

It's just occurred to me that it wouldn't need to be longer if the period in which your weapons were warming back up was counted as "not fleeing" by the AIs (with perhaps a playerIsArmingWeapons event to warn them). Then you'd potentially get 15 seconds of incoming fire to handle and they'd know not to believe your surrender next time.

There are probably still some other disadvantages to managing it this way.

[Tricky]

Maybe calculating the dot product of the player's flight vector compared to the NPC. Couple it with the time spent flying away from the NPC and not using the aft laser.

[Disembodied]

Maybe calculating the dot product of the player's flight vector compared to the NPC. Couple it with the time spent flying away from the NPC and not using the aft laser.

I'd include not using any lasers or pylon-mounted weapons in there, too. Obviously you'd want to deal with laser temperature, to prevent players withdrawing to allow their lasers to cool being misread as fleeing. Can the NPCs judge player laser temperature? If the player has cold lasers, is redlining their engines, and is positioned so that the NPC is consistently within a cone centred on the player's stern*, for X (15?) seconds, the AI could read that as "fleeing". The AI should definitely have a low tolerance for fleeing, though: if the player returns to the fray, then the AI won't believe them if they try to flee a second time.

* Perhaps defined as: the NPC would be visible in the player's rear view?

[cim]

Can the NPCs judge player laser temperature?

Yes.

If the player has cold lasers, is redlining their engines, and is positioned so that the NPC is consistently within a cone centred on the player's stern*, for X (15?) seconds, the AI could read that as "fleeing".

That's probably an accurate indicator of fleeing, but I suspect would miss far too many genuine cases. It takes a bit over 30 seconds for lasers to cool completely from the thermal cutout point. Running for another 15 seconds after that means that from deciding you're outnumbered to them actually letting you go would take most of a minute. (The cone restriction also seriously limits the evasive manouevres you can use if there's more than one or two of them, and doesn't help at all if you've been pincered by two groups)

As another point: I'd much prefer a solution which allowed for a snap decision based on what the player's current state was, because the NPC is only going to proactively check it every 5 seconds, and because you might have a situation where:
P = player, T = trader, A1-3 = grouped pirates.

• A1-3 attack T.
• P attacks A2; A2 breaks off the attack on T and opens fire on P.
• A1 and A3 continue the attack on T but list P as an enemy target.
• P takes heavy damage from A2 and flees.
• A2 notes the fleeing, and returns to shooting at T as the currently more dangerous of the two.
• T surrenders and dumps cargo, switching the pirates to "repel target" mode: i.e. finish off the current fight so they can scoop it up. A1-3 will remove T from their target list at this point.

At this point, unless A1-3 can instantly recognise P as fleeing - and remember, two of them haven't really been tracking P's behaviour at all to this point - they'll switch to attacking P. (Worse, A2 is likely to then pick up "Ah, my allies have a combat target - I'd better help them" and start going after P as well)

It's not impossible to avoid this, but it is more difficult, and also potentially inefficient.

[Disembodied]

I'd much prefer a solution which allowed for a snap decision based on what the player's current state was, because the NPC is only going to proactively check it every 5 seconds [...]

Yes, I see what you mean - I hadn't really thought about multiple enemies, either. I'm wary of the idea of the player having to signal their status via putting the weapons into safe mode, though, if only because it's one more thing (and a slightly unnatural thing) for the player to have to do in an emergency situation (although the proposed rearming delay could make things interesting).

How about a check which looks at whether 1) the player is further away than they were before, and 2) how long has it been since the player fired a weapon? Maybe if the player passes six successive checks - each time they're further away, and still haven't fired any weapon - then they're deemed to be fleeing. It's not a snap decision, of course, but an accumulation of states, which would require tracking, so that might kill it as a solution.

Even if it's workable, it still doesn't cover being pincered by two groups (although the player could always flee away from both groups) - but maybe when the player is seriously outnumbered, then perhaps the attacking NPCs might be less inclined to let them flee, anyway.

It also doesn't cover situations where the player is slower than the NPCs - although in the core game, with the player in a Cobra III, that shouldn't occur very often. But even if the player is flying (say) a Cobra I, without injectors, there are other factors to bear in mind: the main one being, it's just harder to flee in a slow ship. If you can't put more distance between you and your pursuer, then your pursuer is simply less likely to let you go (for escorts/pack members, though, there could be a maximum distance they're prepared to travel away from their mother/leader).

There are also different types of hostile NPCs. The player can signal surrender to a pirate, by dropping cargo (and not returning fire, too, probably). For traders, it might be more difficult - but they tend to be slower, so the player should be able to run away from them (or, in the case of escorts, from the mothership). Police and bounty-hunters might just be more determined to make the kill, and so harder to flee from.

[cim]

I'd much prefer a solution which allowed for a snap decision based on what the player's current state was, because the NPC is only going to proactively check it every 5 seconds [...]

Maybe if the player passes six successive checks - each time they're further away, and still haven't fired any weapon - then they're deemed to be fleeing. It's not a snap decision, of course, but an accumulation of states, which would require tracking, so that might kill it as a solution.

That's still - assuming the NPCs aren't being interrupted by high priority events, which they probably won't be if the player isn't firing back - 25-30 seconds of fleeing before it gets acknowledged. They'll probably be dead by then...

An NPC which decides to flee gets that acknowledged within a few seconds. The player really needs the same sort of speed of response, if possible.

There are also different types of hostile NPCs. The player can signal surrender to a pirate, by dropping cargo (and not returning fire, too, probably). For traders, it might be more difficult - but they tend to be slower, so the player should be able to run away from them (or, in the case of escorts, from the mothership). Police and bounty-hunters might just be more determined to make the kill, and so harder to flee from.

Essentially there are two combat attack commands: "destroy" and "repel". Destroy fires on the target until it explodes, repel until it runs away.

Traders get "repel" (no sense in making a fleeing target desperate enough to fire a missile, for instance).
Hunters and police get "destroy" (no bounty otherwise / the offender can return)
Pirates start on "destroy" (don't let the traders escape) but switch to "repel" once enough cargo is dropped (acknowledge surrender, and just make sure any bounty hunters or escorts hanging around get chased off)
Escorts start on "repel" focused on ships attacking their mothership, but switch to a "destroy" attack on their mothership's target.

Both behaviours need to be able to identify fleeing ships quickly: "repel" because they accept surrenders, and "destroy" because if they're chasing a fleeing ship and someone else attacks them or a group member asks for help, that needs a higher priority.

[Disembodied]

That's still - assuming the NPCs aren't being interrupted by high priority events, which they probably won't be if the player isn't firing back - 25-30 seconds of fleeing before it gets acknowledged. They'll probably be dead by then...

An NPC which decides to flee gets that acknowledged within a few seconds. The player really needs the same sort of speed of response, if possible.

Hmm ... without a direct, active signal from the player, then, there would be no way to differentiate between the player actually fleeing, and the player just jinking momentarily away from combat to gain distance/allow their lasers to cool. Which seems a shame - it would be good if the NPCs could read the situation, rather than having to rely on an overt cue. Although I appreciate that this is much harder to do!

That said, the time factor really depends on what causes the player to flee. I've run away from fights before without being on the ragged edge of disaster - just knowing that I was outnumbered and outgunned. If a player is so deep in trouble that five more seconds of combat is likely to kill them, then is it not possibly already too late for them to try to run away? If 25-30 seconds was too long, perhaps the number of "tests" could be reduced, to four or three? Something like this - where the AI is responding to player behaviour - is I think definitely a situation where there isn't such a need for the game to be equal in how it treats players and NPCs.

Essentially there are two combat attack commands: "destroy" and "repel". Destroy fires on the target until it explodes, repel until it runs away.

This sounds really good, and should create a variety of "intelligent" behaviours! It makes me hope even more that this intelligence can be fitted seamlessly across the game.

Maybe I'm making a mistake in thinking that it's necessary for the AI to log and compare player action over time, though ... Would it be possible to use the difference between "destroy" and "repel" to determine player "fleeing"? If NPCs are in "repel" mode, perhaps they can look for a bunch of metrics from the player on the assumption that these will equal a ship that's on the run (or at least should be - players who get into this state, and DON'T run, probably won't survive if they keep on fighting):

• laser temperature (say, below 75%?)
• speed (full speed/in the red)
• pitch (within a small degree of level)
• shields (at least one of them low/down)
• heading (within the arc of "away").

If the player ship passes this multi-variable test, then a ship in "repel" mode could treat them as fleeing. A ship in "destroy" mode, though, needs an overt signal: dropping cargo for pirates, powering down weapons for police.