Difference between revisions of "Map release process"
From QWiki
m |
m |
||
| Line 20: | Line 20: | ||
===Step 1. Closed beta=== | ===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 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 map should be sent privately to the beta testers. | ||
| Line 27: | Line 28: | ||
===Step 2. Collect feedback=== | ===Step 2. Collect feedback=== | ||
| − | * the beta testers provide feedback (see section below). | + | * the beta testers provide feedback (see detailed section below). |
* the feedback should consist mainly on reporting bugs on the map, flow improvements, angles (...) | * 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. | * 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=== | ===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 map name (file) should have the suffix rc1 (can be multiple) | ||
* the public provides feedback (see section below) | * the public provides feedback (see section below) | ||
| Line 38: | Line 39: | ||
===Step 4. Collect feedback=== | ===Step 4. Collect feedback=== | ||
| − | * the public provide feedback, based on actual matches being played. | + | * 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 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. | * the map is changed / upgraded, and it can be another Release Candidate, or the Final version. | ||
Revision as of 13:26, 21 May 2024
--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:
- Set the recommended steps required to have consistent map releases;
- Collect feedback in an orderly manner;
- 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:
- BSP file (uploaded to https://maps.quakeworld.nu/)
- loc file (uploaded to https://maps.quakeworld.nu/)
- Wiki page of the map (info + links to everything)
- 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)
Generic recommendations
* to be added:
- tips about the video (camquake or similar...)
- examples of birds eye views