add events dummy example to chess

[ecioppettini]

This is not a functional change, just an example application of the current code in PaimaStudios/paima-engine#409 . It's also possible it may not compile, since I'm using local dependencies.

I defined an overloaded event to just to show how it looks, but both events are emitted at the same time (which could be a valid use-case though)

The events table looks something like this:

The joined lobby event was never emitted so it's not there.

The registered_event table looks like this:

The output of mqtt subscribe -h 127.0.0.1 -p 8883 -q 2 -l ws -t '#' -v looks something like this for example:

app/95a54b3250ababba95ca72d9c61a07554d8252746ad2ce711b44c0809adc75ac/user/0x82d9d608030496013587d9e0566509b2e6182afa/lobbyId/7ONFSpzOOwnO {"rounds":500}
app/b8c9872e0f8f4c6b9d9815fd4ff1f8746c6c4ca348911e7cda7fcc4771181ad6/user/0x82d9d608030496013587d9e0566509b2e6182afa/lobbyId/7ONFSpzOOwnO {"rounds":500,"isPractice":true}
node/block/1252 {}
node/block/1338 {}
app/365f0dd042b4225a85c20c6332be58dd5244de021b7778ef5d70d3056c9d5afa/winner/0x0 {}
node/block/1339 {}

[acedward]

the client shouldn't need mqtt
is this some workaround for something not compiling?

[acedward]

same as ``esrun ?

[ecioppettini]

yeah, I forgot I did this. Since I'm mostly just copying the dependencies locally I added this to install it, but normally it would be a transitive dependency.

[acedward]

If types need to be defined with typebox perhaps it should be exposed in paima-engine

[acedward]

It looks like v1 & v2 where defined to have this optional type Type.Optional(Type.Boolean())
It might be better for the insistence as both events have the same name and indexed fields (and there is no way of distinguishing them)

[ecioppettini]

They can be distinguished by the topic (which is at app/topic). Since the topic is the hash of the signature, these will have different hashes, because one has one extra field.

But you could define a single event with the optional field as you say. The thing is that events are immutable, you can't add a field to an existing one, so this was an example of what you would need to do if you want to add a new field. So let's say you forgot to add the field initially, you can add this later for example.

Or if you want to change the type of an existing field you would need to do something similar.

[acedward]

as const required?

[ecioppettini]

I guess not, I probably added it when testing something.

[acedward]

this should have the field lobbyId indexed, and winner not indexed

[acedward]

I think we shouldn't return data by modifying the reference, it works - but as there is no way to tell the programmer this will happen (as in other languages that you can mark as mutable) in the worst case perhaps call it mutableEvents

[ecioppettini]

That's just how I prefer to write it though, there is nothing enforcing one style or the other. I personally always assume that if I pass an array then it may be mutated (in js). In this case there is not really any point in reading from this object, so it has to be write only, but that can be clearer through the name as you mention.

[SebastienGllmt]

This is just a personal preference thing and it's up to each game to decide how they want to do this. This PR is more to decide if the interface of the things coming from Paima Engine itself is good or not

[acedward]

@ecioppettini just a question, this is deterministic, first all stateTransitions get written in order, then events get sent?

[ecioppettini]

yes, if any of the state transition queries rollbacks then nothing gets emitted also.

[SebastienGllmt]

I feel like this should probably have an interface that looks more like what I wrote below since I think this is a lot more clear what is going on

encodeEventForStf({
    from: precompiles.default,
    topic: MatchWon,
    data: {
        winner: results[0] === 'w' ? matchEnvironment.user1.wallet : matchEnvironment.user2.wallet,
    }
});

[ecioppettini]

I updated the interface to look like this (PaimaStudios/paima-engine@63bb369).