Jump to content
  • Advertisement
Sign in to follow this  
myrdos

Obsolete networking article - Take down?

This topic is 4319 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was reading through the networking articles on this page, and almost all of them are very good. (IMO) However, I came a across an article entitled "Multiplayer Math" by Larry O'Brien that I think is very UNhelpful.
Quote:
Since latency and variability are not solvable problems--they're facts to be worked with--it's as foolish to try to build a twitch-based game for world-wide Internet play as it is to attempt to create an amusement park with genetically engineered dinosaurs. Not because we can't imagine it, but because the technology just doesn't exist.
Quote:
Content developers will probably be forced to create low- and middle-bandwidth games for the next seven or eight years before broadband technologies gain a sufficient installed base to entice developers. ... With the kind of bandwidth being touted by cable modems, by contrast, it will be perfectly feasible to render the graphics for a client entirely at the server-side and push it through at 30 frames per second, which seems amazing until you realize that your television cable does basically the same thing.
Quote:
Audio chat can be especially devastating to performance, since it requires either raw bandwidth consumption or CPU-intensive compression. To make things worse, chat is likely to increase at the most critical time--when the action is fast and furious. Finally, it's difficult, if not impossible, to prioritize and reschedule voice data the way you might with game data. (Don't look to DVSD modems for a magic solution, either. They just allocate the bandwidth between the two functions. A typical DVSD modem will allocate 19.2Kbps to data and 9.6Kbps to voice.) A better way to implement audio chat is the use of "taunt-lines," with predetermined, cached audio streams that can be designated with only a few bytes of actual bandwidth consumption.
Quote:
This is exactly what most multiplayer games you see today do--peer-to-peer direct transmission with perhaps a master player for occasional game-world state checks. This works fine for small groups.
Surely this is no longer true??? (article was written in 1997) Disclaimer: I didn't read the whole article, because every time I started reading somewhere, I saw something ridiculous and obsolete. There may be something valuable buried deep inside, but I submit to you that his misleading guesses about networking will cause more harm to would-be networking programmers than help. Perhaps it would be best to take the article down.

Share this post


Link to post
Share on other sites
Advertisement
I guess he didn't like the Quake series of games, which had been out by then, and were playable over the Internet.

Even in 1997, the connection wasn't peer-to-peer. In most cases, one player hosts the game, and the other players connect, in client/server fashion.

Regarding VOIP: For 1997, compressing audio chat might take a lot of CPU, especially if you didn't require hardware 3D cards. However, these days, it's quite usable, at least on broadband connections. Even on modems, you "can" compress down to about 2 kbps, but the quality is very poor. Many games use voice chat these days.

Quote:
With the kind of bandwidth being touted by cable modems, by contrast, it will be perfectly feasible to render the graphics for a client entirely at the server-side and push it through at 30 frames per second


Btw: This quote made my day :-)

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Quote:
With the kind of bandwidth being touted by cable modems, by contrast, it will be perfectly feasible to render the graphics for a client entirely at the server-side and push it through at 30 frames per second


Btw: This quote made my day :-)



Well of course its feasible, its just that the developers are to cheap to pay for the bandwith needed to do it ;)

-Limb

Share this post


Link to post
Share on other sites
Bah, the problem is that those designers want 24-bit colour. Render your graphics in 8-bit, compress them as GIF and you have no problem.

Share this post


Link to post
Share on other sites
Yes, it won't stress the server at all rendering 32+ different fullscreen views 30 times per second... ;-)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!