Like HowStuffWorks on Facebook!

Halo Networking: An Interview with Chris Butcher


Who's in Charge Here?
"The thing with this networking model is if there's a bug in the computer code where two machines could provide the same inputs but get different outputs, there can be problems."
"The thing with this networking model is if there's a bug in the computer code where two machines could provide the same inputs but get different outputs, there can be problems."
Photo courtesy of Bungie.net

Chris Butcher continues:

"Halo is also a client/server based network model, meaning that one machine in the game is the server of the game, and then everybody joins it making that machine the master. If you are a client, you send your actions to the server and then when the server receives the actions from everybody it then sends out everybody's collective actions to all clients. And that's how we make sure everybody's in the same game together.

It's actually the same network model we used in Marathon back in the day, although Marathon had some bugs in it. The thing with this networking model is if there's a bug in the computer code where two machines could provide the same inputs but get different outputs, there can be problems. There are lots of different ways that could happen. It could be a bug where you are using just some random garbage memory in the computer and that would be random from machine to machine. That would be bad.

The other thing is that we're not running exactly the same simulation on all machines. When [the server] is sending information about what actions are occurring on all of the machines [it doesn't] send them to everybody. It would be a pure peer model if we did send it to everybody.

The thing is, we run the simulation and we run the world, that's one part of what we do, but then every frame we also have to do things just for the local player, like you have to figure out what their first person weapon is doing, whether they're reloading or throwing a grenade. We actually render their view of the world as well.

So those actions -- because they only take place on one machine -- those actions can't be allowed to affect the deterministic state of the world. So basically we have a separation inside our game. This is the stuff that is deterministic -- it's all the objects in the world and how they move. This is the stuff that is not deterministic -- the sounds that you can hear on the local machine, what you are rendering with your graphics and a couple of other things. We have to separate those two.

If we keep them separated, then the game will stay in sync between the other machines. But if they are not separated correctly -- if there is information transferred between the two -- then the machines will diverge in the simulation, and you might not necessarily notice that because one machine could be like the player is here but the same player is [in a slightly different place] on somebody else's machine, so you might not necessarily notice that, unless you tried to shoot them and the bullet hit them in such a way that hit them on one machine and missed them on another machine. Then the divergence basically cascades like that until eventually the game is completely different on different machines and then it's meaningless of course."


More to Explore