In many games, the player can pick up items like weapons, food, gold …
The “RPGlike” nature of DreamStones makes that GamePlay element expectable.
However, some constraints make it inconvenient to have permanent objects - the data on who owns what object can’t be stored on the server side (the server keeps no player data in memory), and storing it on the client side is limited (You could give an item to a player, but you couldn’t really take it back)
Therefore, game objects should be either ephemeral (disappear between sessions) or definitively owned (a player can’t lose them, can’t give them, etc.).
For permanent objects, the best is probably to assimilate them to spells - the LearningSpells system can be seen as a special way ogf storing permanent objects - it makes much more sense not to be able to give a spell to another player than not to be able to give an Enchanted +3 Sword of Dragon Sensing.
This means that all items will be temporary. To better maintain SuspensionOfDisbelief?, it’s probably better to stick to items that don’t look like they’ll last long. This includes :
Items that players don’t usually expect to see disappear :
So, these items should be mostly avoided in the GamePlay - when possible, getting the same effect with either a spell (“summon sword” ^^) or a less permanent item.
The gameplay now has some boots of water-walking and the like. However, as this page says, they should be avoided. Hmm. Anyway, the gameplay now is mostly technical experimentation, the graphics used are pretty arbitrary, etc. These items disappear out of ChallengeRooms (which may not cause too much dissonance if the difference between challenges and “normal” play is well stressed).
There is a simple way to store any persistent data on the user’s machine. Just use encrypted “cookies”. For example, you could store a list of checksums for owned items in such a cookie, and refuse to use any item not in list. This cannot be spoofed, as the client doesn’t have any access to the key.
There is however still a problem with the user “returning” to his previous inventory by replacing the cookie with an older copy of it. I don’t see a way around it without storing some data on the server (like a list of expired cookie hashes), or making the cookies timeout (but what about the users that don’t visit certain server for a long time?).
Note how you never “lose” items in SecondLife?. Unless you delete them on purpose – but that’s not a problem.
But the solution above could be still useful for counting “charges” on the items.
The problem of “returning” to previous inventories is why I think items should be either fully persistant and un-loseable, as in SecondLife?, or fully ephemereal and stored entirely on the server side the time of a session. Trying to make anything in between (semi-persistant items you keep between sessions but can still lose) is going to raise problems, such as players reverting to their previous inventory, or storing the data persistantly on the server.
Among those, I think that storing the data on the server is accpetable but shouldn’t be the default way of doing things. If a server thinks he has the resources for handling the items of a bunch of players, more power to him.
The advantage of storing data on the player side is also that the same items can be used on several servers, provided they have the right digital signature of the original server. – EmileKroeger
About artifacts: Another important class would be keys, maps, diplomas and the like. Items that can’t be used in most circumstances, but are still valuable. Those kind of things can make good “local” rewards (They unlock plenty of stuff!), and yet not unbalance on the global level.
About losing items: I think it can be (partly) solved by game design; chosing items that can disappear without it being much of a problem. Potions and bombs and the like. Nothing too valuable. Stuff that’s only useful for the local puzzle. – EmileKroeger
(A bit of conversation was moved to PersonalizingYourAvatar)