Paima events

[acedward]

New packages

@paima/events

This PR introduces an event system and also sets up the events to use typebox so that it is both strongly typed and so that we can later export them as json-schema for documentation purposes and so that it works well with the json-schema we'll use for the log system

• doesn't solve the ENV issue
• disable external users from sending messages to the engine/batcher (I believe this can be done with this)
• add more status options to the batcher event
• don't only send block events when a block is non-empty (non-empty should maybe just be a filter on blocks?)
• fix the issue where block events may be skipped if paima engine shuts down (see Handling shutdowns in event listeners in Emit event standard for games #373)
• Disable MQTT reserved keywords (/, +, #) in event names
• test this PR

Define an event

const QuestCompletionEvent = genEvent({
  name: 'QuestCompletion',
  fields: [
    {
      name: 'questId',
      type: Type.Integer(),
      indexed: true,
    },
    {
      name: 'playerId',
      type: Type.Integer(),
    },
  ],
} as const);

Listen to Messages

Listen to an event

PaimaEventManager.Instance.subscribe(
  {
    topic: QuestCompletionEvent,
    filter: { questId: undefined }, // all quests
  },
  event => {
    console.log(`Quest ${event.questId} cleared by ${event.playerId}`);
  }
);

Send Messages

Sent an event

PaimaEventListener.Instance.sendMessage(
  QuestCompletionEvent,
  {
    questId: 5,
    playerId: 10
  }
);

@paima/broker

Start MQTT Server

new PaimaBroker(ENV).getServer('Paima-Engine');

This creates a WebSocket MQTT server

Tarochi Example (with Batcher)

Screen.Recording.2024-07-15.at.12.30.55.mp4

Card-Game (Direct TX)

Screen.Recording.2024-07-15.at.17.20.15.mp4

Overview

[SebastienGllmt]

?

[acedward]

This is something I'm still looking into. Waiting for confirmation adds a couple of seconds.

[acedward]

I've set up an ENV variable for this.
There looks like no great solution, but it can take 3-4 seconds to get the confirmations.
When using the paima-events you want to know the input-hash quickly, and expect to be posted eventually.

[SebastienGllmt]

what is the rationale for the /sys/ prefix here? What is the naming convention you're following?

[acedward]

https://docs.aws.amazon.com/whitepapers/latest/designing-mqtt-topics-aws-iot-core/mqtt-design-best-practices.html#:~:text=Since%20MQTT%20topics%20are%20case,when%20creating%20each%20topic%20level.

for paima events
/system/engine/stf
/system/batcher/hash/{hash}
...

for game events
/game/whatever

[SebastienGllmt]

Probably better to define these inside the if block instead of up here. Also, I think it's generally safer too use IIFE instead of using let like this to avoid the variables accidentally going unasigned during refactoring

[SebastienGllmt]

Is this meant to be commented out?

[SebastienGllmt]

Again, is this meant to be commented out?

[SebastienGllmt]

We have 8883 and 8884 hard-coded in many places despite them being specified here. I think it's because in a lot of places we return undefined as a possibility even though these config files are meant to avoid the undefined case

[acedward]

This is the issue with the 'complex' interface.
This module can be called by paima-engine and the batcher.

They do not share a common interface for ENVs so one alternative is:

import type { ENV as ENV1 } from '@paima/batcher-utils';
import type { ENV as ENV2 } from '@paima/paima-utils';

...
constructor(private env: typeof ENV1 | typeof ENV2) {}
...

this.env.I_CAN_USE_METHODS_DEFINED_IN_BOTH

But this made the Interface have to pass the global ENV (not very nice)