Map release process

--DRAFT--

This page is aimed at mappers that want to release their creations, and expect them to be used in tournaments.

The process is expected to solve problems associated with map releases (inconsistent names, artifacts, long period until the final is released, etc.).

Goals

Having a documented set of steps for map releases aims to:

1. Set the recommended steps required to have consistent map releases;
2. Collect feedback in an orderly manner;
3. Ensure the final version of the map is released as quickly as possible, with the highest possible quality.

Map release process

Step 0. Drafts

• The mapper works on the map on its own.
• Sharing images is ok, but without showing too much.

Step 1. Closed beta

When the mapper decides to show the map to someone, then its time to have a closed beta version, not release to the public yet. The goal is to get feedback from experienced players.

• The map is mostly ready, and this is the stage where the mapper wants to start collecting feedback.
• The map should be sent privately to the beta testers.
• The number of beta testers should be limited - 3 should be enough
• The map name (file) should have the suffix _beta1 (can be multiple)
• The map should not be uploaded to online servers.

Step 2. Collect feedback

• the beta testers provide feedback (see detailed section below).
• the feedback should consist mainly on reporting bugs on the map, flow improvements, angles (...)
• The mapper updates the map and makes a new version: it can be another closed beta version (n+1) OR it can be a Release Candidate.

Step 3. Release candidate

This is when the map is released to the public for the first time. Until this moment, the map was unknown to the public. The goal of the Release Candidates (rc) is to get feedback and make the finishing touches.

• The map name (file) should have the suffix rc1 (can be multiple)
• the public provides feedback (see section below)
• It can be uploaded to online servers, just make a post on #server-admins Discord channel (don't mention anyone)

Step 4. Collect feedback

• the public provide feedback, based on actual matches being played (see detailed section below).
• the feedback is more about item availability and placement. But any feedback is good feedback.
• the map is changed / upgraded, and it can be another Release Candidate, or the Final version.

Step 5. Final release

• The mapper decides to make the final release.
• Between step 3 and this step there should be a period no longer than 30 days.
• The Artifacts mentioned below should be included with the release. They should be worked on before the release.
• There should be no further changes on the map! Ever!

Collecting feedback

Google sheets/forms can be used. Link to template to be added later

Artifacts

The Final map release should include the following artifacts:

• Wiki page of the map (info + links to everything)
• BSP file (uploaded to https://maps.quakeworld.nu/)
• loc file (uploaded to https://maps.quakeworld.nu/)
• Overview of the map: a 'birds eye' view of the map, including major items (to be added to the Wiki page)
• MAP file (optional)
• Small presentation video (optional but recommended)
• high resolution textures (optional)

The link to the files should be on the wiki page.

Generic recommendations

* to be added:

• tips about the video (camquake or similar...)
• examples of birds eye views