LambdaHack-0.11.0.1: A game engine library for tactical squad ASCII roguelike dungeon crawlers

Safe Haskell | None
Language | Haskell2010

Game.LambdaHack.Atomic.PosAtomicRead

Contents

- Internal operations

Description

Representation and computation of visiblity of atomic commands by clients.

See https://github.com/LambdaHack/LambdaHack/wiki/Client-server-architecture.

Synopsis

- data PosAtomic
  - = PosSight LevelId [Point]
  - | PosFidAndSight FactionId LevelId [Point]
  - | PosSmell LevelId [Point]
  - | PosSightLevels [(LevelId, Point)]
  - | PosFid FactionId
  - | PosFidAndSer FactionId
  - | PosSer
  - | PosAll
  - | PosNone
- posUpdAtomic :: MonadStateRead m => UpdAtomic -> m PosAtomic
- posSfxAtomic :: MonadStateRead m => SfxAtomic -> m PosAtomic
- iidUpdAtomic :: UpdAtomic -> [ItemId]
- iidSfxAtomic :: SfxAtomic -> [ItemId]
- breakUpdAtomic :: MonadStateRead m => UpdAtomic -> m [UpdAtomic]
- lidOfPos :: PosAtomic -> Maybe LevelId
- seenAtomicCli :: Bool -> FactionId -> PerLid -> PosAtomic -> Bool
- seenAtomicSer :: PosAtomic -> Bool
- pointsProjBody :: Actor -> [Point] -> PosAtomic
- posProjBody :: Actor -> PosAtomic
- singleAid :: MonadStateRead m => ActorId -> m PosAtomic
- doubleAid :: MonadStateRead m => ActorId -> ActorId -> m PosAtomic
- singleContainerStash :: MonadStateRead m => Container -> m PosAtomic
- singleContainerActor :: MonadStateRead m => Container -> m PosAtomic

# 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. Also note that hearing is not covered because it gives very restricted information, so hearing doesn't equal seeing (and we assume smelling actors get lots of data from smells).

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
PosSightLevels [(LevelId, Point)] | whomever sees all the positions, notices
PosFid FactionId | only the faction notices, server doesn't
PosFidAndSer FactionId | faction and server notices
PosSer | only the server notices
PosAll | everybody notices
PosNone | never broadcasted, but sent manually

#### Instances

Instances details

Show PosAtomic Source # |
Instance details Defined in Game.LambdaHack.Atomic.PosAtomicRead Methods showsPrec :: Int -> PosAtomic -> ShowS Source # show :: PosAtomic -> String Source # showList :: [PosAtomic] -> ShowS Source #
Eq PosAtomic Source # |
Instance details Defined in Game.LambdaHack.Atomic.PosAtomicRead Methods (==) :: PosAtomic -> PosAtomic -> Bool Source # (/=) :: PosAtomic -> PosAtomic -> Bool Source #

posUpdAtomic :: MonadStateRead m => UpdAtomic -> m PosAtomic Source #

Produce the positions where the atomic update takes place or, more generally, the conditions under which the update can be noticed by a client.

The goal of this mechanics is to ensure that atomic commands involving some positions visible by a client convey similar information as the client would get by directly observing the changes of the portion of server state limited to the visible positions. Consequently, when the visible commands are later applied to the client's state, the state stays consistent --- in sync with the server state and correctly limited by visiblity. There is some wiggle room both in what "in sync" and "visible" means and how they propagate through time.

E.g., `UpdDisplaceActor` in a black room between two enemy actors, with only 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` in similar cotext would 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.

iidUpdAtomic :: UpdAtomic -> [ItemId] Source #

All items introduced by the atomic command, to be used in it.

iidSfxAtomic :: SfxAtomic -> [ItemId] Source #

All items introduced by the atomic special effect, to be used in it.

breakUpdAtomic :: MonadStateRead m => UpdAtomic -> m [UpdAtomic] Source #

Decompose an atomic action that is outside a client's visiblity. The decomposed actions give less information that the original command, but some of them may fall within the visibility range of the client. The original action may give more information than even the total sum of all actions it's broken into. E.g., `UpdMoveActor` informs about the continued existence of the actor between moves vs popping out of existence and then back in.

This is computed in server's `State` from before performing the command.

lidOfPos :: PosAtomic -> Maybe LevelId Source #

What is the main map level the `PosAtomic` refers to, if any.

seenAtomicCli :: Bool -> FactionId -> PerLid -> PosAtomic -> Bool Source #

Given the client, its perception and an atomic command, determine if the client notices the command.

seenAtomicSer :: PosAtomic -> Bool Source #

Determine whether the server would see a command that has the given visibilty conditions.

# Internal operations

pointsProjBody :: Actor -> [Point] -> PosAtomic Source #

posProjBody :: Actor -> PosAtomic Source #

singleAid :: MonadStateRead m => ActorId -> m PosAtomic Source #

doubleAid :: MonadStateRead m => ActorId -> ActorId -> m PosAtomic Source #

singleContainerStash :: MonadStateRead m => Container -> m PosAtomic Source #

singleContainerActor :: MonadStateRead m => Container -> m PosAtomic Source #