beginning networking

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.

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

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

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

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

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.

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...

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.

"TCP is NEVER a better choice"

Sorry, but anyone who makes a blanket statement like that is obviously either not thinking things through or doesn''t know what they''re talking about.

They tried using tcp for position data updates

If you madly broadcast data updates, then udp is what you use; for files, or events you use tcp. Chatting or purchases should probably use tcp. Thats the type of data broadcast they were designed for.

What would you do to send a file with udp? Serialize it and re-order it on recieve? just use tcp

There''s no reason why you can''t use both in a game.

Right, each has a place that it is appropriate for.

okay, now, where can i get some good udp tutorials or good books on udp using winsock, or directplay, whatever...

a2k

there are 2 well respected books on Winsock:

Winsock 2 by Lewis Napper
Windows Sockets Network Programming by Bob Quinn

I see. Really thanks all of you that answered my questions.

But I have another question about my game:

1. For the single player game, it is obvious that all AI should be handled by the player''s computer, but for the multiplayer game, would it be better to randomly select some players(clients) to handle the AI of computer players?

2. If one of the human player is disconnected from the network, is it good to replace the disconnected human player with AI of computer players which is handled by a randomly selected player from the rest?

Thanks for your help.

Longbow.

A good idea would be to figure out which computers have the fastest processor / most ram / best network connectivity and have some kind of ''election'' based on that whenever anyone joins or leaves the game.

I''d probably just run my AI on the server for simplicity, but I can see a few cases where there is just too much AI to do on the server.