winsoc2.h lib

[G309216C]

KBW is right listen to his advice.

Not only that but if you are expecting anything above a A I would say forget about it considering, the code itself uses worst technical programming aspects not only that but the lack of indentation would make it a nightmare for other programmers to read. The whole code seems illegal and can cause false detection from Firewalls-Anti-Virus solutions. As this is a game I would imagine this needs some type of injection into native windows process to allow network communication.

A quick read through the code shows that the data is not secure and the network will not have any guarantee to succeed in high latency networks. It may work very well in LAN but over WAN and MAN it is completely useless.

Let alone these but the whole structure of program seems very bad.

But still I wish you get good grades.

[karan124]

@kwb
sir i have game on c++ allegro now i just want to make it multiplayer means two user play same game on different pc (pair to pair networking)
through internet just as server client based..

[karan124]

@spaceworm
i am just new to c++ ,i started 3 months ago and learn this more.....

[kbw]

i have game on c++ allegro now i just want to make it multiplayer means two user play same game on different pc (pair to pair networking)

We've discussed one of these previously on this forum somewhere. I have difficulty finding past posts on this forum; over the years we've covered quite a lot and some talented contributors have provided what in other circumstances would be considered expert consultancy. A lot of that expertise gets ignored by students.

A game has interesting requirements that make it more tollerant of failure than a chat application. A game needs a fast response, but it can also be made to cope with missing updates. That suggests a datagram protocol (UDP) rather than a stream (TCP) as it's not important to keep the session going.

However, many home users are stuck behind firewalls restrict UDP, so that would be a reason to stick with TCP. Anyway, back to your game.

The server needs to exist to allow clients to see each other easily. Also, the server can maintain a game session (or multiple simultaneous sessions), keep score, manage game resources and so on.

Each client sents updates on what it's doing and the server sends an update periodically on what everyone is doing.

For example, consider three remote players in a multiplayer pacman game.

Each player would send direction changes. on demand.

The server would send regular updates with the posistions and direction of all the pieces. If a player missed an update, it could pickup where it left off from the next update.

So the server maintains the set of players and their states, and the game's state. It sends regular updates such that a client can match that state from any given update.

The client sends state changes on demand. So, in our example, if the player does nothing, no update is sent (other than some kind of perioding keep-alive signal).

Really, the problem isn't so much a programming problem. It's an analysis problem. You have to think through what needs to be done, refining uncertain areas until you know what to do. You can only start coding once you know what to do. You can't start by writing code.