Sprint 3 is here! What are we doing? Then next logical task we need to do now that how the quests and game data are stored have been worked out, is to make the user aware of the new quest started by the game creation flow. This requires three things:

1. A way to define this first step in the quest data - we can define quests right now, but not what goes on in them
2. A way to read this "new quest" step from the quest data and create a new Issue on Github
3. A way to scan for all of these "new quest" steps (and in fact any other step) in the list of quests ready to be processed so that any new actions the game need to take every tick can be run.

Our tasks look something like this:

In diagram form, our architecture looks a bit like this right now:

Quest Queue

I'm now renaming "Task Queue" to "Quest Queue" as it's now primarily a list of active quests, each of which is either new and awaiting processing, or awaiting some trigger action from the user.

The game's "tick" loop will run every few minutes (I'll tune this to balance cost and processing time), and will mainly scan through this list of quests to check whether an action needs to be taken. But will sometimes schedule new quests to be dropped on users. This means Quests get processed under three scenarios:

• When a user starts a game, the first quest should be processed immedaitely
• Randomly, users should acquire new quests, maybe once every day to a few days
• Whenever users provide a trigger

Triggers

There needs to be a few different triggers that the game must detect to progress the game, although I'm not addressing them this sprint, it makes sense to think about them:

• Comments in reply to Issues. I expect to be able to accept user commenting on issues, to be able to implement simple types of quests along the lines of "I need you to find some deleted text in a previous commit", this allows the game to accept simple text answers to these quests
• Commits. It's a certainty that we need to be able to check commits made by the user, and therefore actually look at the files in there
• PRs. We definitely need to be able to check PRs, as this is an important thing to be able to test

We can poll GitHub for this stuff, but if we want the game to be responsive for players (i.e. be able to respond within a few seconds to minutes of a player's action), then we potentially need to poll for a LOT of stuff from GitHub every few minutes, which is going to be too much, for both them and us. So we need to rely on as many webhooks and notification features as possible. That'll have to be addressed in the next sprints, but it does mean at this point we shouldn't think too hard about building a polling loop as it's probably going to be a dead-end approach.