There are a few problems here.

First, fork() doesn't just create a new thread, it creates a new process.

Second, creating a thread OR a process per player is generally way too inefficient. (Although processes may be reasonable, if you want a very strong separation guarantee for data. Most games don't want to pay this cost.)

Third, you are not properly capturing the return value of fork(). You will need the process ID, because at some point, you need to wait() for the process, to avoid creating zombie processes. And fork() may return -1, which you need to treat special, because sending signals to pid -1 is a Really Dangerous Thing (tm.)

Look into select(). This lets you accept and receive data from many players at one time, without blocking the game loop. You can then send messages to all clients by simply iterating over your array of sockets. If you need to serve more than, say, 1000 players in the same process, then select() may start becoming a bottleneck; at that point you can look at various evented I/O mechanisms (such as boost::asio.) However, at that player count, you might also want to stop using TCP and use UDP instead, because you can get more efficiency out of a UDP protocol. You'd then just sit in a loop, reading messages off a single UDP socket, and you can allocate threads to your other players whatever way you want. (Typically, one thread per core, and players handled in a first-come, first-serve manner.)

Blocking happens in the select() call in your code, because you're not specifying a timeout.

Also, what is hClient? Is it a single object instance? Should you really call a Thread() function on the same object for each connecting client? Does the Thread() function block, or spawn a new thread, or what?

There are tons of select() tutorials on the web, which go into much more detail than I can do in a forum post format.

So you have TWO parts that block your main thread: the select() call, and the Thread() call.

You should re-write your logic as a state machine, where everything is queued, and nothing blocks.

If you want to create a thread per client (not generally a good idea) you need to call pthread_create() before you call the Thread function, but remember that the list of sockets is globally mutable, as is your general world state, so you would need to protect any mutable shared state with a mutex. (This is one of many reasons why thread-per-client is bad.)

This is a huge topic, which you have to learn through practice, and reading through the code of other games.

The source code for a number of popular networked games is available for download. You can look at the Quake or Doom III series, or you can look at the Unreal Engine, for examples of things that have worked well.

Not really.

How much experience do you have in game programming? And in networking? Because game networking programming is a skill in itself, that requires that you first understand game programming, and network programming, separately.

If you haven't built some networked application, and some game, already, perhaps you could build a non-networked game and a non-game network application first?