Difference between revisions of "Map release process"

From QWiki
 
(3 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
This page is aimed at mappers that want to release their creations, and expect them to be used in tournaments.<br>
 
This page is aimed at mappers that want to release their creations, and expect them to be used in tournaments.<br>
 
<br>
 
<br>
The process is expected to solve problems associated with map releases (artifacts, released, etc.).
+
The process is expected to solve problems associated with map releases (inconsistent names, artifacts, long period until the final is released, etc.).
  
 
==Goals==
 
==Goals==
 
Having a documented set of steps for map releases aims to:
 
Having a documented set of steps for map releases aims to:
 
# Set the recommended steps required to have consistent map releases;  
 
# 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.
 
# Ensure the final version of the map is released as quickly as possible, with the highest possible quality.
  
 +
 +
==Map release process==
 +
[[File:Qw-map-release.drawio.png]]<br>
  
 
===Step 0. Drafts===
 
===Step 0. Drafts===
 
* The mapper works on the map on its own.
 
* The mapper works on the map on its own.
* Sharing images is ok, share whatever you want
+
* 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!
  
===Step 1. Closed test version===
+
==Collecting feedback==
* The mapper may test the map by playing it if they want to, but its not necessary
+
''Google sheets/forms can be used. Link to template to be added later''
  
===Step 2. Release===
 
* The mapper should release the map when they feel that it is completed
 
* If they believe the map can be updated to optimize the map they may freely do that on different filenames.
 
  
 
==Artifacts==
 
==Artifacts==
The Final map release may include the following artifacts:
+
The Final map release should include the following artifacts:
 
* Wiki page of the map (info + links to everything)
 
* Wiki page of the map (info + links to everything)
 
* BSP file (uploaded to https://maps.quakeworld.nu/)
 
* BSP file (uploaded to https://maps.quakeworld.nu/)

Latest revision as of 16:22, 15 September 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:

  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

Qw-map-release.drawio.png

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