# Same Shift Loading System

## Abstract

For as long as maps have existed, they have had the general flow of players selecting the map in the previous shift/round (thus pulling the configuation for a map into `next_map.json`), which would immediately load on the onset of the next round. This system has worked well from a technical aspect (fastest initialization time possible), but the social aspect of selecting maps has left a lot to be desired.

As such, this design doc proposes (or at least tracks several issues pertaining to) a Same Shift Loading System. This system would overhaul the way initialization works in order to address long-standing grumbles with how map voting works, by allowing the playerbase who is imminently entering a round to select the map they want to play in, and only initializing the map upon completion of the vote.

## Goals

1. Provide the playerbase who is intending to play the impending round the ability to democratically vote for the map that the majority of players would like to play.
2. Offer a seamless system that's built into overarching inter-round delay time (the period in which players load into a new round)
3. Provide compatibility for admins to override the vote (by either uploading their own map the round prior or by allowing them to abort the vote and select something else).

## Non-goals

1. Disincentivize the ability for different maps to be played. The general goal of maptainers is to maintain maps, and it becomes hard to do so should maps fall out of such intense favor that it is effectively boycotted. This will likely be an issue with any map voting system that is implemented, but we still really want certain maps to be played on from a pure maintainability standpoint (finding bugs, missing features, etc.)
2. todo?

---

The Ideal Flow would be as follows (there are several considerations that may not be present in the final technical implementation)

1. Round Starts
2. High Priority Subsystems Start Initializing (as well as those necessary for SSVote)
3. SSVote initializes and immediately initiates a vote for a duration
4. Any other subsytems initialize as vote progresses (if possible to be concurrent with vote sleeping/calculating/what have you)
5. SSVote finishes and sends vote to map loading system
6. Map Loads
7. Game Starts with maps that the players in that given round voted for

Do note that it wouldn't make intuitive sense to allow previous-round map voting, the only vote that could and should exist would be at Step 3.

## Alternatives

1. Keep the existing map voting system as-is. It may be possible to have this system exist in concurrent with the existing system, but it might end up being rather confusing to end users.
2. Ban mid-round votes, you can only vote on the next round's map at the start or end of a round.

## Potential Changes

All dependent on technical implementation and current head admin/maptainer desires in relation to map rotation and player population.

## Big List Of Problems In The Switchover

##### Tick them off if considered in your implementation of this design doc. Leave list intact. Add more if you think of them as we want to get as close to exhaustive as possible

- [ ] How to avoid players bombing the vote/immediately disconnecting if they don't get their way?
- [ ] Technical feasability of SSVote operating during background operation (probably not a real issue)
- [ ] Admin ability to abort the vote/override the map (it's likely that we should consider SSmappping firing to be the point of no return, and any desired changes would require a world reboot)
- [ ] Preserving admin-uploaded map functionality
- [ ] How long should the ideal delay be between world boot and SSvote firing? Balancing round wait times and players connecting.
- [ ] Presenting latejoiners with the vote.