Thread: [Algorithms] Network implementation, where to start
Brought to you by:
vexxed72
From: Sam M. <sa...@dn...> - 2000-11-23 02:45:12
|
Hi all, I'm about to start adding network support to my game. The way I see it, I have the following two options: use DirectPlay, or come up with my own protocol via Winsock. What are your experiences with these two options? It seems like I would have very fine grained control and maximum efficiency by writing my own protocol, but at the same time I might stumble across obstacles that I wouldn't encounter with DirectPlay. The other question is portability. I want to make sure that it's not going to be impossible to later port my network code to a different operating system. If DirectPlay hides what's going on beneath the surface, I'd imagine portability would be rather difficult. I'm pretty clueless about network programming in general so I've got a lot to learn, but I want to make sure I'm heading down the right path to start off with. Comments please! -Sam |
From: Akbar A. <sye...@ea...> - 2000-11-23 04:32:52
|
hey, to be honest, use direct play. i don't use it, but it seems like it's the 'right thing' to do now. to many cool examples in the dplay sdk now to pass up. is that *voice stuff even for real? if you want to learn winsock, cool =) there is a buttload of stuff in msdn <cool winsock examples>, and mspress just released a new book on it. network programming for windows i gave phil a link to it.. if you plan on porting, then use winsock. but if not use dplay. if you go with winsock <dx8 sdk exapmles look pretty cool to me, again>; my friend that works over at croteam, took a pretty neat approach to there game/engine. instead of emulating a dedicated layer in udp, they just went in and opened up a buttload of ports. so iirc it's 3 udp's flying and 1 tcp for dedicated msg's. >I'm pretty clueless about network programming in general so I've got a lot >to learn that's really the beauty of all these neat api's/languages coming out. you don't ;) btw, a little blip on c# since everyone had diffrent views on it, esp linux users.. 'The terms of the Microsoft investment included an option under which Microsoft could request that Corel translate Microsoft's next-generation .Net server software to Linux.' http://yahoo.cnet.com/news/0-1003-200-3785993.html?pt.yfin.cat_fin.txt.ne weird, cause i thought corel was bill's private investment (135 mill), oh well. please offline on that.. *this is not an easy problem at least with today's common bandwidth i cc'd this cause some stuff about dplay -voice. good luck, akbar A. "common knowledge isn't as common as you think".. not sure if i got this quote right.. -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Sam McGrath Sent: Wednesday, November 22, 2000 8:44 PM To: gda...@li... Subject: [Algorithms] Network implementation, where to start Hi all, I'm about to start adding network support to my game. The way I see it, I have the following two options: use DirectPlay, or come up with my own protocol via Winsock. What are your experiences with these two options? It seems like I would have very fine grained control and maximum efficiency by writing my own protocol, but at the same time I might stumble across obstacles that I wouldn't encounter with DirectPlay. The other question is portability. I want to make sure that it's not going to be impossible to later port my network code to a different operating system. If DirectPlay hides what's going on beneath the surface, I'd imagine portability would be rather difficult. I'm pretty clueless about network programming in general so I've got a lot to learn, but I want to make sure I'm heading down the right path to start off with. Comments please! -Sam _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list |
From: Shane S. \(Work\) <sh...@bl...> - 2000-11-23 05:06:15
|
There is one more possibility you have forgotten about, and that is non-Microsoft machines talking to each other, like a PS2 -> PC, or a Dreamcast->Xbox. So DPlay on one machine and some other protocol on another. I am currently going through the same thought processes myself and it's a REALLY hard call because writing your own network layer from scratch using Winsock, although obviously doable, is quite an undertaking and is seriously reinventing the wheel, but using DPlay locks you pretty much into PC<->XBox. DPlay kicks ass now, and for you to try, on your own, to write DPlay then you are stepping into a world of hurt. :) The other option, which is what I reckon I'll go for, is to say "who cares" about a PS2 talking to an XBox. They probably wouldn't let you develop the same for them both anyway. :) Then DPlay just becomes your message transport layer which can be written differently on each console, like your rendering layer. So you get: PC<->PC PC<->XBox XBox<->XBox Dreamcast<->Dreamcast PS2<->PS2 I have pretty much convinced myself about DPlay, and I am 95% sure I'll use it. It's a similar argument to D3D v OGL, except there is no real equivalent to OGL in networking. Shane Shane Stevens Lead Programmer bluetongue www.bluetongue.com -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Sam McGrath Sent: Thursday, 23 November 2000 1:44 PM To: gda...@li... Subject: [Algorithms] Network implementation, where to start Hi all, I'm about to start adding network support to my game. The way I see it, I have the following two options: use DirectPlay, or come up with my own protocol via Winsock. What are your experiences with these two options? It seems like I would have very fine grained control and maximum efficiency by writing my own protocol, but at the same time I might stumble across obstacles that I wouldn't encounter with DirectPlay. The other question is portability. I want to make sure that it's not going to be impossible to later port my network code to a different operating system. If DirectPlay hides what's going on beneath the surface, I'd imagine portability would be rather difficult. I'm pretty clueless about network programming in general so I've got a lot to learn, but I want to make sure I'm heading down the right path to start off with. Comments please! -Sam _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list |
From: Akbar A. <sye...@ea...> - 2000-11-23 09:35:04
|
>PS2 talking to an XBox. i'm not familiar with dplay But; isn't it just a matter of decoding whatever dplay sends over, convert it to 'normal' form, then make the conversion to whatever os' you want? i mean dplay is a top level layer.. everything gets crammed into a *packet* and sent over a pipe, so wouldn't it just be a matter of writing a *convert utitly.. or is the dplay kind of shabby on this? *is this even possible, i mean is dplay really intense <can't find the word, 3:38 am here ;) laterz, akbar A. "common knowledge isn't as common as you think".. not sure if i got this quote right.. -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Shane Stevens (Work) Sent: Wednesday, November 22, 2000 11:06 PM To: gda...@li... Subject: RE: [Algorithms] Network implementation, where to start There is one more possibility you have forgotten about, and that is non-Microsoft machines talking to each other, like a PS2 -> PC, or a Dreamcast->Xbox. So DPlay on one machine and some other protocol on another. I am currently going through the same thought processes myself and it's a REALLY hard call because writing your own network layer from scratch using Winsock, although obviously doable, is quite an undertaking and is seriously reinventing the wheel, but using DPlay locks you pretty much into PC<->XBox. DPlay kicks ass now, and for you to try, on your own, to write DPlay then you are stepping into a world of hurt. :) The other option, which is what I reckon I'll go for, is to say "who cares" about a PS2 talking to an XBox. They probably wouldn't let you develop the same for them both anyway. :) Then DPlay just becomes your message transport layer which can be written differently on each console, like your rendering layer. So you get: PC<->PC PC<->XBox XBox<->XBox Dreamcast<->Dreamcast PS2<->PS2 I have pretty much convinced myself about DPlay, and I am 95% sure I'll use it. It's a similar argument to D3D v OGL, except there is no real equivalent to OGL in networking. Shane Shane Stevens Lead Programmer bluetongue www.bluetongue.com -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Sam McGrath Sent: Thursday, 23 November 2000 1:44 PM To: gda...@li... Subject: [Algorithms] Network implementation, where to start Hi all, I'm about to start adding network support to my game. The way I see it, I have the following two options: use DirectPlay, or come up with my own protocol via Winsock. What are your experiences with these two options? It seems like I would have very fine grained control and maximum efficiency by writing my own protocol, but at the same time I might stumble across obstacles that I wouldn't encounter with DirectPlay. The other question is portability. I want to make sure that it's not going to be impossible to later port my network code to a different operating system. If DirectPlay hides what's going on beneath the surface, I'd imagine portability would be rather difficult. I'm pretty clueless about network programming in general so I've got a lot to learn, but I want to make sure I'm heading down the right path to start off with. Comments please! -Sam _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list |
From: Adam M. <amo...@dp...> - 2000-11-23 11:52:17
|
Then you would in effect be writing a direct play emulator for your target platform. Theoretically it is possible, but most people usually don't approach portability that way (if they have the sources -- I believe that there are quite decent windows emulators for linux, for example), for very good reasons: * performance * dependance on MS' annual rehaul of DirectX * MS usually doesn't publish its internal formats * its much easier to use existing portable interfaces than hacking existing nonportable ones. ________________________________________________________________________ p e r s p e c t i x -- interactive visual computing adam moravanszky mor...@pe... perspectix ag phone: +41-1-277 57 97 hardturmstrasse 171 fax: +41-1-277 57 78 8005 zurich, switzerland www.perspectix.com ________________________________________________________________________ > >PS2 talking to an XBox. > i'm not familiar with dplay But; > isn't it just a matter of decoding whatever dplay sends over, > convert it to 'normal' form, then make the conversion to whatever os' you > want? > i mean dplay is a top level layer.. > everything gets crammed into a *packet* and sent over a pipe, > so wouldn't it just be a matter of writing a *convert utitly.. > > or is the dplay kind of shabby on this? > > *is this even possible, i mean is dplay really intense <can't find the word, > 3:38 am here ;) > > > laterz, > akbar A. > > > "common knowledge isn't as common as you think".. > not sure if i got this quote right.. |
From: Eric L. <lengyel@C4Engine.com> - 2000-11-23 07:45:29
|
> I'm about to start adding network support to my game. The way I see it, I > have the following two options: use DirectPlay, or come up with my own > protocol via Winsock. What are your experiences with these two options? It > seems like I would have very fine grained control and maximum efficiency by > writing my own protocol, but at the same time I might stumble across > obstacles that I wouldn't encounter with DirectPlay. > > The other question is portability. I want to make sure that it's not going > to be impossible to later port my network code to a different operating > system. If DirectPlay hides what's going on beneath the surface, I'd > imagine portability would be rather difficult. > > I'm pretty clueless about network programming in general so I've got a lot > to learn, but I want to make sure I'm heading down the right path to start > off with. If you don't know a lot about network programming, then DirectPlay is definitely going to get you to a functional implementation the fastest. The downsides are exactly what you mentioned: everything is done in way which is hidden from you, and it is not in the least bit portable. I chose to take the route which gives me the greatest possible control over the bits that go over the wire. I use the UDP protocol (part of TCP/IP), accessed through WinSock 2.0 on Win32 platforms and OpenTransport on the MacOS platform. There are many difficulties with this approach, not the least being that guaranteed, in-order packet delivery is something that you have to take care of yourself. I discussed the basics of PC/Mac UDP networking in an article on Gamasutra earlier this year: http://www.gamasutra.com/features/20000124/lengyel_01.htm -- Eric Lengyel |
From: Daniel V. <vo...@lo...> - 2000-11-23 08:35:57
|
On Thu, Nov 23, 2000 at 04:06:11PM +1100, Shane Stevens (Work) wrote: > > I have pretty much convinced myself about DPlay, and I am 95% sure I'll use > it. It's a similar argument to D3D v OGL, except there is no real > equivalent to OGL in networking. No. D3D can be ported over to OpenGL (e.g. Michael Vance did it for Heavy Gear II) but Direct Play is completly not portable. So if you choose to use Direct Play you rule out network compatibility with e.g. Linux. Even when you don't even consider your app/ game running on another platform than Windows XYZ keep in mind that it also rules out dedicated servers on other platforms. -- Daniel Vogel vo...@lo... Programmer 714-505-8915 x17 Loki Software www.lokigames.com |
From: Aaron D. <ri...@ho...> - 2000-11-23 12:50:49
|
While I've no experience with DirectPlay, one of the speakers at the AGDC mentioned that it (I think they were using DX7) had a funny knack of dropping players in one of their RTS title postmortoms. I've never used it so I can't vouch for that personally. May have been a poor implementation on their side. I've always used UDP or TCP (partially because I like the idea of portability, even if I don't intend it in the initial design and partially because I'm used to networking code after working on network gear for a number of years) for all networked apps. There's a fair deal of quality reference material available (take the GPL'ed quake engine for example). You might also want to take note, as previously stated, of the implications of using a microsoft-only API for network comm's. It's EXTREMELY limiting (to put it nicely) when it comes to cross-platform game play. > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...]On Behalf Of > Daniel Vogel > Sent: Thursday, November 23, 2000 7:36 PM > To: gda...@li... > Subject: Re: [Algorithms] Network implementation, where to start > > > > On Thu, Nov 23, 2000 at 04:06:11PM +1100, Shane Stevens (Work) wrote: > > > > I have pretty much convinced myself about DPlay, and I am 95% > sure I'll use > > it. It's a similar argument to D3D v OGL, except there is no real > > equivalent to OGL in networking. > > No. D3D can be ported over to OpenGL (e.g. Michael Vance did it for > Heavy Gear II) but Direct Play is completly not portable. So if you > choose to use Direct Play you rule out network compatibility with e.g. > Linux. Even when you don't even consider your app/ game running on > another platform than Windows XYZ keep in mind that it also rules out > dedicated servers on other platforms. > > -- > Daniel Vogel vo...@lo... > Programmer 714-505-8915 x17 > Loki Software www.lokigames.com > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
From: Daniel V. <vo...@lo...> - 2000-11-23 08:39:40
|
On Wed, Nov 22, 2000 at 06:44:21PM -0800, Sam McGrath wrote: > > The other question is portability. I want to make sure that it's not going > to be impossible to later port my network code to a different operating If you don't want to rule out network compatibility don't use DirectPlay. > system. If DirectPlay hides what's going on beneath the surface, I'd > imagine portability would be rather difficult. I'd say "impossible". -- Daniel Vogel vo...@lo... Programmer 714-505-8915 x17 Loki Software www.lokigames.com |
From: Akbar A. <sye...@ea...> - 2000-11-23 10:11:14
|
>I'd say "impossible" i guess this answers my earlier question about rev eng it ;) laterz, akbar A. "common knowledge isn't as common as you think".. not sure if i got this quote right.. -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Daniel Vogel Sent: Thursday, November 23, 2000 2:40 AM To: gda...@li... Subject: Re: [Algorithms] Network implementation, where to start On Wed, Nov 22, 2000 at 06:44:21PM -0800, Sam McGrath wrote: > > The other question is portability. I want to make sure that it's not going > to be impossible to later port my network code to a different operating If you don't want to rule out network compatibility don't use DirectPlay. > system. If DirectPlay hides what's going on beneath the surface, I'd > imagine portability would be rather difficult. I'd say "impossible". -- Daniel Vogel vo...@lo... Programmer 714-505-8915 x17 Loki Software www.lokigames.com _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list |
From: David H. <da...@hu...> - 2000-11-23 12:58:16
|
To throw my own tupenny-hapennys worth in here, having used both I'd go for the TCP/IP UDP way. The DPlay pros/cons in my opinion are: Pros: 1/ DPlay will get you off the ground quicker and is pretty cool if all you want is PC-PC communication. 2/ DPlay seemlessly supports IPX based LAN communication as well - however most office networks where only IPX was used now use TCP/IP as well or instead - and even if they don't it's easy enough to set up. Cons: 1/ DPlay is surprisingly almost as complex to use as lower level TCP/IP - usual large API bloat. 2/ Winsock is based on a pretty much universal sockets model which is easily portable across platforms (don't know if Winsock is available on XBox?). 3/ (and I don't think anywhere enough emphasis is placed on this one) Most large companies employ firewalls or proxys of one sort or another. Typically these prevent incoming connection attempts to hardware on the company side, but sometimes with things like Socks they require all traffic is routed through a special proxy server. These firewalls are often pretty simple to code round or through and there is some support for them in DPlay 6 but only if your administrator is prepared to open certain port ranges for incoming connects (even if you're a client). Normally the administrator will say no - however unless you're using multiple peer-peer networking a single outgoing connect to the server is enough - easy with Winsock - can't be done with DPlay (I think?). If more people start taking this sort of thing into account I might be able to start playing counter-strike on the internet at lunchtime. Thank you. David |
From: Bernd K. <bk...@lo...> - 2000-11-23 21:13:44
|
Daniel Vogel writes: > Shane Stevens writes: > > convinced myself about DPlay, and I am 95% sure I'll use > > it. It's a similar argument to D3D v OGL, except there is no real > > equivalent to OGL in networking. > > No. D3D can be ported over to OpenGL (e.g. Michael Vance did it for > Heavy Gear II) but Direct Play is completly not portable. I think Shane Stevens is correct in his point that there is no vendor-neutral networking API above the level of TCP/IP, SMTP, FTP, HTTP etc. DirectPlay exists because in many (if not al) cases chat, messaging, mail,voice-over-IP can efficiently be implemented w/o being game specific, and developers are just as happy not having to deal with it. IIRC DX8 spiced DP up by adding an (acquired) technology that is resource intensive but rather specific to multiplayer games (ability to do multiple server-side mixing of voice-over-network). Efficient voice compression and decompression is a good example of technoloy that a developer might be better off licensing, but then the same could be said for efficient delta compression, authentification and encryption of UDP networking for knee-jerk games. At this point licensing an engine is a definite option. DP gives you something for free that you might need, but the portability of your title will be affected seriously: either feature loss (up to and including inability to play over the net across OS), or a rather expensive port. > > If DirectPlay hides what's going on beneath the surface, I'd > > imagine portability would be rather difficult. > > I'd say "impossible". In particular if legal issues arise. API's and file formats should not be proprietary, but that concept has been used for "area denial" before. b. |
From: Neal T. <ne...@ps...> - 2000-11-24 01:33:40
|
Bernd Kreimeier <bk...@lo...> writes >I think Shane Stevens is correct in his point that there is no >vendor-neutral networking API above the level of TCP/IP, SMTP, >FTP, HTTP etc. OpenPlay? (http://www.publicsource.apple.com/projects/openplay/) Admittedly, when I last looked at it (about 8 months ago now), it did seem to be in need of some work, but there has been a complete new release (1.2) since then... Neal Tringham (Sick Puppies / Empire Interactive) (ne...@ps...) (ne...@em...) |
From: Parrish H. <phe...@bi...> - 2000-11-23 23:47:02
|
Sam McGrath wrote: > Hi all, > I'm about to start adding network support to my game. The way I see it, I > have the following two options: use DirectPlay, or come up with my own > protocol via Winsock. What are your experiences with these two options? It > seems like I would have very fine grained control and maximum efficiency by > writing my own protocol, but at the same time I might stumble across > obstacles that I wouldn't encounter with DirectPlay. > > The other question is portability. I want to make sure that it's not going > to be impossible to later port my network code to a different operating > system. If DirectPlay hides what's going on beneath the surface, I'd > imagine portability would be rather difficult. > > I'm pretty clueless about network programming in general so I've got a lot > to learn, but I want to make sure I'm heading down the right path to start > off with. > Comments please! To a large degree, this will depend upon the scope of your project. If you're working on a small shareware/freeware/demoware style game with no expectations of significant commercial gain, then I'd suggest DirectPlay is worth a shot. It's there, it's free and your game would probably not suffer due to DirectPlay's isolation platform-wise. On the other hand if you're engaged in a commercial project, the issues are slightly different. In this instance DirectPlay is probably most appropriate for peer-peer networking games such as Age of Empires and so on. If your game is client-server, then I'd think again. A significant proportion of dedicated servers run on Linux or other Unix derivatives. In this instance, DirectPlay's lack of portability weighs heavily against it. You'll also tend to find (and this is true for OpenGL as well) that there's a larger community of experts who are familiar with TCP/IP and its various idiosyncracies than there is for DirectPlay (especially DirectPlay8). When you're looking for help - fast - this can make a powerful difference. There is also DirectPlay8 itself. No-one really knows how well DirectPlay8 is implemented. Does it scale well? Are there any success stories? What are the risks? Given that the authors of DirectPlay6/7 continued promoting it right up until its imminent demise, it seems unlikely we can rely upon them for an honest evaluation. If you really would like to use DirectPlay8 in a commercial project, it might be worth soliciting some opinions from developers who have used it commercially. Right now, that means talking to people who were on the DirectX8 beta program. Cheers, Parrish Heywood |
From: Akbar A. <sye...@ea...> - 2000-11-24 00:47:37
|
i've searched through google and couldn't get to much interesting info... does anyone know where i could find some interesting info on what's behind the algos on some of the video codecs <mpeg, divx>... thanks, akbar A. ;vertexabuse.cjb.net "common knowledge isn't as common as you think".. not sure if i got this quote right.. |
From: gl <gl...@nt...> - 2000-11-24 02:12:04
|
Try mpeg.org (btw, DIVX is a hacked version of MS' mepg4 codec). -- gl ----- Original Message ----- From: "Akbar A." <sye...@ea...> To: <gda...@li...> Sent: Friday, November 24, 2000 12:51 AM Subject: [Algorithms] video codecs > i've searched through google and couldn't get to much interesting info... > does anyone know where i could find some interesting info on what's behind > the algos > on some of the video codecs <mpeg, divx>... > > thanks, > akbar A. > ;vertexabuse.cjb.net > > > "common knowledge isn't as common as you think".. > not sure if i got this quote right.. > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
From: <Lea...@en...> - 2000-11-24 02:32:44
|
> i've searched through google and couldn't get to much interesting info... > does anyone know where i could find some interesting info on what's behind > the algos > on some of the video codecs <mpeg, divx>... http://www.mpeg.org/MPEG/MSSG/ Leathal. |
From: Akbar A. <sye...@ea...> - 2000-11-24 03:11:02
|
thanks; jeeesh, i've been reading about this a bunch more. wow, they got some messed up problems ;) and i though pulling 12 mill triangles over the bus was a prob ;) laterz, akbar A. ;vertexabuse.cjb.net "common knowledge isn't as common as you think".. not sure if i got this quote right.. -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Leath Muller Sent: Thursday, November 23, 2000 8:38 PM To: gda...@li... Subject: Re: [Algorithms] video codecs > i've searched through google and couldn't get to much interesting info... > does anyone know where i could find some interesting info on what's behind > the algos > on some of the video codecs <mpeg, divx>... http://www.mpeg.org/MPEG/MSSG/ Leathal. _______________________________________________ GDAlgorithms-list mailing list GDA...@li... http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list |
From: Nicolas S. <nic...@ch...> - 2000-11-24 04:22:01
|
> i've searched through google and couldn't get to much interesting info... > does anyone know where i could find some interesting info on what's behind > the algos > on some of the video codecs <mpeg, divx>... Search for more specific things.. Checking my copy of MPEG2, references of the spec are ISO/IEC 13818 (part 2 for the video), also known as ITU-T H.262 (video only). I don't have the MPEG4 references at hand, since it was in its early stages at the time I was working on MPEG2, but you can clearly find links from those sites. Check out : http://www.mpeg.org/MPEG/video.html (non-official, but has almost all worth surfing pointers) http://www.cselt.it/mpeg/ (the real official mpeg commitee homepage) -MPEG2 and MPEG1 are very close; they use the same coding scheme. -MPEG2 mainly extends and generalizes the previous spec, and adds some support for interleaved video. It is the one used for DVDs, digital cable or sat etc. -MPEG3 never existed because the commitee realized that flexibility of the profile/level stuff of MPEG2 allowed it to match requirements of the 3rd revision. -MPEG4 adds new more advanced stuff such as wavelet coding and more general textures/shapes.. It is designed specifically for low bitrates channels. AFAIK, DivX is lame rip-off of Microsoft's MPEG4 codec, where the guys only changed a few little things (audio codec?). -MPEG7 and MPEG21 are the latests iterations. I clearly recommend you reading Chad Fogg's MPEG2 FAQs linked from previous site (or here if you are lazy http://bmrc.berkeley.edu/frame/research/mpeg/mpeg2faq.html). This is clearly the best one available. Hope this helps --- Nicolas |
From: Samuel M. <sa...@dn...> - 2000-11-24 20:15:08
|
> In this instance DirectPlay is probably most appropriate for peer-peer > networking games such as Age of Empires and so on. Ah hah, which brings me to my next question! The type of game I'm writing is an RTS, and I've been wondering which architecture to go for, peer-to-peer or client-server. I feel that computers generally are fast enough these days, and our game is not too demanding (i.e. we're not dealing with a million units) for one computer to handle the entire simulation and distribute information to each client. I can think of a few problems with client-server though, one of which is if the player running the server loses early, he/she is not necessarily going to want to sit through the rest of the game..i.e. server responsibility would have to be transferred to another computer. I'd really like to go with client-server because I wouldn't have to deal with the synchronization issues involved with peer-to-peer. In addition I don't want a game to be bogged down by one slow computer on the network. From what I can tell though, most RTS games (if not all) to date have used a peer-to-peer architecture. Does anyone know of an RTS which has successfully used a client-server system? Can anyone convince me instead to use peer-to-peer? Thanks for everyone's help so far, your responses for my previous question have been really helpful. -Sam |
From: Jamie F. <j.f...@re...> - 2000-11-24 21:25:34
|
I believe there are already games out there using floating servers, which can shift from one machine to another. Some Grand Prix game did it, I think... Grand Prix Legends? Not sure. Anyway, I don't know owt about it, so I'll shut up now :) Jamie Samuel McGrath wrote: > > In this instance DirectPlay is probably most appropriate for peer-peer > > networking games such as Age of Empires and so on. > > Ah hah, which brings me to my next question! The type of game I'm writing > is an RTS, and I've been wondering which architecture to go for, > peer-to-peer or client-server. I feel that computers generally are fast > enough these days, and our game is not too demanding (i.e. we're not > dealing with a million units) for one computer to handle the entire > simulation and distribute information to each client. I can think of a > few problems with client-server though, one of which is if the player > running the server loses early, he/she is not necessarily going to want to > sit through the rest of the game..i.e. server responsibility would have to > be transferred to another computer. > > I'd really like to go with client-server because I wouldn't have to deal > with the synchronization issues involved with peer-to-peer. In addition I > don't want a game to be bogged down by one slow computer on the network. > >From what I can tell though, most RTS games (if not all) to date have used > a peer-to-peer architecture. > > Does anyone know of an RTS which has successfully used a client-server > system? Can anyone convince me instead to use peer-to-peer? > > Thanks for everyone's help so far, your responses for my previous question > have been really helpful. > > -Sam > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list -Virus Scanned and cleared ok |