Npc Accuracy - And Simulation Consistency - Next Steps

[BrazilianJoe]

It is great to see the developments on npc accuracy:

 

https://forums.warframe.com/index.php?/topic/395422-npc-accuracy/

 

But there's more to be done. 

 

There is still a discrepancy due to client-host lag where enemies still shoot behind the clients. 

 

I think that the AI logic and host-client logic should follow a more advanced and distributed model. 

 

The game should store telemetry data automatically and estimate from past history who should be the best host. 

It should not just be based on theoretical values  - upstream and downstream - but actual measurements taken during game time. Occasionaly the game should send a "ping?pong!" in the flurry of the mission data communication to measure actual latency for example. The data would be used to estimate the best host in the subsequent missions. 

 

The host would have to gain delegating logic, so that it can quickly tell all clients who will provide certain information. 

This kind of delegation wouldn't be fixed at the mission start. Instead, it would be changing all the time depending on game state.

 

This delegation would have the added advantage of distributing the host load, easing even mode the pressure on upstream, which is usually 10% of the downstream speed. 

 

I will suggest a few algorithms, maybe none of them are the best for the job, but they should at least provide inspiration. 

 

MASTER HOST AND DELEGATED HOST (MH and DH)

 

What is currently the HOST will become the MASTER HOST. Occasionally the host may decide, depending on a few aspects of the game state, that a client should take a few hosting duties for a small portion of the simulation. Upon making this decision, the MASTER HOST would broadcast a message stating that client X would be a DELEGATED HOST for very specific parts of the simulation.

 

All clients receive this message and will treat incoming broadcasts from the DH as authoritative about the game simulation state, but any conflicting message from the MH will override it. 

 

The MH will accept messages from the DH as being authoritative, but changes in simulation state may obsolete the priority of a DH's duties, causing the MH to take those aspects for itself or moving them right to another client as a different DH. 

 

USING MH AND DH IN PRACTICE:

 

The game state will start with all duties performed by the MH.

 

As the game progresses, the MH will delegate certain specific statistics to be managed by some of the clients, having them behave as DH. Most of these will comprise two aspects of enemy state: Targeting AI and health/status state.

 

ASPECTS TO BE DELEGATED:

 

ENEMY SPAWN

 

 

As new enemies come into play they could start by default by being DH'ed by the player closest to it. This can have updates to the spawning logic to have unambiguous presets, so that it has as close to zero as possible overhead to set the DH.

 

WHY? Because the AI is more likely to target the closest player. 

 

 

WHAT IS DELEGATED: 

 

The client will be told to run authoritatively that AI's logic, and broadcast that single enemy behaviour to everyone else, as if being the host. 

Enemy AI's decisions will be calculated with local precision and zero lag. 

A player closest to the enemy should be DH to the enemy's health/status. Player's melee should have an immediate effect on the enemy. 

If the AI switches targets to another player, the targeting aspect of the AI will be moved to that player's computer.

It should be possible to have a single mob with targeting+accuracy being DH'ed by one player, and health/statuses being DH'ed by another player. 

 

TRIGGERING MIGRATION

 

If an enemy AI switches targeting for any reason from the current DH's warframe, the MH will switch the AI management to the computer of the player being targeted, to maintain locality of accuracy calculation. 

 

 

If the enemy changes locality  to be closer to another player, or another player moves closer to it, the health/status would switch to the player closest to it. 

The health/status switch must have tolerance levels to prevent ping/pong racey states where the DH switches back and forth too fast. 

 

The DH cannot directly transfer its authority to another client. It can say "Target X is closer to player Y" or "Target X is targeting player Y", and the MH will then quickly order the DH change for the aspect according to the case. 

 

 

HIDING LAG

 

 

The messages from the DH about enemy shots will be sent in coordinates relative to the target, not in absolute space. If a bullet passes 1m behind a player, the message will convey that, and each client will make a visual representation by itself.

As a consequence, even if the Warframe is in the wrong position because of lag, the shots will still display the same accuracy everywhere. 

 

Destructibles - Only the DH will be able to tell whether a destructible is indeed destroyed by an AI's stray shot. Destructibles have "undefined resistance" and can "resist shots", in terms that a non-DH may have a simulation state that could mean "destroy that crate because of bombard shot"; But since it didn't receive the DH's message to blow that crate, the crate does not blow. I call it a "resilience rule" as a model for the game simulation/logic, and helps keeping consistency across the players. 

 

Area effects - Area effects will have SHRAPNEL. In short, Shrapnel is little more than a COSMETIC EFFECT to justify applying an effect (damage or buff/debuff) to a target which the local simulation (non-DH) thinks is outside range, but the DH or MH says it's in range. 

 

Shrapnel are fragments which "cause" the exact same effects of the area effect to one specific target. Shrapnel may fly beyond the official effect area. Shrapnel does not happen spontaneously. It is only triggered on very specific conditions to hide lag: 

