Thank you ernow, phear- and Valkoran. I really appreciate you taking the time to share your experience with me.

I suppose that there really is no correct way of implementing such a system. It depends almost entirely on what you'd like the system to be able to do (and then how robust and flexible you'd like it to be, as well).

Thanks guys.

Best wishes,
Sam.

Quote:Original post by ernow

- optionally: move the loot after the timeout to a general loot on the server so others can loot it.

I do not like the final option because I think that loot should fit te player's level. Otherwise you will see a lot of n00bs waiting near battlefields foor high level loot.

What you said here is interesting, and as you said afterwards, depends on the MMO. I quite like the idea that enterprising 'newbies' can acquire loot beyond their level if they are willing to take a risk. You'd have to limit what they can use though, otherwise you might end up with newbies with very unbalanced equipment! :-)

Thanks,
Sam.

Quote:Original post by ernow
Just store the loot on the client

I'd like to point out the number one rule regarding online games: Don't store any important data on the client.

If you were to follow that, there's a chance, even if small, that someone could be using a hacked/unofficial client and could edit their loot, so they could suddently have The Ultimate Holy Crap Run It's Going To Kill Us weapon.

Regarding how loot is generated, the most simple yet effective way i can think of would be to create a table that would contain the loot ID, name, flags, and chance of appearing, a NPC Type table that'd have basic NPC information such as ID, name, flags, stats, and loot IDs, and finally each NPC would be a NPC "instance" that would refer to a NPC ID.

That way you'd only need to store the NPC health and position per NPC, saving up a lot of DB space and even possibly bandwidth.

In my server protoype I have a script file for each monster on the server side which is something like this:

drop1 = "Sword"drop1_chance = 21 //percentdrop2 = "none"drop2_chance = 22drop3 = "none"drop3_chance = 23drop4 = "none"drop4_chance = 24

so each monster can drop 4 items, then theres just an array of items in the server with Sword as the name field, and it would match them up like that.

I like it like this because each monster drops only certain equipment, I could also make a large database with items and just have a monster have a certain chance to drop a random item.

Quote:Original post by nuno_silva_pt

...so they could suddently have The Ultimate Holy Crap Run It's Going To Kill Us weapon.

Heh, you can tell you've played a few MMOs! :-)

I did think that storing things on the client was a bad idea. I was attempting to work out how to 'hack' (spoof / fake) TCP packets when I was fourteen. So yes, there will almost certainly be someone that is 'curious' enough, or determined enough, to give it a fair go.

I wasn't sure whether he meant an RPG rather than MMO in the above instance, though.

Thank you also rgibson11 for sharing your experience. It's good to know how people are actually doing it (even if they are personal projects rather than live MMOs or ORPGs).


Thank you to everyone for your answers. I'm now excited rather than daunted by the idea of implementing such a system (albeit possibly in the far future).

I tend to always be looking for the 'right' way of doing things when in fact the 'right' way of putting the system together is to think it through and work out your needs (as well as to consider pitfalls).

Thanks guys,
Sam.

Quote:Original post by Samuel_XMA
I wasn't sure whether he meant an RPG rather than MMO in the above instance, though.

Well, he was talking about logging out and such, so it should be at least an ORPG.

Quote:Original post by nuno_silva_pt

Quote:Original post by ernow
Just store the loot on the client

I'd like to point out the number one rule regarding online games: Don't store any important data on the client.

If you were to follow that, there's a chance, even if small, that someone could be using a hacked/unofficial client and could edit their loot, so they could suddently have The Ultimate Holy Crap Run It's Going To Kill Us weapon.

Of course you're toast as soon as someone is able to hack the client but not just for loot and other data. A solution might be to only use the client to store available loot. Perhaps even encrypted with a public key.
- Killing an enemy causes a call to the server.
- The server generates an encrypted loot item and passes it back to the client and forgets all about it.
- Picking it up would cause a call to the server passing the encrypted item.
- The server would decrypt with the private key.

This way the client keeps the loot safely.

Quote:Original post by ernow

Of course you're toast as soon as someone is able to hack the client but not just for loot and other data. A solution might be to only use the client to store available loot. Perhaps even encrypted with a public key.
- Killing an enemy causes a call to the server.
- The server generates an encrypted loot item and passes it back to the client and forgets all about it.

So, how does server determine that the powerful axe you are wielding and using to kill other players was actually "available" and "generated by call to server", and it's not just some random item that player conjured up. 500 times.

Quote:- The server would decrypt with the private key.

The problem with encryption is that both, client and server need to know the contents of the payload. As such, they both have adequate information to decrypt and modify the contents. Encryption in this case prevents only man-in-the-middle attacks, which are not an important problem anyway. Strength of key is irrelevant in this case.

The biggest flaw here is that "server forgets about it". If you look at authentication systems, server never forgets about client. Upon login, it generates a secret (something from server, something from client, something random) and uses that to verify actions. This secret is never shared with client, and if server were compromised in appropriate way, the encryption fails.

Simple conclusion is that server must never forget about original item - at which point the concept of storing anything on client becomes moot.

Besides - what advantage would server forgetting about items bring?

Again, my idea is just what it is: an idea about how you could implement it.

The main advantage of the idea is not storing all loot of all players all the time on the server.

As with any option, there are pros and cons.

In my solution the clients doesn't need to know the content of the loot item. and only when an item is picked up it gets pushed back to the server.

Another option would be to mark the potential loot with some stats (player level, enemy level, etc) send that to the client (encrypted), store it at the client, and send that to the server when picking up the loot and have the server generate the actual loot.

The secret you keep is the private key that is kept at the server and that is used to encrypt the data that is stored on the client.

I´ll stop defending my system right here; it was just an example.