AI in multiplayer

It depends a great deal on the game.

Some details need to be kept in sync, other details do not, and those details are unique to every game.

It is generally best for clients to send events across the wire, not processed data. Let the server/host do the work to figure out authoritiatve data, then have the server send out (event + data) updates as needed.

Hi frob,

It's for a sports related game. So, the players have a great deal of AI that goes on. However, I'm worried their state won't reflect and things will get out of wack easily.

What events vs processed data are you referring to? Like position data should not be sent? I'm trying to get a very basic sense on what's suppose to happen.

Example (Basketball game):
- PlayerA vs PlayerB
- PlayerA moves his guy to shoot the ball. The defender comes, jumps up and blocks his shot.
- PlayerB is moving around the court as well.

Server:
- What data is the server getting from playerA & playerB?
- Who is processing the AI for the non-user controlled characters?
- What data is sent the clients to show progress?

Thanks
Jeff.

If you're lock-step networking, then the AI makes the same decisions on all the machines.

If you're client/server, then you likely run the AI on the server, and send the outcomes to each client, as some sequence of events or control data for the AI entities.
This could be anything from a high-level plan ("go over there and perform that action") to per-step instructions similar to what you'd send for a player in an FPS.

for a 2-player only game... what makes more sense? Are games typically "lock-step"?

I would think because sports games are deterministic because of re-plays, that you would just have the server feed up the non-deterministic values (all the random numbers + input)?

Any ideas?

Are games typically "lock-step"?
[/quote]

There is no "typical" implementation for games, although certain styles of gameplay (RTS, FPS, Racing, MMO, board games, etc) typically tend towards certain solutions or parameter combinations that best match that particular game style.

For example:
Almost all (big) RTS-es are lockstep.
Not many (big) FPS-es are lockstep.

So what type of data will I be sending?

If I do a peer to peer 'lock-step' what would I need to send? for instance, do I need to send what frame of the animation their player is at? What about the AI, how can I be sure all the AI animations to be in sync? I can easily sync the player positions and velocities, but getting the animations to appear in sync, I'm not sure.

This is relatively important, for the case of shooting, you want to see the other player jump and shoot at about the right time.

Thanks
Jeff.

do I need to send what frame of the animation their player is at?[/quote]

You need to send no other data than the player inputs for each step, if you correctly implement lockstep networking.

hplus,

I guess I don't understand lockstep.

Are you saying every frame of the game you will need to:

* Receive Data from Host Peer
* Update the game
* Render the game
* Send Inputs from this Peer to Host

Host peer would look like:

* Receive Data from Client Peer
* Update the game
* Render the game
* Send Inputs from this Peer to Client

??

In a peer to peer method, is there a such thing as a host vs client?

I guess the host would be one in charge of gathering up the random numbers for the game and sending it to the client... is that correct?

So really the host is sending it's input data + random number generated data for this frame?? So that the client can generate the same AI, etc.? What about frame rate, elapsed time issues?

Sorry about these questions, I know very little about network programming.

Thanks
Jeff.

I guess I don't understand lockstep.

I highly recommend reading the Age of Empires ("1,500 archers") article, linked to by the FAQ of this forum.

In a peer to peer method, is there a such thing as a host vs client?
[/quote]

You can use a peer-to-peer physical network connection, and still use a client/server logical game topology.

I guess the host would be one in charge of gathering up the random numbers for the game and sending it to the client... is that correct?
[/quote]

No. In a lock-step simulation, you initialize all the (pseudo-)random number generators to the same value once. Then, because all nodes run exactly the same commands in exactly the same order, the random number generators will generate the same values on all the nodes.

A simple way to think about this is that the game client looks something like:


game_step = 1;
for (step = game_step; step <= game_step + latency; ++step) {
send_empty_data_for_step(step);
}
forever() {
receive_packets();
if (i_have_all_packets_for_step(game_step)) {
step_simulation_once();
game_step += 1;
send_user_input_for_step(game_step + latency);
}
collect_input_commands();
animate();
render();
}


It's important that local commands do not actually have any effect on the local game state -- the local game state is only affected within step_simulation_once().

The "hosting" player still runs this kind of client, just like anyone else. Additionally, on the host, there is another logical process, that does:


game_step = 1;
forever() {
if (i_have_all_player_data_for_step(game_step)) {
send_all_player_data_for_step_to_all_players(game_step);
game_step += 1;
}
}


This can be interwoven in the main loop, or it can be a separate thread, or it can even be a separate process. It doesn't matter much. Note that the server doesn't necessarily have to simulate anything at all -- if you do proper lock-step, then the clients will all simulate exactly the same thing for the same step number. De-synch will be the result of a code bug, or the result of deliberate cheating.

hplus,

Thanks for help so far!

I was talking to someone else on IRC. They seem to believe that really only RTS's use lock-step and that sports games should probably be using a server-client system.

Discussing further, he set it up like this....
Computer1
- Is Client1
- Runs the server

Computer2
- Is Client2

So each game is a client, but one of the computers runs the 'server' which is responsible for doing the AI simulations and telling the clients what to do.

Do you agree/disagree with that?

So, using your syntax, it might be something like this:

// SERVER
forever()
{
receive_packets();
if (i_have_any_data_put_into_queue())
{
process_queue();
}

update_ai_simulation();
send_all_data_to_clients(); // ?
}

// EACH CLIENT
forever()
{
receive_packets();
if (i_have_any_data_put_into_queue())
{
process_queue();
}

update_my_game_sim();
send_only_my_user_data_to_server();
}


Does that seem right?

Thanks
Jeff.

They seem to believe that really only RTS's use lock-step[/quote]

Not necessarily true. Torque network engine (a version after the Torque 3D game engine) did it for FPS, according to a presentation I saw at GDC. There.com does it for a virtual world. The trick is to figure out how to hide the round-trip latency of a command going to the server and coming back. This can be done with acknowledge animations, or by showing the local client "ahead" and correcting if you guess wrong, or by game design, etc.

I recently added multiplayer to my RTS, I decided to go with client/server. After reading the AOE article and realizing how hard doing lockstep is I thought there is no way I want to tackle it when adding networking to an already mature code base, if a team of full time networking and AI experts had difficulty implementing it, I didn't stand a chance. I wasn't shooting for perfect game simulation either, which if you have a competitive AAA RTS title that would be very important, hopefuly my implementation is good enough for casual games, I will be releasing a beta soon.

My favorite way to handle NPC artificial intelligence, actually basically the whole NPC system.

Basically in multiplayer game the client sends and receives data according to the input of the player, but what happens when you write bot to replace the player input, you have artificial intelligence of some sort even though the bot might just be a macro. So basically remove all of the code from the real players client what you think your artificial intelligence does not need and afterwards modify the client to run the artificial intelligence. Now you can host these NPC clients anywhere you basically want and possibly make one NPC client act as multiple NPCs.

We just simplified the game server a ton and categorized NPCs and Players as same things, because really they do the same thing, but the other is programmed and the other is born. Though this does use more bandwidth, but you can of course run the game server and NPC clients in local network or even in same physical server.