Multiplayer networking
Thursday, March 22nd, 2007For the next test release of Orcs vs. Martians, I’ve decided to attempt to support multiplayer networking. For me this is probably the hardest feature to support. It’s just inherently difficult, cumbersome to test, and an area where I have little prior experience.
I’ve dragged several computer systems into my living room in order to have the room to do multiplayer testing. Looks like my living room is going to be an office for a while.
My initial multiplayer test run was pretty humorous. After working out some initial crashes, I got a game world made of bricks. The brick texture is meant for rendering brick roads, but on the client machine the entire world got rendered in brick. It was pretty funny - I had a screenshot but, unfortunately, I lost it.
I worked through that problem and tried again. Next I saw a more familiar problem - the water on the client machine was all wrong. It had rectangular “holes” in it, and the shorelines texture was in the wrong places (namely, not along the shore).
Turns out this problem is caused by random map generation. The client system was generating the water first and then the terrain second, so the water and its shoreline were in the wrong place (not knowing where the terrain was going to be). The problem never manifests itself on the server because, there, the terrain and water get generated in the reverse order. With Torque networking, it’s sometimes hard to get Torque to do things in the order you want.
The fix turned out to be just to re-initialize the water a 2nd time, i.e. after terrain generation on the client machine. A call to WaterBlock::updateFluidRegion() filled in the water’s rectangular holes:
…and then a call to WaterBlock::CalculateDepthMaps() put the water’s shore texture back along the shore:
w00t!
I’ve now got multiplayer working better than it has before. I’ve even implemented a nifty feature that allows the server to pause a multiplayer game, on both server and client(s). So far, so good!
Back to coding.



