[omtose]

>execute AIs on clients, and send their inputs along with players' inputs

That seems strange, you'd be sending multiple times the same AI's actions to the server, in which case you better be certain that it's deterministic, not to mention the security concerns. It seems far easier to execute the AI on the server and send its actions to each player, especially if it's a trivial AI.

[MayeulC]

A lot of games actually do this: each client has its own AI, and the games just exchange player state. By syncing player state before computing the AI's next action, you ensure that every game instance will have the AI perform the same operation.

Of course, for this, you need a bit of determinism, and some games need to synchronize other parameters, which can lead to "security" concerns: bullet spread, hit detection and such for FPSs, for example.

This can also lead to some hilarious de-sync issues when a player tries to cheat on its local game instance. By altering its local state, the AI is effectively desynchronized, and the players can observe different outcomes on their local instances. This is often used as a punishment for cheating.

The alternative (for serverless, p2p games) is to have a central host, but it might take a lot of computing resources, and the host is then generally free to cheat.

One side effect of having deterministic AIs synced over the lobby is that the code needs to have the exact same behavior, down to the rounding errors. This can dramatically increase the complexity of cross-platform multiplayer games, and usually requires the exact same binary to be used by every client.

I think that Civilization and Sins of a solar empire use this kind of distributed AI scheme (as well as most games that don't have cross platform multiplayer, and those where you can experience de-syncs).

[maffydub]

I wonder what you might actually do is execute AIs on both, and send occasional snapshots of the AI state from the server to the clients.

This gives you the benefit of low-latency on the client (don't have to wait for the server to tell it what the AI is doing) but also avoids security and non-determinism worries. (Although the AI might still be non-deterministic, it probably can't diverge too much before the client receives the next snapshot from the server).

This might be more effort than it's worth, though...

[posterboy]

> benefit of low-latency

you achieve the benefit by loosening consistency, i.e. the local ai will have to react to local events before those are acknowledged by the server to see any gain, and the server might come to different opinions because it sees a different state of the game considering multiple clients who are constantly out of sync.

That leads to warping. A rocket, to take an example of an extremely simple entity, might fly a few meters on your screen only to explode right in front of your face because the server sent a message that the flight path was blocked by an online enemy that your client didn't predict.

[TeMPOraL]

I don't see how this is an issue. Just imagine that client-side AI is just another player that happens to share the same CPU as the human one. From the server's POV, there's not much difference. Client inputs are client inputs, you always want to have some anti-cheating mechanism in place.

[TeMPOraL]

Client-side AI inputs can be trusted no more and no less than player's input; same anti-cheating mechanisms apply.

Sure, if you can execute AI server-side, go ahead. But the GP asked about scaling it up, and this offers a trivial way of doing so.

[IanCal]

There are different actions that link to cheating though, so I don't think the same anti-cheating mechanisms will work across the board.

A player remaining still doesn't benefit the player. All the AI enemies nearby standing still does.