Safe Haskell | None |
---|
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
- resetsFovCmdAtomic :: UpdAtomic -> Bool
- breakUpdAtomic :: MonadStateRead m => UpdAtomic -> m [UpdAtomic]
- breakSfxAtomic :: MonadStateRead m => SfxAtomic -> m [SfxAtomic]
- loudUpdAtomic :: MonadStateRead m => Bool -> FactionId -> UpdAtomic -> m (Maybe Msg)
- seenAtomicCli :: Bool -> FactionId -> Perception -> PosAtomic -> Bool
- seenAtomicSer :: PosAtomic -> Bool
- generalMoveItem :: MonadStateRead m => ItemId -> Int -> Container -> Container -> m [UpdAtomic]
Documentation
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 |
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 PosAtomicSource
Produce the positions where the action takes place.
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., 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 assing 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 PosAtomicSource
Produce the positions where the atomic special effect takes place.
resetsFovCmdAtomic :: UpdAtomic -> BoolSource
Determines if a command resets FOV.
Invariant: if resetsFovCmdAtomic
determines we do not need
to reset Fov, perception (ptotal
to be precise, psmell
is irrelevant)
of any faction does not change upon recomputation. Otherwise,
save/restore would change game state.
breakUpdAtomic :: MonadStateRead m => UpdAtomic -> m [UpdAtomic]Source
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 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.
breakSfxAtomic :: MonadStateRead m => SfxAtomic -> m [SfxAtomic]Source
Decompose an atomic special effect.
loudUpdAtomic :: MonadStateRead m => Bool -> FactionId -> UpdAtomic -> m (Maybe Msg)Source
Messages for some unseen game object creationdestructionalteration.
seenAtomicCli :: Bool -> FactionId -> Perception -> PosAtomic -> BoolSource
seenAtomicSer :: PosAtomic -> BoolSource
generalMoveItem :: MonadStateRead m => ItemId -> Int -> Container -> Container -> m [UpdAtomic]Source