Safe Haskell | None |
---|---|
Language | Haskell2010 |
Semantics of atomic commands shared by client and server. See https://github.com/LambdaHack/LambdaHack/wiki/Client-server-architecture.
- data PosAtomic
- posUpdAtomic :: MonadStateRead m => UpdAtomic -> m PosAtomic
- posSfxAtomic :: MonadStateRead m => SfxAtomic -> m PosAtomic
- breakUpdAtomic :: MonadStateRead m => UpdAtomic -> m [UpdAtomic]
- seenAtomicCli :: Bool -> FactionId -> Perception -> PosAtomic -> Bool
- seenAtomicSer :: PosAtomic -> Bool
- generalMoveItem :: MonadStateRead m => Bool -> ItemId -> Int -> Container -> Container -> m [UpdAtomic]
- posProjBody :: Actor -> PosAtomic
Documentation
The type representing visibility of atomic commands to factions, based on the position of the command, etc. Note that the server sees and smells all positions.
PosSight !LevelId ![Point] | whomever sees all the positions, notices |
PosFidAndSight ![FactionId] !LevelId ![Point] | observers and the faction notice |
PosSmell !LevelId ![Point] | whomever smells all the positions, notices |
PosFid !FactionId | only the faction notices |
PosFidAndSer !(Maybe LevelId) !FactionId | faction and server notices |
PosSer | only the server notices |
PosAll | everybody notices |
PosNone | never broadcasted, but sent manually |
posUpdAtomic :: MonadStateRead m => UpdAtomic -> m PosAtomic Source #
Produce the positions where the atomic update takes place.
The goal of the mechanics is to ensure the commands don't carry significantly more information than their corresponding state diffs would. In other words, the atomic commands involving the positions seen by a client should convey similar information as the client would get by directly observing the changes the commands enact on the visible portion of server game state. The client is then free to change its copy of game state accordingly or not --- it only partially reflects reality anyway.
E.g., UpdDisplaceActor
in a black room,
with one actor carrying a 0-radius light would not be
distinguishable by looking at the state (or the screen) from UpdMoveActor
of the illuminated actor, hence such UpdDisplaceActor
should not be
observable, but UpdMoveActor
should be (or the former should be perceived
as the latter). However, to simplify, we assign as strict visibility
requirements to UpdMoveActor
as to UpdDisplaceActor
and fall back
to UpdSpotActor
(which provides minimal information that does not
contradict state) if the visibility is lower.
posSfxAtomic :: MonadStateRead m => SfxAtomic -> m PosAtomic Source #
Produce the positions where the atomic special effect takes place.
breakUpdAtomic :: MonadStateRead m => UpdAtomic -> m [UpdAtomic] Source #
Decompose an atomic action. The decomposed actions give reduced
information that still modifies client's state to match the server state
wrt the current FOV and the subset of posUpdAtomic
that is visible.
The original actions give more information not only due to spanning
potentially more positions than those visible. E.g., UpdMoveActor
informs about the continued existence of the actor between
moves, v.s., popping out of existence and then back in.
seenAtomicCli :: Bool -> FactionId -> Perception -> PosAtomic -> Bool Source #
Given the client, it's perception and an atomic command, determine if the client notices the command.
seenAtomicSer :: PosAtomic -> Bool Source #
generalMoveItem :: MonadStateRead m => Bool -> ItemId -> Int -> Container -> Container -> m [UpdAtomic] Source #
Generate the atomic updates that jointly perform a given item move.
posProjBody :: Actor -> PosAtomic Source #