Creating my own goroutines / await response of user to resume execution

Runtime Framework
1

Hello!

I am making a card game where cards have effects composed of several tasks that run in sequence.
However, some tasks can ask the player to choose something. (cards’ effects are stored in json as a list of these tasks)

I this case, I could try to store the current state of the task execution and then try to resume it, or I could halt a goroutine waiting on a channel and fill that channel from the MatchLoop.

So my question is: would the nakama runtime get angry at me if I spin up a goroutine that modifies the MatchState?

if this is not he best approach… how should I handle this?

2

Hey @elementalcode I think it depends on how you are modifying the match state and what you are doing with the stored match state after resuming execution.

However, taking a step back, I’m not sure if this is the correct approach. Why is there a need to store match state in the Go runtime and manipulate it in a Goroutine? Why not run the card effects from one piece of match state, and then represent the user choice as a separate piece of match state that is sent to the server?

3

To try to make our effects modular so our game designers can make new cards without touching code, our cards have a series of steps to run these steps can generate artifacts that feed into the next step (very similar to a CI pipeline)

When a step needs the player to pick something, the pipeline kinda halts until the response from the user.

I am investigating if halting a goroutine is the best approach or just remembering in which step of the pipeline we left off to then resume it on the next tick