# 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 `BoardState`s `fn(&RunningGame) -> BoardState`, possibly memoized
in case *creating* the `BoardState` is expensive.