Im a total newb to networking programming, and im somewhat experienced in windows programming and very experienced in C++ under DOS. That said, I want to make a game that is multiplayer where one person hosts and others join the game running on the host. So here are my questions: 1. I was wanting the host computer to host the game and the players will only join a game (not be able to host their own). So is it easier to have two seperate programs? One Client and one Server? Or would it be simpler to have it all one app, and anyone can host or join a game? 2. Should I use DirectPlay? I see that DirectPlay is no longer supported in the future versions of DirectX, and I hear it was really just a wrapper for Winsock anyway. I tried to learn DirectPlay a year ago, but didnt get very far. Or should I just learn Winsock (I know totally nothing about it). What do professionals use for networking? 3. What tutorials or documents should I brush up on before doing a game like this, I can do text for graphics, and im pretty comfortable with the basic windows programming, so what all would I need to know before I start a network game, since I hear they need to be planned out well before one begins. 4. What is the best layout for a network game, what model should I use as for where data is kept, (local to client, or remotely on server) and any other things I should be considering or thinking about. I know this is a big post, sorry if its a pain to read through, but I really appreciate this forum and anyone who responds, thanks again.

Selethd,

I too was new to network programming prior to starting out on my current game, but now feel much more comfortable with it and am well on my way. I'll attempt to answer your questions from my experience (which has been over the last 4 months) and hopefully can help get you that much closer to being on your way :).

1. One big thing here is whether your game is going to be fully 3D using DirectX or OpenGL, or a simple 2D game written using the Windows GDI. I looked into both possibilities and decided to go the first route, that being two seperate applications. This is great if you are 100% sure that the person playing the game would never either host the game, or the server requires so much processing time that running a client on top of it just wouldn't work. As well, this means your server can run full tilt while clients are constantly updating it.

At this point in my project I see ther merits of both, with the client/server being included within the same application, you can save on lots of duplicate code or having to setup a somewhat more in depth solution and leave files in a "common" folder if they're used by both client and server.

2/3. I started out with DirectPlay and later switched over to raw UDP using Winsock and added in my own reliability layer. You also have the option of using TCP/IP which works well if you're not doing a fast action game such as a FPS. The majority of games I've played use Winsock and UDP as their transport protocols with only a handful that I know of implementing a DirectPlay networking interface. If you want to learn more about Winsock, here's a simple tutorial for you to follow to setup a sample Client/Server architecture over TCP/IP:

MSDN Winsock Example

As for planning, make sure you hav a solid architecture, and that any object that may require access to the buffer to be transmitted over the network can get at it, or at least add to an existing message. Small things like this can really start to become irritating over time, so you're better spending more time analysing at the start than diving right into the code.

4. The general idea behind a client/server architecture is that the server stores all critical data to not only help keep clients in sync but reduce the risk of cheating. I'd highly recommend you go with this format as opposed to the client's storing all state locally. That said there will be certain state you'll have to store both locally and remotely, but when the server puts it's foot down it's got the last say ^_^.

Hope some of this helps you understand a little more of what you're getting into. It's a great learning experience and something you definitely won't regret...can never have too much knowledge ^_^.

Best of luck,

Permafried-

Strange,

I compiled and ran this and everything worked out just fine...it may become a slightly large post but post first your client source and then your server source, maybe something was a little off even if you did just copy and paste it. If not I really couldn't tell ya what's up but it's worth a look anyways.

It looks like you're getting to this line and it simply returns which is why you're not even seeing the Connection Closed message or anything:

if (bytesRecv < 0)
return;

Add the following code just before the conditional statement above and see what value it prints out....as a general rule any error from Winsock will return SOCKET_ERROR which = -1:

printf( "Error: %ld\n", bytesRecv );

Permafried-

One last question. If I am going to make a pong clone, multiplayer with winsock, using server client setup.

What should my server look like?

I want the server to actually be running the game, and sending updates of paddles and ball positions to clients.

I want clients to display paddles and ball, and send input to server

So should my server be a console app? or for a real time situation, do you need async sockets that would require a win32 app?

And how often should the server send the clients updated info?, every frame or a certain time interval?