Project Formation Algorithm Improvements

[bundacia]

Strategic Goals Impacted

• !Game is balanced
• !Learner stats match our subjective reality, elicit honest feedback, and promote self-directed, collaborative growth

Overview

1. Players ELO is calculated. Players have an Elo-based ranking game-prototype#9
2. Pool Formation
   • Moderator initiates cycle
   • Different voting pools are formed and players are assigned to them
   • Players vote in their separate pools
3. Project Formation
   • Moderator launches cycle
   • Project formation algorithm places players within each pool on projects and distributes advanced players from within the pool to the projects

Game configuration

See LearnersGuild/echo-cli#82 for more info on how the moderator configures the game.

Pool formation

Pools are formed when moderator initiates a cycle and are given unique identifiers, and players are informed of which pool they were assigned to. Advanced players are also informed of their pools but they are not treated any differently at this point.

Note: The moderator will need a log of players that shows how many times they were assigned as an advanced player in previous cycles so they can configure the game in such a way that non-paid advanced players rotate.

Project formation

Project teams are formed only by players already within their pool. There is no cross-pool poaching, borrowing, lending, or anything like that. When comparing players experience levels, their Elo-ranking is used.

Constraints

• No team size of 1
• Team thresholds specified by moderator should constrain number of teams that a player can lead based on their rating
• 1 goal per advanced player: If an advanced player is on multiple projects, they need to be based on the same goal
• Only assign players that have voted
• Only form teams within -+1 of recommended team size.

Prioritized Optimizations:

1. Maximize number of team sizes that are the same as the goal’s recommended team size
2. Maximize number of non-advanced players assigned to a goal that they voted for (weight secondary goal choices at %70 of primary goal choices)
3. Maximize number of advanced players assigned to a goal that they voted for
4. Minimize teams of size 2

Additional nice to have optimizations (in order of priority):

1. Minimize the number of teams a player is on
2. Maximize team novelty: put people in new team configurations
3. Minimize maximum number of times any of the players was "shafted" (not assigned to their first or secondary choice in previous cycles)
4. Minimize difference between advanced player and average Elo in rest of the team
5. Maximize number of different goals that are selected

Plan of Attack

I (@bundacia) plan to work through this epic in roughly this order:

1. Improve the algorithm so that it obeys all the new constraints and is "pool-ready" (game Project Formation Algorithm supports new config & constraints #426)
2. Add the ELO stat for players (game Players have an Elo-based rating #422)
3. Create pools based on ELO when a new cycle is created (game Voting Pools are formed when moderator initiates a cycle #427)
4. Allow moderators to configure the pools with /cycle init (moderators can configure pool- and project-formation algorithms using the CLI echo-cli#82)
5. Change vote API/UI as needed to make sure votes happen within a pool (game voting results are displayed grouped by player pool and goal #421)
6. Run new algorithm in each pool instead of show the entire chapter (game project teams are formed within voting pools using Elo-ranking #423)
7. Make UI changes so players can see their ELO ranking (Players can see their Elo-based rating #425)
8. Allow moderators to see how often players have been advanced players (moderators can determine how many times each player was an "advanced player" on a team echo-cli#83)

References

• pool and project formation v1 (game mechanics design issue)
• players have an Elo-based ranking (game mechanics design issue)

[jeffreywescott]

Updated title and description from Team --> Project

[jeffreywescott]

@shereefb pulled out your nice-to-have into its own issue: #420

Not making it part of the main epic, but will add to Backlog in case we can get to it.

[shereefb]

@jeffreywescott makes sense that nice to haves are in #420 . One thing to note is that some of them might be cheap to implement (or even free to implement) so it's worth referring to the issue just so that whoever is implementing can keep in mind.