Hello all,

I am working on a client hosted co-op action game.

Lately I've playing with the AI and I realized that I've missed a critical point:

How do client-hosted games deal with an AI that is spread over multiple scenes?

The current architecture that I have is an authoritative server that one of the clients host, the server runs inside the engine (it can be extracted though), the server has a quad-tree that through it, it queries which clients receive which information.

The main considerations that worry me are:

• A* navigation in a server that doesn't run inside the engine
• Performance (if each client goes to a different map then it means many bots will be spawned and will be handled by a single machine - that also happens to be the machine the is responsible for updating the clients)

Thanks for any idea

@hplus0603

hplus0603 said:
I'm assuming you're using a simulated-server, replicated-clients setup, where object state is replicated from the server. (deterministic lockstep is not typically used for action shooters.)

That is correct I am using client-side prediction to cover position update lags

hplus0603 said:
The entities are then replicated to the clients. As long as you replicate the entity ACTIONS (movement, shooting, interactions with the world,) you don't need to replicate their MOTIVATIONS (the AI algorithm.) The AI entities don't really need to work any differently from other-player entities on a particular client.

If I understand your statement correctly, your point is, having all the AI actions determined by the server and it's results sent to other clients (this is by the way the current algorithm which I use) - and since you haven't mentioned the multi-scene issue, you'd recommend separating the pathfinding from the hosting player's current scene (which I'm currently coupled to)?

Going by this approach (a single server that might manage ~100 bot entities), I assume I should probably implement a mechanism that categorizes bots into update priorities and calculate new behaviors accordingly.

@hplus0603

hplus0603 said:
I don't quite understand the “scene de-coupling” thing.

To clarify, I currently use a built-in pathfinding system that the engine I'm using provides, the downside for the system is: it can only work on agents that exist within the current scene/map.

So the de-couple thing refers to - stop relying on the current scene/map to calculate paths, and have each map's graph and its obstacles handled by custom code that can be virtual (thus agents won't rely anymore on the actual scene they exist in, and can be handled via code like everything else).

@hplus0603

The end goal is to enable remote clients be in a different map than the host player, sort of like Diablo / Borderlands.

@hplus0603

I will clarify the objectives that I'm trying to achieve:

I have 2 main requirements that the AI needs to follow through:

1. Support root animations between client and server - relatively “easy” to achieve will expand on that later
2. Support bot spawning at different maps without the host player along with its “server” component present at said scene - the reason this is currently an issue, is due to the existing code relying on unity's navigation system which in turn requires the Agent to exist in the scene so that it could navigate (which is in absolute contrast to the requirement)

I have thought of 2 options, neither seem to me to be better, so I hope to hear more opinions on the matter:

Option 1#:

The bot instances that are created will be entirely handled by the server - all decisions will take place there, and the results like will be sent to remote clients, similar to the way that player's inputs are handled by the server.

The server bot instance will also play animations/root animations during this time the clients that receive an input will not sync there movement - but play the animation as well and after the animation ends the position sync will be turned on. (I tested it on a few clients and this strategy seem to wok well without much effort)

Pros

• relatively easy to build
• the server bot instance will have better sync with root animations done by the client
• Authoritative
• No network required between a client and server for the decision making part of the AI

Cons

• the server will have visual awareness (animations)
• will make the 2nd requirement very hard to implement

Option 2#:

The 1st client to enter a scene will be the “owner” of said scene, meaning decision making will take place at client side, and the results will be sent to the server. (when that client leaves, 1 of the other clients in that scene will take it's place as the owner of said scene)

Pros

• point 2# won't be as hard to implement
• the server won't be aware of visual related data (animations)
• Easier load on the host player

Cons

• will require each scene owner, to send more traffic to the server
• scene owner lags will affect everyone in that scene
• recovery when a client lags, or exists the map will be hard to implement

@hplus0603

hplus0603 said:
What does the server do with clients that are in “another zone” than the person that is hosting.

Well that's a question I'm trying to find an answer to, I'd prefer the server to be authoritative in this case as well, and that pathfinding would be handled by the server - though I think it will be very hard to implement.

hplus0603 said:
What happens for the players themselves? Is it still server authoritative? Can players in another zone go through walls?

All player inputs should be handled in an authoritative manner by the server, in order to go to a different scene, a player could enter a house or a cave for instance.

hplus0603 said:
It sounds to me like you need to have an instance of each zone that there's a player in, on the server. This means that you can run AI pathfinding in the server instances, without breaking them out to another process.

By “zone” do you mean map/scene?

Also what did you think about the options that I stated above?