Mission Map

Introduction

---

The Mission Map block turns course navigation into a fun and playful experience by creating a map with clickable dots – or missions. Each mission takes the user to the corresponding section in the course, but can assume many forms, like side quests, checkpoints or even time bound events. The mission map is automatically built based on a chosen course and can exchange information with the Mission course format.

Architecture

---

The block feeds from section info in a selected course, automatically displaying them in chapters that can be created upon block configuration. A block can have as many chapters as the campaign needs, with no restrictions in terms of responsiveness.

The database model is pretty straightforward, with each block instance associated with the course being a record in the maps table, while each chapter with its correspondent name is a record in the chapters table. Finally, each mission in each chapter is a record in the missions table.

Work in progress

---

Discussions

---

• Activity voting implementation outline
  • Voting is an important part of a user’s journey on Evoke. Once a group enters a mission on the map, they should be able to vote on which activity they – as a group – want to tackle.
  • This mechanic could be implemented in the block as a group voting feature that takes in account each member of every group in a course and opens up a voting session during a certain period of time.
  • Votes could be stored on another table (user_votes as an example) where user_id and activity_id would be associated.
  • There are two possibilities in terms of votes computing:
    1. Time bound: a deadline is configured for the voting sessions so all members of each group in the course can vote during this period. Once the deadline is reached, the choice with a higher number of votes wins, so votes > 0 and this is independent of the number of participants n.
    2. Quorum based: groups start voting and, once the simples majority is reached (votes > (n/2+1)) the choice is declared victorious. There is a deadline for voting too, but users don’t need to wait until then to start the mission.
  • There are two possible edge cases:
    1. No one votes and deadlines are reached. In this case, possible solutions would be:
       • A second round of votes, with nudges to remember users and a closer deadline; or
       • A randomizer that chooses one of the possible voting options to the users (a coin being tossed could be an animation for that).
    2. There is a tie if groups have an even number of participants. Possible solutions would be:
       • A second round of votes with the 2 top voted options, with a closer deadline; or
       • A randomizer that chooses between the 2 top voted options.
  • Once votes are set and session is over, via the Availability API, the block can run a scheduled task via Task API to set the corresponding availability of each activity for each group based on the votes counted.
  • The only requirement for this strategy is that the course is completely assembled before the block voting is configured.
    • This is needed because, when setting up the voting sessions, the admin will need to choose which activities will be associated with each session.
  • The snippet below (extracted from Moodle documentation) demonstrates how to do that:

$restriction = \core_availability\tree::get_root_json([\availability_group\condition::get_json($group->id)]);
$DB->set_field('course_modules', 'availability', json_encode($restriction), ['id' => $cmid]);
rebuild_course_cache($course->id, true);