danfinlay
commented
11 years ago When the client makes a change, it should ideally know the permissions of the server and disallow its own user, say from building in someone else's territory (territories have been a feature of minecraft servers for some time, and should definitely be on our roadmap here). After each modification, the server will always reply with whether those changes were accepted or not, and by default the client should receive that response and stay aligned with the server's world, even if permissions have changed.
As far as creating obstacles, I don't think you'll have luck with creating barriers, since the user can always modify the game object, and hacking it is the whole point, but if a problem is solved correctly, you can stream reward events from the server, say an animation, a message, even a next mission. That way you're not limiting the client world, you're just adding value from the server.
kumavis
In order to to build some challenges/levels, we will need to be able to impart some limitations on the player. For example if there is a gate that must be unlocked by streaming a key through to a lock, it would necessitate not being able to get past the gate by other means ( breaking through blocks, manually setting the avatar position ).
This would also allow you to have public spaces where a trusted some are allowed rights to modify, protected from the anonymous passerby.