Semantics of atomic commands shared by client and server. See https://github.com/kosmikus/LambdaHack/wiki/Client-server-architecture.
- data PosAtomic
- posCmdAtomic :: MonadActionRO m => CmdAtomic -> m PosAtomic
- posSfxAtomic :: MonadActionRO m => SfxAtomic -> m PosAtomic
- resetsFovAtomic :: MonadActionRO m => CmdAtomic -> m (Maybe [FactionId])
- breakCmdAtomic :: MonadActionRO m => CmdAtomic -> m [CmdAtomic]
- loudCmdAtomic :: FactionId -> CmdAtomic -> Bool
- seenAtomicCli :: Bool -> FactionId -> Perception -> PosAtomic -> Bool
- seenAtomicSer :: PosAtomic -> Bool
The type representing visibility of actions to factions, based on the position of the action, etc.
|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
only the faction notices
faction and server notices
only the server notices
never broadcasted, but sent manually
Produces the positions where the action takes place. If a faction is returned, the action is visible only for that faction, if Nothing is returned, it's never visible. Empty list of positions implies the action is visible always.
The goal of the mechanics: client should not get significantly
more information by looking at the atomic commands he is able to see
than by looking at the state changes they enact. E.g.,
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
of the illuminated actor, hence such
DisplaceActorA should not be
MoveActorA should be (or the former should be perceived
as the latter). However, to simplify, we assing as strict visibility
MoveActorA as to
DisplaceActorA and fall back
SpotActorA (which provides minimal information that does not
contradict state) if the visibility is lower.
Decompose an atomic action. The original action is visible
if it's positions are visible both before and after the action
(in between the FOV might have changed). The decomposed actions
are only tested vs the FOV after the action and they give reduced
information that still modifies client's state to match the server state
wrt the current FOV and the subset of
posCmdAtomic that is visible.
The original actions give more information not only due to spanning
potentially more positions than those visible. E.g.,
informs about the continued existence of the actor between
moves, v.s., popping out of existence and then back in.