beginning networking
Author
okay, i''m about ready to code some network stuff, but i''m still skeptical about me actually getting it to work.
1) it''s a simulation/racing game, and i don''t think sending input states will be enough. i need to send absolute values, don''t i?
2) i should go udp, right?
3) how the hell do i code the server? i know (correct me if i''m wrong) that i have 2 options.
let the server do all the logic, and let the clients render, or let the clients do everything, but have the server just distribute the data.
4) is this actually doable? i''m so skeptical about synchroniztion and stuff. i''m sure the best thing to do is TRY it. (but i don''t have any good winsock udp articles/tutorials. i don''t know how to code for udp)
5) i''m thinking about 8 player lan, and 2 player over internet. does this sound reasonable for a simulation game?
thanks for any help/answers.
a2k
1)Sending absolute positions is normally what I prefer. It makes sense if you''re going to have to do collision detection alot anyway.
2)For a racing game? Yes.
3)In your case, I would suggest having each client perform all work for the person playing on it, and just send position / vector / heading updates to the other players.
4)Yes, it''s actually a very good first application to try your hand at networking. You have 2 options... Winsock or DirectPlay. Despite rarely suggesting DirectPlay, some people find it easier. You might want to look at both before deciding.
5)Sounds reasonable to me.
2)For a racing game? Yes.
3)In your case, I would suggest having each client perform all work for the person playing on it, and just send position / vector / heading updates to the other players.
4)Yes, it''s actually a very good first application to try your hand at networking. You have 2 options... Winsock or DirectPlay. Despite rarely suggesting DirectPlay, some people find it easier. You might want to look at both before deciding.
5)Sounds reasonable to me.
1) Sending absolute values (actual positions of objects) would be preferable over sending input states because this will ensure all clients have the same game state at all times.
2) For a racing game, UDP would be preferable for the following reasons
- it is faster than TCP.
- occasional dropped packets can be safely ignored. The game state will be updated in the next packet.
3), 4) and 5) same as JonStelly
Steve 'Sly' Williams
Tools Developer
Krome Studios
2) For a racing game, UDP would be preferable for the following reasons
- it is faster than TCP.
- occasional dropped packets can be safely ignored. The game state will be updated in the next packet.
3), 4) and 5) same as JonStelly
Steve 'Sly' Williams
Tools Developer
Krome Studios
Author
oh yeah.
thanks, guys. those are the answers i was looking for. now if only i could get a hold of a good winsock book, or a good direct play tutorial/book. i''ve successfully been able to create tcp winsock apps, but not very advanced. i''m gonna look into direct play if there''s enough material on it. thanks again.
a2k
thanks, guys. those are the answers i was looking for. now if only i could get a hold of a good winsock book, or a good direct play tutorial/book. i''ve successfully been able to create tcp winsock apps, but not very advanced. i''m gonna look into direct play if there''s enough material on it. thanks again.
a2k
As we are on the subject of winsock, I''m currently in the proccess of planning to create a server/client system, to distribute ''database'' style data over a network. Anyone know any good tutorials, I can''t seem to find any.
-Lethe
-Lethe
Hello, I am new to network game programming. I am going to code a real time strategy game just like Warcraft. But I am not sure
about the following before start writting the game.
1. Should I use TCP or UDP?
2. Would it be better to leave all logic at the client-side and leave the data synchronization to the server only?
3. Is there any books in the market/documents that can help me more on DirectPlay or Winsock?
Thanks for helps.
Longbow.
about the following before start writting the game.
1. Should I use TCP or UDP?
2. Would it be better to leave all logic at the client-side and leave the data synchronization to the server only?
3. Is there any books in the market/documents that can help me more on DirectPlay or Winsock?
Thanks for helps.
Longbow.
Author
you know, you might be able to get more responses if you started yer own thread, but i''d like to know the answers to yer questions, regardless, too.
a2k
a2k
No need new thread *grin*...
1)TCP - The minor latency/overhead added by TCP over UDP is going to be almost nothing in a game like Warcraft. If you go UDP, you''ll have to go through the motions of making it reliable *depending on how you implement movement* so you''ll just be duplicating TCP.
2)Distributed - I would handle all movement / construction on each client. I''m assuming for a game like that, you would have more of a peer setup, and not so much of a client/server. In other words, the server would be a client. Anyway, For movement, I would just send the unit that someone selects and the position they want them to move to. You then just have to be sure that your movement AI will always generate the same path given 2 points in space. That''s not too tough. For construction, simply send a "Unit X is building a building Y at location Z" to the clients and let them time when it is complete etc... Only thing I would use the server for is to handle combat and distribute the other messages.
3)Winsock 2.0 by Lewis Napper is a great Winsock book. There is another book "Network programming in Win32" but it''s somewhat more advanced, and covers more than just Winsock. I have yet to see a book that really covers directplay, but Inside DirectX *the latest version* has some info if I remember correctly.
1)TCP - The minor latency/overhead added by TCP over UDP is going to be almost nothing in a game like Warcraft. If you go UDP, you''ll have to go through the motions of making it reliable *depending on how you implement movement* so you''ll just be duplicating TCP.
2)Distributed - I would handle all movement / construction on each client. I''m assuming for a game like that, you would have more of a peer setup, and not so much of a client/server. In other words, the server would be a client. Anyway, For movement, I would just send the unit that someone selects and the position they want them to move to. You then just have to be sure that your movement AI will always generate the same path given 2 points in space. That''s not too tough. For construction, simply send a "Unit X is building a building Y at location Z" to the clients and let them time when it is complete etc... Only thing I would use the server for is to handle combat and distribute the other messages.
3)Winsock 2.0 by Lewis Napper is a great Winsock book. There is another book "Network programming in Win32" but it''s somewhat more advanced, and covers more than just Winsock. I have yet to see a book that really covers directplay, but Inside DirectX *the latest version* has some info if I remember correctly.
I think you two missed his sarcasm.
and I heard a rumor that the guys at lucus tried using tcp for xwing-vs-tie fighter... and they confirmed that it doesn''t work...
and I heard a rumor that the guys at lucus tried using tcp for xwing-vs-tie fighter... and they confirmed that it doesn''t work...
Magmai, X-vs-Tie is a different type of game than Warcraft. As a rule, any game where the user is in direct control of their character *i.e. slide right, slide left, go forward, go back* UDP is probably the answer. For games like warcraft where some type of game AI handles the movement of the individual units, *i.e. unit X, go to position Y*, TCP is probably the better choice. There are exceptions to that rule, but it''s a good way of deciding which one is right for you.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
