Comments on: Debugging Multiplayer Games

By: Glenn Fiedler

Glenn Fiedler — Fri, 16 Apr 2010 17:08:47 +0000

sure that’s one way to do it, but you’d find the game would hitch a bit more because it has to wait to receive a packet every frame vs. being able to have an amount of time n where it would proceed without blocking

By: Gatsby

Gatsby — Thu, 15 Apr 2010 11:48:27 +0000

interesting article

just have one thing to say about “Synchronous Debugging”:

you know, if you used blocking sockets you wouldn’t have to mess with the timeouts when breaking in the first place. and you could simply hit break as you intended. you could optimize later, when the game works.

By: Swiss Tony

Swiss Tony — Wed, 17 Feb 2010 18:33:29 +0000

I’d also add a ‘debugging’ flag for each clients, based on the result of IsDebuggerPresent() (PC), and passing that flag to all other players. If you have a client that does not respond for a lengthy period of time, but has a debugger attached to him, you can assume he’s hit a breakpoint and you should not disconnect him.

If he has no debugger and does not send heartbeats for 30 seconds, he’s ready for a good kicking.

By: triton

triton — Thu, 10 Sep 2009 23:09:42 +0000

Thanks, this is very useful advice. I'm going to start implementing a multiplayer game and this sure is gonna be helpful.

Waiting for part 2 …

By: Glenn Fiedler

Glenn Fiedler — Tue, 08 Sep 2009 22:47:02 +0000

yeah unreal does something similar in their demo recording and playback mode – it’s pretty neat

By: Liam

Liam — Tue, 08 Sep 2009 21:23:59 +0000

I thought you had gone on the run from the mad stalker

“Notice how the socket receive function is not even called in journal playback mode”
I realise this example code yet for the benefit or other readers. A good idea is to abstract the sending and receiving out to a router interface. These routers are created by a factory method and when a journal is required then a journalling router is attached, when not then normal router is. I feel it is good design (one of the SOLID principles) and also makes the same (or near same) code path used for single and multiplayer versions. When there is to be no network communications a “single instance” router is used to route the messages and similarly in replay mode the messages are read from a stream and passed off.
Using the same code path is something which Dave Weinstein talked about in a past GDC lecture which I would recommend to anything thinking of creating a networked game. He does make the point that using journalling makes you attractive to the armed forces; yet why you would want this I have no idea

By: Glenn Fiedler

Glenn Fiedler — Tue, 08 Sep 2009 15:30:37 +0000

fixed – thanks!

By: Niklas Lundberg

Niklas Lundberg — Tue, 08 Sep 2009 08:52:40 +0000

timeSinceLastHeartbeat += deltaTime; -> timeSinceLastHeartbeat[i] += deltaTime;
at the end in the first code snippet

By: Ben Garney

Ben Garney — Mon, 07 Sep 2009 19:44:02 +0000

My favorite “caught by a journal bug” – game was up and on the same tick that the mission lobby ends and it switches to the next mission, everyone on the server turns on their voice chat, it would crash.

We only caught that one by virtue of long periods of stress testing + journalling. And even then it only happened once.

Are you going to cover fuzz input testing? (ie, having a process that simulates banging on the keys for extended periods?) I’ve found that that is quite useful and a low-effort way to improve stability.

By: Wollnashorn

Wollnashorn — Mon, 07 Sep 2009 11:46:38 +0000

Yay! A new tutorial. Thanks, man.
It’s really helpful.