Hey there folks.

Just looking to learn a little more about how game networking is done. Currently I am just toying around with TCP and UDP connections, client server peer to peer etc.

That got me thinking about the best practice / implementations.

I would like to implement a simple multiplayer RPG which does the following;

Multiple players who use simple spells

Can pick up items that drop on the ground

Now I assume that the best practice for the items would be to have a database / file structure like JSON or XML behind it and store these server side. However would I use TCP or UDP to tell the server my player has picked up or dropped an item? I assume TCP due to TCP checking packets for packet loss?

Now this brings me to the multiple players moving and casting spells - according to GafferOnGames UDP is the preferred connection for action games but it is mentioned that where TCP is needed to use TCP. Would a hybrid implementation suit me best?

Any sources / advice would be much appreciated.

Thanks again.

Any sources / advice would be much appreciated.

The Forum FAQ, particularly Q1, Q3, Q4, Q5, Q12, and potentially several others.

Thanks for the links! Worth noting that, at least for Q1, some of the links are broken.

Might also be worth hyperlinking for a question to its answer it that's possible.

Both GameDev and Microsoft re-orgnized and broke old links. It's annoying. It's even more annoying that I can't actually edit the FAQ from the page it's linked at, I have to go through a totally different interface, and I keep forgetting what my second password is (or even what the second link is...)

Which brings me to the subject of permalinks. Permalinks: You should have them. And keep them working!

Agreed! I may have a few more questions but luckily enough the FAQ answered most of them - not sure how I missed it.

Another question - what is the best way to store players / clients? Creating a new socket for each client? Is there a decent tutorial on this?

I've looked in the FAQ but can't quite find what I am looking for. I'm just looking to implement basic position sending for every client connected to the server.

what is the best way to store players / clients? Creating a new socket for each client?

What does "store" mean in this case? "Manage on the server"?

With TCP, you have no option: Calling accept() returns a socket where you talk to that individual client.

With UDP, you also have no option: There is a single socket for the port, and all clients will send to the same socket. Thus, you will have to use the remote IP-and-port data from recvfrom(), and/or a "session id" that you issue to the client, as a key into a look-up table (hash table) to figure out which client is sending the packet. (Note that the session ID, if you use it, must be long, random, and hard to guess, else cheaters may easily cheat.)

I have seen implementations where people create a new socket per client for UDP. Is this viable?

By store I mean...well. Keep track of, as I need a way to determine who I shall send information to.

If I store the location of entities on my server and then I need to send them to one of the players I need the appropriate ID as well as the location to update them.

I have seen implementations where people create a new socket per client for UDP. Is this viable?

Have you? I'd be surprised. That's a very poor choice, because it wastes resources with no perceptible benefit.
Also: "socket" and "port" aren't the same thing. For a second UDP socket to make sense, it needs to listen to a new port. Switching ports makes firewalls, as well as NAT, harder to deal with.

By store I mean...well. Keep track of

Any computer science curriculum will tell you that when the problem is "how do I look up this data based on a key" the answer is "use a hash table."

It was only one or two places that I'd seen that had suggested creating a new socket. Perhaps I had misunderstood what they had written and they meant they created a new socket to listen for different information but it seemed they had a socket per client.

Thanks for the advice.