Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Violenza

Questions about net game programming ideas (long)

This topic is 6535 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

my friend and i have done some game programming in the past and would like to venture into some network game development. we were brainstorming and came up with some questions. when programming a tcp/ip game all info is transmitted via fixed-size packets. what if i needed to send a packet to the server regarding the game state but needed to send more info than the packet could hold? break it up over multiple packets? when using the winsock (yes its a VB game *puts on flame retardant suit*) control and the send data method basically what you are sending is a string of text to the receivign computer. how is this really sufficient to handle a fast paced game? if its a string that we have to hold our game-state info in, that means we''ll have to parse every string before we can use it that sounds like a lot of overhead PER packet or is there a better way to do this entirely? what i mean by game-state is the packet would be sending info about all objects nearby, their coords, their vector, etc, etc the game we are thinking about would be an online zelda-esque adventure/rpg game. we''d like people to build houses and buy land, etc so the world map will be constantly changing. instead of hardcoding the maps in a data file somewhere we thought it would be really groovy to have all the maps in database tables that way when someone builds a house on the land it can update the database directly. so when the next person enters that area the game engine will render the screen based off the newest database info. is this feasable? sounds like it would be *really* slow. i figure we are targetting 24-30fps so i''m not sure if speed hit will much of an issue. i reckon much of the performance would be based on that of the database server machine eh? if my idea isn''t realistic id appreciate it someone could point me down a more appropriate path... thanks for any input and thanks for reading =) Mark Mengelt Program Analyst Phoenix, AZ

Share this post


Link to post
Share on other sites
Advertisement
VBs Winsock control can send data as any type, specified by the optional type argument that is passed to senddata after the info to be sent.

The packet size is not fixed length, it is the size of whatever data you are sending along with the overhead size of the header (part of the header info is the size of the packet, but none of this is visible through the VB control) I believer there is a max size, but Winsock will automatically break it up into the appropriate chunks.

TCP/IP is not very well suited to fast paced gaming due to the size of the header which is all overhead info that will slow down your game. Keep packet sizes high to maintain a small header to game info size ratio. If you send along nothing more then a pair of doubles as an x,y coord, then the TCP/IP header is going to be larger then the information you''re sending. I believe the header can be on the order of 16-30 bytes or thereabouts. That''s a lot of overhead for most games.

I''d suggest using Directplay over the VB winsock control. Anything would be more efficient then the VB winsock control.

I also don''t think VB is well suited to developing any game that operates on even a pseudo large scale multiplayer environment that is meant to be realtime. It may be useable if you stick with the DirectX APIs as much as possible (DirectDraw, DirectPlay, DirectInput, and DirectSound - Direct3D if it''s going to be 3D, but that''s just pushing VB even more) And yes, I recommend using DirectInput even over the VB controls. And stay away from VBs variant data type. It''s flexibility comes at the big disadvantage of speed.

Share this post


Link to post
Share on other sites
Try it and find out. The overhead shoudln''t be significant -- at least on C++ it isn''t. Anyway, I don''t know much about TCP/IP, because I''ve never messed with the networking part of programs. You''ll never know until you try!



"If a man does not keep pace with his companions, perhaps it is because he hears a different drummer. Let him step to the music he hears, however measured or far away" --Henry David Thoreau

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Ummm.... theRaskell says:

TCP/IP is not very well suited to fast paced gaming due to the size of the header ... I''d suggest using Directplay...

Depending on exactly what you mean when you say "TCP/IP" you''re contradicting yourself here.

There are three different protocols to think about when talking about network gaming over the Internet: IP, TCP, and UDP. IP is the base protocol. TCP and UDP are built on top of IP. UDP is a very thin layer and it gives you unreliable connectionless communication. TCP is a complex layer and gives you a reliable connection-oriented communication. Straight IP can be pretty much ignored by the vast majority of people.

DirectPlay uses TCP and/or UDP - I really don''t know much about it, but it runs over the Internet so it''s got to use one or the other. Thus using DirectPlay results in *more* overhead than not using it. Whether or not this overhead is greater than whatever overhead would be introduced by rolling your own depends on you. Choose to use DirectPlay or not by the features it gives you and how easy the API is, not whether or not it has some unspecified "overhead".

Fast paced networked games usually use UDP. TCP sounds nice, but most games don''t need absolute reliability. So what if one packet gets lost if you''re going to be getting another one a tenth of a second later which obsoletes the one that was lost.

-Mike

Share this post


Link to post
Share on other sites
you guys have to admit.. there is a certain appeal in doing something in a language that wasn''t really designed for it (i.e. online roleplaying game in VB)

=)




Mark Mengelt
Program Analyst
Phoenix, AZ

Share this post


Link to post
Share on other sites
There is a certain appeal, but only to a point. The main problem with using a tool for something it''s not intendend to do is that there are always drawbacks. In VB the obvious one is speed. As VB (and general computing power) progresses this will be less of an issue. But I know I''d be pissed if I dev''d an entire game in VB and it turned out to be too slow...


Epolevne

Share this post


Link to post
Share on other sites
TCP/IP refers to the TCP protocol (Actually, that''s a bit redundant cause the acronym stands for Transport Control Protocol. UDP stands for Universal Datagram Protocol) Anyways, there was no contradiction. I was talking specifically about TCP. I don''t recall if the VB winsock control supports UDP but I have a vague recollection that it does.

I was referring to the overhead header size that comes with using TCP and the extra effort the protocol uses to guarantee data arrival. UDP doesn''t do this, so it''s far more efficient (and yes, less reliable, but not unuseable). TCP is NOT suited for an environment where you are sending large numbers of small packets of info. You''ll want to lump as much of your data together for sending as possible.

Share this post


Link to post
Share on other sites
It should be noted that there are some very fundamental differences between UDP and TCP besides their reliability, the most significant of which is that TCP is a stream-based protocol while UDP is a datagram-based protocol.

Basically, there's no such thing as a "packet" with TCP. It's a stream of bytes and a single send of 1024 bytes may end up being received as: 1 recv of 58 bytes, 1 recv of 512 bytes, 1 recv of 454 bytes. You have to reconstruct the "packet" on the other side.

With UDP, neither recipt of the datagram nor the recipt order (ie. you could send out 5 UDP packets and get them misarranged) is guranteed. UDP will send the packet all at once so long as it's not too big. I think the max size varies but 8k seems to be a reasonable upper bound.

One unfortunate drawback of UDP is that the packet headers aren't compressed on PPP connections like TCP packets are, so there is more overhead. However, as UDP tends to be the preferred method for games this ends up being somewhat unavoidable... just be aware of it.

I haven't used DirectPlay so it may very well be that DirectPlay supports the illusion of "packets" for both TCP and UDP, and is just converting the data to and from a byte stream if you specify TCP. For VB, DirectPlay might be the best option, but for C/C++ I would weigh it carefully against low-level socket code. Historically, the problems associated with DirectPlay have outweighed its convenience.

Edited by - Kensai on August 29, 2000 3:51:53 PM

Share this post


Link to post
Share on other sites
The main problem with using TCP is not the overhead, but the fact that the connection will stall and buffer other data to ensure that data arrives "at least once, no more than once, and in the correct order". Whereas with a game, you would more commonly want dropped packets to simply be forgotten about and not have your networking system waiting for them.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!