Struct Interactor 

pub struct Interactor<'l, Storage, Action, Context, Output> { /* private fields */ }

The interface all modifications of the game state go through.

Game state modification is deferred by default. Each change in queued until the end of the function, or Interactor::flush is called. This means all reads will not see any changes made after the last flush, if any. Multiple changes can be queued to the same item between flush points, and they will be applied in the order they were queued.

Use Interactor::create to create new items, and Interactor::get to storage existing items. You can queue updates in either case using Pending::update or Existing::update, respectively. With an Existing item, you can read the state of the item by dereferencing it, and use Existing::destroy to destroy it.

Interactors are used in game::Init, player::Init, Interaction, and Reaction. Depending on the usage, an Interactor will have different Context available. For example, in most cases, the Context will contain the game Root, but in game::Init, it does not, as the Root has not yet been created.

Interactors may also have additional optional outputs, depending on the kind. Interactions and Reactions may use Interactor::enqueue_trigger to enqueue Reaction::Triggers, which will start a new Reaction on the server once dequeued. Reactions can also end the game by Interactor::set_game_outcome.

All changes made with an Interactor are transactional: if an error occurs, there is no need to undo any changes you made (even if flushed), just return an error. The changes from that Interactor and all the preceding triggering Interactors will be reverted automatically.

Implementations

impl<'l, Storage, Action, Context, Output> Interactor<'l, Storage, Action, Context, Output>

pub fn context(&self) -> &Context

Extra context available to this Interactor

pub fn create<Create>( &self, create: Create, ) -> Pending<'_, Storage, Action, Create::T>

where Create: Into<Action> + Create,

Create a new item. See action::Create.

As changes are deferred, this method returns a Pending item, which can make updates, but cannot read the item state, as it does not exist until Interactor::flush is called.

pub fn get<T>(&self, id: IdT<T>) -> Result<Existing<'_, Storage, Action, T>>

where Storage: Storage, T: Storable<Storage::State>,

Storage an existing item by id. Returns an error if the item does not exist.

pub fn root(&self) -> &Context::Root

where Context: GetRoot,

Gets the Common::Root object.

pub fn get_root<Root>(&self) -> Result<Existing<'_, Storage, Action, Root>>

where Storage: Storage, Root: Storable<Storage::State>, Context: GetRoot<Root = IdT<Root>>,

If the Common::Root object is an IdT, gets that item.
Equivalent to self.get(self.root()).

pub fn enqueue_trigger(&self, trigger: Output::Trigger)

where Output: EnqueueTrigger,

Enqueues a Reaction with the given Reaction::Trigger.

Triggers are processed FIFO, after an Interaction or Reaction completes, until the queue is emptied. This means infinite loops are possible if Reactions keep enqueuing more Reactions.

Triggers are only executed server-side, and are ignored on the client. If the Reactions are successful, the clients will be updated with the outcomes of the Reactions. If a Reaction errors, all Reactions and the initial Interaction (if any) will be reverted, and the resulting game state will be as if they never happened.

pub fn set_game_outcome(&self, game_outcome: Output::GameOutcome)

where Output: SetGameOutcome,

Sets the game outcome. Once Reactions complete successfully, the game will end, and clients will be notified of the outcome. If this is called multiple times, the last outcome set will be used. If the transaction fails, the game will not end.

pub fn flush(&mut self) -> Result<()>

where Action: Action<State = Storage::State>, Storage: Storage,

Flushes all pending changes to the game state.

Avoid calling this method unless necessary, as it requires exclusive access to the Interactor and is only needed when the updated state of an item needs to be read. It is not necessary to flush at the end of the function, this will be done automatically.

Flush will direct all operations to the item::Storage implementation, which means this may have side effects such as engine events (e.g. entity creation) being triggered. As the Interactor could still fail, this could result in spurious events as the changes are done and undone.

Trait Implementations

impl<'l, Storage: Debug, Action: Debug, Context: Debug, Output: Debug> Debug for Interactor<'l, Storage, Action, Context, Output>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.