[Reality] still in effect, the mock you made

glyph at divmod.com glyph at divmod.com
Thu Oct 12 13:30:21 CDT 2006


On 03:32 pm, radix at twistedmatrix.com wrote:
>On 10/12/06, glyph at divmod.com <glyph at divmod.com> wrote:

>This doesn't sound right: If I want to perform an Action in response
>to your Action, my action should definitely not be in the same
>transaction. That's what I was imagining that consequentlyDo
>("respond" in my proposal) would allow you to do. If it doesn't, then
>what *do* you do if you want to run an Action in response?

Whoops.  I remembered that, but forgot to mention that you didn't agree with that conclusion.

Here's my thinking.  _Something_ has to happen in the same transaction, even if it's scheduling another transaction to run.  The basic level of assurance that a system in imaginary needs is this: if the player performs an action that nets them something positive, but something present causes a negative consequence, it shouldn't be possible for the player to manipulate anything in the game state to avoid the negative consequence unless that is explicitly allowed.

This is the reason I chose the word "consequence" instead of "response" to describe these kinds of reactions.  The word "response" implies a discretionary reaction from another player, not an enforced, necessary reaction from the system.

If, for some reason, the consequent action causes an exception (which it really, really never should) then the player's action can't take place either.  It's a bug, but if the player's action fails at least it won't be an exploit.

Later, it may make sense to do something more clever where the later actions are actually independent and are database persistent, but I think that involves more subtle use cases (where NPCs are really their own agents and not direct enforcers of game logic).  Once all the other stuff I've mentioned is implemented, though, it should be easy enough to implement an extended version where the consequence that runs in the same transaction is just something that guarantees that a later scheduled transaction will run some other action.  I believe we can keep that scheduling a separate discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://twistedmatrix.com/pipermail/reality/attachments/20061012/1d2d33f8/attachment.htm


More information about the Reality mailing list