Search
Forum Home | Login
Feralax
Feralax
Join Date 04/2009
0

Thoughts the Networking Issue(s)

Yeah, I'm going to rant.

April 15, 2009 8:27:51 PM from Demigod ForumsDemigod Forums

First a criticism: sorry about this Stardock, but somebody had to point this out--saying that you are going to forego using a server/client model for the sake of reduced latency is like saying you are going to code the entire game in x86 assembly language for the sake of having the entire program run faster; it's something that people decided a long time ago that we, as developers, weren't going to do, because the efficency lost by using a compiler is made up for by the gain in sanity/the program actually working. My point is this: have you actually tested it and found that latency is so significant an issue with the server/client model that you have no other recourse?

Second, a statistic: After over fifty attempts, I managed to make it in to the lobbies of exactly 6 custom games; the router was a nonissue, as I bypassed it by connecting directly into the cable modem. I don't think blaming it on my ISP is particularly fair, as I would imagine you would be hardpressed to find any statistically significant sample of websites/other games that my ISP is the cause of my inability to visit/play (ie, the number of OTHER things I can't do on the internet because of my ISP is--statistically speaking--zero). Same goes for the Windows socket argument: I can't remember the last time that I went to a website, got an error, and was able to fix it immediately by refreshing. Granted, the web is TCP, but the point remains... My point is this: Even with the error-prone method of "everybody connects to everybody else," this statistic is unfathomably high; the fact that it is possible for Client A to connect to Client C and Client B to connect to Client C, but not for Client A to connect to Client B really suggests that there is something a little fishier going on.

Finally, a suggestion: Is there no way to hybridize your system to include a server/client model should no other recourse prove possible. That is to say, if Client A and Client B can both connect to Client C, but Client A cannot connect to Client B, then--in order to avoid "giving up" and declaring the game impossible--is it possible to implement it in such a way that Client A connects to Client B through Client C? My point is this: I implore you to at least consider an alternative; there is a /reason/ people use the server/client model.

 

 

 

demigod
Locked Post
Search this post
Advanced Search
Subscription Options
Reason for Karma (Optional)
Successfully updated karma reason!
Feralax
DalzK
Join Date 09/2008
+26
Reply #1 April 15, 2009 8:41:29 PM
from Demigod ForumsDemigod Forums

My point is this: have you actually tested it and found that latency is so significant an issue with the server/client model that you have no other recourse?

Well if you look at other games (DotA in particular) which doesnt use a p2p model, you will see that players from, lets say, USA and the UK cannot player with each other without lag. In Demigod I hardly ever get lag with people in the USA (im in UK)

Finally, a suggestion: Is there no way to hybridize your system to include a server/client model should no other recourse prove possible. That is to say, if Client A and Client B can both connect to Client C, but Client A cannot connect to Client B, then--in order to avoid "giving up" and declaring the game impossible--is it possible to implement it in such a way that Client A connects to Client B through Client C? My point is this: I implore you to at least consider an alternative; there is a /reason/ people use the server/client model.

Well they said they are going to implement a system similar to this as their newest game (Elemental) will use it, so they can put it into Demigod rather easily. Basically, if two people fail to connect to each other they will connect via the server first instead (they have servers in many different countries so this is possible).

Reason for Karma (Optional)
Successfully updated karma reason!
Feralax
VoodooKing
Join Date 12/2002
+2
Reply #2 April 15, 2009 9:06:07 PM
from Demigod ForumsDemigod Forums

I think the client/server model is 'the' way to go. Latency shouldn't be a problem if players connected to each other are within the same region. It has worked for many games, I don't see why Demigod should be any different.

Reason for Karma (Optional)
Successfully updated karma reason!
Feralax
SuperMudkipz
Join Date 04/2009
0
Reply #3 April 15, 2009 9:20:37 PM
from Demigod ForumsDemigod Forums

Quoting DalzK,
reply 1
In Demigod I hardly ever get lag with people in the USA (im in UK)

And if the game was entirely functional the userbase would be large enough that you wouldn't need to play people from across the world to get a match going

Reason for Karma (Optional)
Successfully updated karma reason!
Feralax
tazzx
Join Date 06/2008
0
Reply #4 April 15, 2009 11:06:28 PM
from Stardock ForumsStardock Forums

my thoughts on p2p and client/server.

client server you cant vs people from other countries, much to high latency
p2p, you can

i live in australia with its small pop of 20mil, i like having people to play with. so far in all my beta experience and retail game i've vsed very few australians, so im happier with p2p, lets just hope all the kinks get ironed out

Reason for Karma (Optional)
Successfully updated karma reason!
View all recent posts
Mark all posts as read Delete cookies created by the forum Return to Top
Stardock Forums v        Server Load Time:   Page Render Time:

Stardock Magazine | Register | Online Privacy Policy | Terms of Use

Copyright © 2025 Stardock Entertainment and Gas Powered Games. Demigod is a trademark of Stardock. All rights reserved. All other trademarks and copyrights are the properties of their respective owners. Windows, the Windows Vista Start button and Xbox 360 are trademarks of the Microsoft group of companies, and 'Games for Windows' and the Windows Vista Start button logo are used under license from Microsoft. � 2012 Advanced Micro Devices, Inc. All rights reserved. AMD, the AMD Arrow logo and combinations thereof are trademarks of Advanced Micro Devices, Inc.