HomePage RecentChanges

This wiki was last modified more than half a year ago and will be deleted eventually!

GameItems

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).

Using Cookies

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.


CategoryGameplay

Discussion

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

I was thinking along these lines too. What is needed are basically two classes of items.
The first class are items that are needed for the gameplay, that provide various bonuses, spells, counters, etc. They would unevitably work only locally, within one domain, and they can disappear when the player is away from that domain.
The other class are the “artifacts”, items used for customizing your character. Most of them have only decorative purpose – your clothes, additional accessorys like glasses, hats, masks, maybe even wings or tails. They need to be persistent in order to keep your avatar looking the way you want. There could be probably a way to “convert” normal items into artifacts, stripping them from their scripts.
Another set of items that would have to qualify as “artifacts” are the tools used for editing maps, if this approach will be chosen. They are scripted, but the scripts only work when the player has “access” to the map he’s on.
I’m still a little concerned about the items disappearing when leaving the domain. That’d make the players very careful, or even paranoid, about portals. You don’t want to lose 2 hours of play just because you got teleported. Any real-time limit would be awkward too.
On the other hand, cheating with the non-artifact items is just cheating yourself – after all, the puzzles are single-player game, and there is noone else you can cheat. – RadomirDopieralski?

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)

If all the player character information (on given FloatingIsland) is stored in a single signed cookie, then I think we can have normal item management, as long as we don’t allow to trade the items between player.
What I mean, is that even if a player “cheats” and returns to an older signed cookie, the whole state is changed, so also everything he gained is lost – he’s back to where he was, back with the experience points, hit points, items, non-defeated monsters, etc. he had.