- DH says that Target X was damaged/effected by Area Effect A

- There is discrepancy between player or enemy position between different DHs, or ot the MH.

- Non-DH receives the message from the DH, but its simulation says that Target X would be outside Area Effect A.

- The Non-DH simulation solves it by generating a shrapnel which "hits" Target X, for the sole purpose of agreeing with the DH. 

 

Shrapnel can be represented as flying chunks of smoldering metal, sparks, light beams or any other particle effect visually fitting to the area effect in question. 

 

The game will generate "shrapnel duds" which are cosmetic-only - in varying amounts depending on particle effects quality setting - shooting at directions where there are no targets like the ceiling or walls, to complement the visual consistency. There is no visual difference between "true shrapnel" and "shrapnel duds". They are there just for the sake of visual feedback, consistency and good looks. 

 

SECOND WIND

 

Second Wind should apply to enemies only. If a Non-DH player's damage would cause an enemy to die, but another enemy's healing effect saves it, the enemy should get a second wind. Second Wind is also a way to hide lag, much like shrapnel. A non-DH may initially believe that an enemy is dead, but the DH say "it still has X hp". The non-DH will bow to the DH and decide the unit must be brought back, triggering a "Second Wind" on the enemy. 

 

 

 

-----

 

 

There might be more to it, more advanced models to use, but I hope these work as good starting points to more brainstorming. 

 

 

 

 

[taiiat]

sounds interesting, though most of it seems to be targeted at something other than Enemy Accuracy. mainly laggy Hosts.

as for Enemy Accuracy, do something simple like making Enemies ~20% less Accurate towards Hosts, add 'fakelag' to Hosts (of about 30ms), or something like that.

Clients have fairly intuitive opportunities to dodge incoming fire. Hosts, not so much. it's better, but Clients still feel like 'Ninjas' while Hosts feel like half a Ninja.

a small adjustment that applies to Hosts only should level the field and make it pretty consistent for everyone. so everyone gets the same opportunities to play skillfully.

(as i don't feel very skillful about being picked for Hosting ('my turn to Host'), and knowing that i need to pick a Warframe that can carry itself because i'm going to be getting hit by just about all of the Enemy Fire no matter what i do about it. not that great of a feeling to know that i either choose a Warframe that maybe i'm not in the mood for Playing, or get Revived several times during the Mission from unavoidable Damage that the Clients can intuitively avoid).

[BrazilianJoe]

sounds interesting, though most of it seems to be targeted at something other than Enemy Accuracy. mainly laggy Hosts.

as for Enemy Accuracy, do something simple like making Enemies ~20% less Accurate towards Hosts, add 'fakelag' to Hosts (of about 30ms), or something like that.

Clients have fairly intuitive opportunities to dodge incoming fire. Hosts, not so much. it's better, but Clients still feel like 'Ninjas' while Hosts feel like half a Ninja.

a small adjustment that applies to Hosts only should level the field and make it pretty consistent for everyone. so everyone gets the same opportunities to play skillfully.

(as i don't feel very skillful about being picked for Hosting ('my turn to Host'), and knowing that i need to pick a Warframe that can carry itself because i'm going to be getting hit by just about all of the Enemy Fire no matter what i do about it. not that great of a feeling to know that i either choose a Warframe that maybe i'm not in the mood for Playing, or get Revived several times during the Mission from unavoidable Damage that the Clients can intuitively avoid).

 

Haven't though about fakelag before, wouldn't it be too cheaty? On first look it seems to be a debuff to the lowest common denominator, an does not solve the underlying issue.

 

But it may actually have a reasonable effect in practice. I won't rule it out, but only testing in practice can tell how good it would be. 

 

And the sharing of upstream across players could have a dramatic effect on reducing upstream pressure. Perhaps even enough to further increase player count. 

Edited February 8, 2015 by BrazilianJoe

[taiiat]

Haven't though about fakelag before, wouldn't it be too cheaty?

And the sharing of upstream across players could have a dramatic effect on reducing upstream pressure. Perhaps even enough to further increase player count. 

it's not much different than the Latency that Clients have. adding fake Latency for the Host's position (which should be what causes Enemies to be less accurate to them) should be about the same as the real Latency that the Clients already experience.

'shared Hosting' sounds plausible i suppose...

don't really have much else to say about that. just note that you run into more potential Latency issues in that manner.

[BrazilianJoe]

it's not much different than the Latency that Clients have. adding fake Latency for the Host's position (which should be what causes Enemies to be less accurate to them) should be about the same as the real Latency that the Clients already experience.

'shared Hosting' sounds plausible i suppose...

don't really have much else to say about that. just note that you run into more potential Latency issues in that manner.

 

Yeah it may mask the discrepancy somewhat, but there would still be uneven results across different machine running the same game. It could be a "good enough" solution if there are more solutions combined with it to reconcile simulation differences. 

 

It's just a different approach to what I am suggesting, and my solutions don't really conflict with this idea.