- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sun, 21 Nov 2010 20:16:09 +0100
- To: Toby Inkster <tai@g5n.co.uk>
- Cc: Semantic Web <semantic-web@w3.org>, Linked Data community <public-lod@w3.org>
On 21 November 2010 20:10, Toby Inkster <tai@g5n.co.uk> wrote: > On Sat, 20 Nov 2010 23:43:18 +0000 > Toby Inkster <tai@g5n.co.uk> wrote: > >> One possible addition, that would go way beyond what the CYOA books >> could offer would be for the client to have a stateful store. So when >> you entered a room, there could be a list of room contents which you >> could collect into your store. The objects that you've collected could >> then influence the progress of the game. Probably need to think a bit >> more about how this should work. > > After further thought, this could/should probably be implemented as a > second layer, above the linked data game. > > A stateful endpoint would exist which would be a quad store. When > you began a game, a graph would be created in that store representing > your game - this could be multi-player. The graph would be > prepopulated with triples along the lines of: > > <#object13> game:location <#node12> . > > At each node, you'd query this endpoint to find what objects exist > (and thus can be collected) at that node. When collecting an object > you'd send an update to the endpoint to remove the triple: > > <#object13> game:location <#node12> . > > And add: > > <#object13> game:carrier <#player3> . > > When dropping an object you'd do the inverse. > > The question though is: how far would we want to go to prevent > cheating? For a single-player game, there's probably no reason to worry > about cheating ("you're only cheating yourself"). > > For multi-player, while (in my current model) the client software can > pretty easily prevent cheating, the server software cannot. Do we add > lots of crypto, or do we rely on trust? I think trust will work well to start, but crypto eventually would be neat. It's possible to actually implement parts of the whole sem web layer cake. It's possible to couple this with a Web of Trust, linked to your WebID, or a zero knowledge proof of your WebID. Another thing I've seen is a whole mud run by an trusted Agent Server side that acts as a 'Dungeon master'. Users perform an action, which is relayed to the dungeon master. The dungeon master is trusted to handle the updates etc (e.g. via ACL). > > -- > Toby A Inkster > <mailto:mail@tobyinkster.co.uk> > <http://tobyinkster.co.uk> > >
Received on Sunday, 21 November 2010 19:18:11 UTC