nicolodavis

I think you might be conflating boardgame.io and boardgamelab.app.

boardgame.io - MIT licensed open-source JS library.

boardgamelab.app - Proprietary platform for designing and playtesting board games.

I agree that asynchronous flows are hard to represent using a state object.

I chose to go with a monadic approach in boardgamelab.app (I'm not limited by language features since I'm designing it from the ground up for this use case). The language is pure and functional with managed effects. You can express things like:

  set of cards -> filter by action cards -> choose -> [card]
  do stuff with [card]

written in a synchronous style, while under the hood it:

1. suspends the rule.

2. waits for the user to make a choice.

3. resumes the rule with the choice made by the user.

(note: listed above is a simplified text representation. The Boardgame Lab structure editor uses a block-based visual language.)

If written in Haskell, the underlying monad would look something like this:

  {-# LANGUAGE ExistentialQuantification #-}

  newtype Rule a = Rule {fn :: State -> (RuleResult a, State)}

  data RuleResult a
    = Done a
    | forall x. Show x => Choose [x] (x -> Rule a)

  instance Monad Rule where
    m >>= k = Rule $ \state ->
      case fn m state of
        (Done a, state') -> fn (k a) state'
        (Choose list m', state') -> (Choose list (m' >=> k), state')

i.e. each rule returns either a completed result or a choice along with a continuation of the remainder of the rule past that choice.

boardgame.io was created as a personal open-source project while I was employed at Google. It is not an official Google product.

If we're talking about some sort of computational system achieving consciousness, I'm curious how you can escape the fact that computation is observer-relative, i.e. the underlying representation of a computation has no semantics, and requires an external entity to provide an interpretation.

Great to hear about the revival of sacred music in your diocese.

Do you happen to have any links to the documents that your previous bishop wrote?

You could consider using a library like boardgame.io for this.

Do you have specific examples of what is difficult to understand in the standard books for a non-native speaker?

Just asking out of curiosity and maybe readers can learn a thing or two about making documentation more accessible.

That's right. For my use-case I decided to just stick with JS for UI stuff (using Svelte). I call into Rust code like a black box to update some state.

No reason except that I've written Go in the past and wanted to learn a new language :)

Comparing the two languages, I would say that Rust's enums and pattern matching make it easier to work with for my specific use case.

The Rollup plugin linked to in the article produces JS functions that call into WASM code. JS objects are automatically converted to Rust structs via Serde and vice-versa.

I use TypeScript / Svelte for DOM interactions and only call into Rust code for the state updates (treating it like a black box).