I'm working on a learning project of a fairly simplistic multiplayer RPG game as a way to get my head around best-practices etc.

One thing I am wondering is if best practice is to roll all loot drops and item crafting on the server rather than inside the game?

I don't have a lot of experience in game development so hopefully this doesn't seem like a really obvious / embarrassing yes or no! ? 

My thought process was:

1. that if there are two players on a map, and they kill a mob, they need to immediately see identical loot, and;

2. rolling the properties of an item server-side eliminates the chance of hacking local code to spit out top tier items

If the above two assumptions are correct, my second question was how to verify on the server that the player has actually performed the function in-game? (For example, that the crafting materials were actually used, or the monster was actually killed? And that a forged request has not been sent from a modified game client?)

I would expect some sort of "signature" or unique hash to be included, but can't yet understand how that dynamic would work?

33 minutes ago, Sam James said:

One thing I am wondering is if best practice is to roll all loot drops and item crafting on the server rather than inside the game?

I haven't had much experience on massive multiplayer games, but yes my inclination would be to do everything on the server. Dumb client. Usually when you are making 'game calculations' on the client it is either for things that don't matter (e.g. particle effects, non significant physics), or for client side prediction to reduce the visibility of lag on the client (e.g. movement, where client predictions are then compared to server authoritative moves and corrected if necessary).

I can't see an immediate compelling reason to do any of these things you mention on the client.

Do absolutely everything that you can possibly do on the server, on the server.  Ideally you shouldn't even be rendering on the client.  Just send all input events to the server, and send the rendered video stream back to the client.

(Note: rendering on the server consumes a lot of bandwidth that a lot of users don't have, so this is not really practical yet unless you don't mind severely limiting your audience.  However, technology marches on, so expect this to become the main delivery system for online games within the next decade.)

Ok awesome thanks for the replies! What is the most commonly used server side stack for this sort of thing? 

I'm not really a best-practices guru, haha, but!

Generally speaking, most common server side setups are something like a Database/File system for persistence and a UDP server(s) that handles the communications.  As for actual existing software that people use, I dunno, there's a lot of game engines and server frameworks out there. 

For my attempt at Multi-Player Online gaming, I'm using in memory data structures for speed and simplicity, backed by a very simple file system where the server(s) saves small files for each persistent in-game object(easily converted to a database later/if/when needed), with multiple specialized UDP servers for performance reasons.  My authentication and player movement controls(and a few other things right now) are in one server, and economic services(banking/etc) is in another, etc..  The servers communicate with each other directly to maintain changes in shared data(Who's authenticated, what's the encryption key they are using, etc..)

That's something you may want to consider as well is some fast light encryption for sensitive data bits.  I use encryption for sending user data(email addys, passwords, etc..) over the network and things like that.  Anything that I think produces a significant window for a hacker to inject/grab/or change sensitive data, I encrypt it before it goes over the wire.  Creative use of simple hashing can do for some things too.

Anyhow, that's how I go about things.

Happy coding!