How Demigod's Networking Problems Were Fixed

The launch of Demigod was troubled by piracy and networking difficulties, which publisher Stardock worked quickly to correct. They've now released a documentary that gives a detailed look behind the scenes of diagnosing and fixing those problems. It includes meetings, interviews with the devs, and part of the bug-tracking process during a frenzied 108-hour work week.

Comments

Re:Nice summary

[Anonymous Coward]

Don't bother, video 1 was some incredibly boring office meetings. video 2 I skipped to cut to the chase, and video 3 was home movie of the boss walking the halls annoying the ever living crap out of the developers actually trying to fix the problem. Again, boring!

Re:Awesome...

[XorNand]

Stardock is based in Plymouth, MI which is halfway between Detroit and Ann Arbor. Slashdot was originally founded in the same area (Dexter, MI IIRC). I live about 15 minutes north of Dexter and about 45 minutes from Plymouth. In case you haven't been following the news, Michigan doesn't have a whole lot to be proud of, economically-speaking. It's possible that the editors have a special fondness for Stardock. While independent game publishers are common in California, it's very rare to find a successful one in the Midwest. And honestly, Stardock produces some pretty top-notch stuff. I am consistently impressed about how close they get to EA in terms of production value. They also have a very progressive (customer friendly) stance on DRM and piracy.

Summary of Technical Reasons Stated In Videos

[The Real Nem]

I've summarized the technical reasons given by the three videos.

Executive Summary:

Seems like their peer-to-peer architecture exasperated otherwise common matchmaking and NAT transversal problems that should be expected and thoroughly tested when developing networked games.

Video 1:

• Summary: The game is peer-to-peer.

Video 2:

• Quote: "We're trying to figure out why users are being removed from the database, which keeps them from being connected, but their not really disconnected, but the server thinks they're disconnected."
• Quote: "...and if you put a return to just ignore the disconnect message it works fine".

Video 3:

• Quote: We're working on a problem in which something, for some reason, keeps telling the database that manages people's records that they're disconnected and we don't know why.
• Quote: So you're putting in the the debug messages?
• Quote: Yep. Just putting in some debug messages to figure out where these ... what is, like ... wh what ... first of who is sending what, um these disconnects.
• Quote: Right, okay, we'll be back.
• Quote: "One of the fields in the database are backwards, or something, on IP addresses because there are so many IP addresses and ports and sockets and stuff that I don't know anything about."
• Observation: They test a fix and it seems to work on several office PCs.
• Summary: The description of the fix includes faster lobby connection time and visual changes to each players ping in the game lobby.
• Paraphrase: How about in terms of the robustness of it, like, how much will people be able to connect?
• Paraphrase: Their games are significantly more intelligent now. Um, there were are lot of crazy things that were going on before and we've been able to simplify a lot of them.
• Paraphrase: What about proxy servers, do you think we need proxy servers now?
• Paraphrase: No I don't think we need proxy servers. It might be good for backup; we were tossing around the thought, I think you brought this up, with routing some traffic if we can thorough the host. That may or may not be possible.
• Paraphrase: Though we had to take care of the case if the host leaves the game we don't want the whole thing to fall apart.
• Paraphrase: Right, right. But it might be a solution for players with low ping times who, you know, can't seem to connect to anybody, but, you know, want to get in the game.
• Paraphrase: Right, that's true. Of course as a backup plan; so if the host left it would take out those people who have really bad connections. But based on what we're seeing, we think, this should handle symmetrical NATs now?
• Paraphrase: What's that?
• Paraphrase: Asymmetrical NATs; this should handle that now?
• Paraphrase: Uh, it's going to handle it better, yeah.
• Paraphrase: Well before it didn't handle it at all, so...
• Paraphrase: Right before it didn't handle it at all, before...
• Paraphrase: I mean if I have two IP addresses, will this work with it now?
• Paraphrase: I don't know that if you have two IP addresses this will work. Uh, this is going to help alot with firewalls and nats, however, um, it does a better job of piercing through the firewall.
• Paraphrase: Of course if you port forward to the right IP, then, from your router, then you're just set.
• Paraphrase: Yeah, that's not an issue.
• Paraphrase: So anyone who's technical will be fine, pretty much for sure, no matter on what kind of crazy connection they've got.
• Paraphrase: And since we've spent more time improving the base systems in the program instead of doing one of the thing

Re:Multiplayer is not fixed

[atamido]

Here are some of the problems, having played it since pretty much the first day: In the initial release, they always tried to use NAT punchthrough. This includes when it wasn't needed. This put more load on their servers and made it slow to connect. Maybe piracy played some role, but given how it worked after it was 'fixed' I rather doubt piracy was the main problem, but more of an excuse. There are some ISPs (and routers) that mess with port numbering for UDP receive. This screws up the P2P network connection.

A big part of the problem was routers that performed Symmetric NAT. Basically, the router will randomize the outgoing port from the router, which is actually a sensible security feature. The problem was that the port would get randomized as something to their connection server, and then randomized to another port when connecting to another player. So that other player would attempt to connect back over a port that wasn't valid.

What was funny about it is that you could forward specific ports to your computer from your router, specify those ports in Impulse, but it still wouldn't work. The outgoing ports on the router would still be randomized to the connection server, and the clients would attempt to connect back over the randomized ports instead of the ports specified in Impulse.

They've improved things but, as you say, they still have a bugs to work out. On the plus side, once they've fixed all of networking issues with Demigod, Impulse should be ready to handle whatever other games come along.

The quote at the bottom of the page, "If things don't improve soon, you'd better ask them to stop helping you."

Re:Multiplayer is not fixed

[Rakthar]

Your comment of:

>>Demigod itself suffers from the problem of being designed with Microsoft's tools that have been focused on the Xbox, and using similar ideas. For example, running at the speed of the slowest isn't a problem when you have a homogeneous environment. PCs aren't homogeneous.

is wrong. They are using the Supreme Commander engine, which was designed for PCs in mind, and had the same issue. The problem is that SupCom and now Demigod are Peer 2 Peer, which means if one node is lagging and can't keep up, everything has to slow down to that pace or things get out of synch. RTS games in particular seem to suffer from this, with Starcraft having slow players and Warcraft 3 having "laggy" connections as well.

It has nothing to do with Xbox tools.