LambdaHack-0.2.10.5: A roguelike game engine in early and active development

Safe HaskellNone

Game.LambdaHack.Common.AtomicPos

Description

Semantics of atomic commands shared by client and server. See https://github.com/kosmikus/LambdaHack/wiki/Client-server-architecture.

Synopsis

Documentation

data PosAtomic Source

The type representing visibility of actions to factions, based on the position of the action, etc.

Constructors

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 !FactionId

faction and server notices

PosSer

only the server notices

PosAll

everybody notices

PosNone

never broadcasted, but sent manually

posCmdAtomic :: MonadActionRO m => CmdAtomic -> m PosAtomicSource

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., DisplaceActorA 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 MoveActorA of the illuminated actor, hence such DisplaceActorA should not be observable, but MoveActorA should be (or the former should be perceived as the latter). However, to simplify, we assing as strict visibility requirements to MoveActorA as to DisplaceActorA and fall back to SpotActorA (which provides minimal information that does not contradict state) if the visibility is lower.

breakCmdAtomic :: MonadActionRO m => CmdAtomic -> m [CmdAtomic]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 posCmdAtomic that is visible. The original actions give more information not only due to spanning potentially more positions than those visible. E.g., MoveActorA informs about the continued existence of the actor between moves, v.s., popping out of existence and then back in.