Magister Engine

Implement the primitives and core of magister in an independant way

• testapp/ has a TUI implementation of playing the engine
• studio/ has a Leptos app for designing cards
• the main directory contains the engine with consists of:
  • a non-reactive publically mutable version of game state: the BoardState
  • an opaque reactive version of game state: the RunningGame

Design Ideas

I will try Domain-Oriented Design, so I’m splitting things into the BoardState and RunningGame.

A BoardState is meant to be externally manipulable, so it relies on having public owned data. Avoid strategies for deduplication, it should be really straight-forward to make w/e changes you want that could be proper game actions from the BoardState.

A RunningGame should be optimized for running a game, and reducers and inferers work with this struct.

I’m keeping the idea for having reducers and inferers, but due to the difference in using DOD, we can change some signatures:

• a reducer is an fn(&mut RunnningGame, act: Action) -> &mut RunningGame, it can now mutate a RunningGame, as RunningGame is no longer responsible for being serializable or externally manipulable in general.
• an inferer is fn(&RunningGame) -> Vec<Action> and should list all the possible actions that can be taken.
• and we need something that can produce BoardStates fn(&RunningGame) -> BoardState, possibly memoized in case creating the BoardState is expensive.