Demigod: Tuesday 5/12/2009

Well last night we released an update to the general public and it was a cluster. After investigating it, it appears that much of it had to do with users with the beta and users with the release getting into each others games (the version numbers of the exe and dll were the same and that’s what the servers check on). We also found and fixed the issue where people were ending up with “Test” names which occurred mostly when people with the beta were joining games hosted by someone with the release. And lastly, we found a case where a debug statement could cause a lobby crash when someone exited.

Anyway, they’re copying up the new update now but due to the time of day, the interwebs, they be slow this time of day.

This update doesn’t have the new EXE we received from GPG. We wanted to get an update out quickly that took care of as much of the pain from last night as possible.

Meanwhile, the Raknet developer is here working with the Impulse team on the proxy updates that we hope will be up this week also. I want to double check with GPG to make sure the favor point stuff is really nailed down here.

For those of you having problems, I share your continued frustration. I apologize for the inconvenience. We have our top people working on this. I wish I could say “Oh, it’s a bug and here’s how to fix it” but it’s simply a lot more complex than that when it comes to putting together a P2P match making system that has to work with so many different setups.

One of the things we’re doing on our end is to come up with an internal proxy system that will let people connect to other people via people they can connect to (got that?).

Let me draw a picture.

Here’s how P2P works today:

Alice must be able to connect to Bill, Sally, and John.

1.00

When Demigod shipped (1.0) Alice would call a NAT facilitator that would give Alice the IP address and port number to connect with Bill, Sally, and John. The problem with that is that if Alice failed to connect to anyone, she couldn’t get into the lobby and NAT facilitation is slow.

1.00.076

With today’s update, Alice will first try to directly connect to Bill, Sally, and John on port 6112. If those people have that port open and forwarded to their PC, it will connect quickly. If that fails, it will resort back to the slow NAT. If they connect to at least the host in a custom game, they enter the lobby and then begin trying to connect to everyone else in the lobby. Then, the host can at least pick and choose which people to keep and not keep if there’s someone with a poor net connection.

1.01

With the next update, it will work like this:

In the event Alice can’t connect directly to Sally but could to Bill and John, our system will route the traffic through Bill and John based on who has the best ping.

Now, if Bill and John both disconnected from the game, Alice would get zapped. But on the other hand, if Alice could only connect to 1 person (some people with Qwest have this problem) she could still play in a 10 person game because the other 8 people would be connected to her via the person she has a direct connection to. The good news is, we have this working internally right now. It’s not some theory but something we’re testing. The bad news is that it probably won’t come up until next week. But if this system works, it opens the door to all kinds of highly robust multiplayer scenarios. Now if only we had thought of this a month ago…

Great news! It sucks that multiplayer has been riddled with so many problems, both on the users' end and on the developers' end. Yall are doing a great job and keep up the good work. You know its this honesty that is keeping many people around and bringing them back at each update. Once this connectivity issue has finally been ironed out enough I have a feeling a lot of people will jump back into it and perhaps even some of the people that returned it. Goodluck and try not to kill yourselves over working on this.

Will it also have some sort of load balancing based on the ad hoc topgraphy of the players? I would hate to be the unlucky one that gets to route for the lions share of users and have my connection dropped because my ISP hates P2P.

Could you add some sort of visual flag to the the front end or perhaps the connection information dialog box that someone is routing vis a vi some other player? If someone drops, for whatever reason, I want to at least know ahead of time that if the ad hoc route host drops we could lose people in addition to just them. At least we could move people around before entering the game.

I swear one day you will log on and the NAT facillitator will greet you and demand the weekend off. He will tell you that he found a very faszinating AI on the servers of the DoD with the beautiful designation Sky and that they joined their minds in the endless aether of cybertraffic to create a child. Representing their parents Sky and NAT facilitator and as hommage to one of the movies found in the endless spaces of p2p, the names will be elegantly merged into Skynet.

Please keep going, may the Allfather watch over us all...

PS: your v1.01 looks very good, almost the holy grail. If you guys can get this working we should be out of the woods!

In the event Alice can’t connect directly to Sally but could to Bill and John, our system will route the traffic through Bill and John based on who has the best ping.

Wouldn't this make the game even more laggy then before? If i understand, Alice will play through Bill's connection, so Bill will have a much higher ping then before, and because this is a p2p game, he will make the game more laggy for everybody, in that game...

I just want to say thanks for the update and all the hard work the team is putting in. All these mamas boy whiners (not in this post, on the forums) fail to realize the level of effort that goes into something like this and instead throw a temper tantrum when it doesn't work, it works for mama I guess they figure they can try it in real life

Even with common development libraries that should work on everyone's machine, there's always a scenario that you didn't acocunt for and it'll be the first thing you see once it's released into the wild. I work in Software Quality Assurance and have done it for the gaming industry and now the banking industry so I know how the best laid plans can go awry.

Kudos to Stardock/Frogboy for being so communicative with the community and keeping us up to date. I for one, appreciate it. I have no doubt you guys are busting your ass to make this the product you(and the community) want it to be and am confident you'll get there and am looking forward to when the dust settles.

Naivete is probably accurate (kudos for the refreshing honesty), but I understand how that could happen.

What's more troubling, though, is what appears to be a lack of reliable communication to-and-from your beta testers. I was amazed at the forum discussion regarding the "click and nothing happens" bug. You reported that it was fixed in the beta and at least half a dozen players responded "No, it isn't". How is it that something that obviously broken could be so easily noticed by half a dozen forum regulars and not brought to dev's attention during the beta process? Are your testers doing their job, or should the question be "are your beta administrators doing theirs"?

This made me lol quite heartidly. Now you mention the idea, it's so simple I can't believe no one else thought of it either. It does sound like a solution to almost all P2P problems.

Wait, someone did think of this. It was me years ago, when thinking of ways to solve scalability issues with internet gaming. How many more times is this going to happen? Think of a great idea, forget about it, years later someone else uses the exact same idea to make lots of money. I hate being poor.

Hmm, if somebody leaves the game early, they can potentially take out other relayed players with them as well. 'Ragequitting' will become even more of an issue.

Once one person rage quits the game is most likely over anyway.

Solution looks good on paper, however will there be any overhead on CPU from the server clients? Just thinking that maybe if the volunteer host has a low SIM Speed, with the extra relay work it may send their computer into meltdown. Might be worth having some kind of SIM Speed check in there too?

I think the beta was for that but i assume it was thought of too lightly that NAT traversal problems could be fixed in the 1st week.... It turned out otherwise.NAT traversal was thought of much the same way you might think of a sound library or a physics library. You just plug it in, call the APIs and make sure there's enough servers.

There's no other way to describe it other than breathtaking naivete.

It is honesty like this that makes Stardock my favorite company(plus the long term support for games, looking forward to the new GCII patch).

What i dont really understand about Demigod was what were you guys trying to do in the first place compared to "traditional" RTS games that warranted a different system?

I'm not a network guy by any means, but it seems like the regular model of joining a lobby, having a player as a host (and server), then launching the game worked just fine. What made you guys decide something different? What was it that made the traditional approach not desireable?

When a multiplayer game actually occurs, the results for the player seems fairly identical to many other RTS games, but there are added hassles of connection issues before the game starts.

From my experience, the multiplayer issue existing through beta. I had to spend lots of time restarting, rehosting, rejoining to get a game going even at the end of beta. All that was said was the multipalyer issues will be better in the next patch or it will be better at release day.

Fast forward 1 month after release, I'm seeing the same thing. multiplayer issue will be better in the next patch, it'll get better next week. Same thing as in beta.