LambdaHack-0.6.2.0: A game engine library for roguelike dungeon crawlers

Safe HaskellNone
LanguageHaskell2010

Game.LambdaHack.Atomic.PosAtomicRead

Description

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

Synopsis

Documentation

data PosAtomic Source #

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.

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 (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.

generalMoveItem :: MonadStateRead m => Bool -> ItemId -> Int -> Container -> Container -> m [UpdAtomic] Source #

Generate the atomic updates that jointly perform a given item move.