Hello, I probably have a stupid question, but no answer for myself, so that's why I'm bugging this forum :-) In a multiplayer game with > 1 players, and some item (health pack, ammo, etc.) to be picked up, how it is decided which player will get if they click almost (from their own point of view) on the item? The issue is not which to pick - you will always find one who can be declared first - the issue is how to make this reasonable to those who didn't get the item ("I did see the thing, why it wasn't there to pick up when I still see it?"). Or, is this of no practical relevance in Multiplayer (I currently doubt)? Thanks Alex

This sounds more like a level design or gameplay issue at a more higher up level then I think you are realizing from the direction of your post.

For starters, lets make one thing here clear, someone HAS to be able to pick it up correct? Now will this have an impact on the players stature compared to another player? If this is the case, then a "race for items" should be exactly what you want, and the first person to grab it (quickest clicker) should get it, you could take into consideration there location by making them be a certain distance from the item before they pick it up, but in the case of FPS like games, its imparative that people "fight" over these resources anyways.

But if everyone is fighting over 1 item, then you have much bigger issues that you need to address. Perhaps you dont have enough strategic locations in a level? or perhaps if the battles are longer you need to actualy spawn the items? If you are forced to race someone with a segnificant advantage to get an item, the player that is suffering the disadvantage should instead go a different route to recoup his losses. It should never come down to "who clicked it first".

If you are refering to some sort of action strategy game, just make it location based as beforementioned. If you have to be right on the item to get it, then that removes most problems of "someone grabbing it first"

If you are refering to looting, then an oft-used solution is to making sure that the item is reserved for the player with the kill for a set amount of time. If its not from a kill.

Well, my question was more related to looting and similar stuff. But the problem seems to remain here - you have to consider which player was the one killing the monster. Doesn't that lead to some weird and nasty things (i.e. when a player slays the monster with a axe for some minutes, but some other waits in the back and uses a crossbow to finish the job from a safe place)?

(Oh, and yes, it seems to be more gameplay-related but untile someone moves the threadit will unfortunately reside here).

Quote:Original post by starmole
Well, my question was more related to looting and similar stuff. But the problem seems to remain here - you have to consider which player was the one killing the monster. Doesn't that lead to some weird and nasty things (i.e. when a player slays the monster with a axe for some minutes, but some other waits in the back and uses a crossbow to finish the job from a safe place)?

(Oh, and yes, it seems to be more gameplay-related but untile someone moves the threadit will unfortunately reside here).

Ninja-looting.

This is completely and entirely design issue.

Common solutions:
- Last person to hit gets the loot
- Lottery loot. randomly choose one of participants (damage-wise, by group, by area) to loot
- Free for all. First to click gets the loot
- Pre-assigned. Quest reward
- Cloned drops. Everyone who participated gets a clone of an item.
- Master looter. Only group leader gets to loot
- Damage based. Person who did most damage gets to loot.

All of these have problems, and all have strong and weak points.

The mechanics, as to who clicked first, how lag effects this, etc. are entirely up to you to decide. Server needs to make an authoritative decision. Obviously, methods that are time-dependant are bad. Person with lowest latency will always be at advantage.

So not having a clue right away from the problem was probably right :-(

All these described techniques seem to apply some handcrafted balance rules to create something that is 'feasible' at least (because I have always in networked games the problem that I see things *after* they happen, not *when* they happen), and the amount of this 'reality difference' depends on network load, lag, computer speed and possibly a lot of more things.

But there is of course no general recipe for these things, until we have servers/networks/PCs at the speed of light :-)

Thanks
Alex

Quote:All these described techniques seem to apply some handcrafted balance rules to create something that is 'feasible' at least (because I have always in networked games the problem that I see things *after* they happen, not *when* they happen), and the amount of this 'reality difference' depends on network load, lag, computer speed and possibly a lot of more things.

But there is of course no general recipe for these things, until we have servers/networks/PCs at the speed of light :-)

How fast do electrical signals in CPU/bus/network cables travel? :)

There is only one "truth", namely what server says. How you handle this with respect to client delays is up to you. But since every game with loot out there does not have issues with that, apparently the problem is solvable today.

The answer here lies not in loot, but event sequencing. It applies to every single aspect of games. How do you choose who shot first, who bought the item first, who is ahead of someone when dealing with collision detection.

There is no perfect solution. Typically, games will hide the problem by introducing acceptable delays, or asynchronous mechanisms.
- Combat actions are not FPS instant, but take .25-5000 seconds to execute
- Loot is assigned according to rules, deciding who picks it up
- Trade uses db transaction concepts
- Collision detection enforces client synchronization and warps invalid characters
- Server might act retroactively, by keeping track of client latency, and acting only after slowest person made their choice, and resolve the resulting actions.

Lots of solutions. It just comes down to which problem to apply them to.

Hmm, perhaps my problem was not applying the rules themself. I know that given all stuff that comes in from the clients you can make a definitive order at the server (including network effects for balancing) which is the base for all rules, you then apply the rule and judge.

As an example, you have player A and B (and for simplicity, the 'first attack gets loot' rule). When A and B stand in front of the enemy, they both see their attack probably first because the other players's attack is still on its way from client to network to server to other client. So they have a visual experience that may be contrary to a further (clearly possible) ruling. It is about this appeareance I was asking, not about applying some rule (where always one could be chosen that will result in balanced results).