Spelling and Typography • Grammar and Usage • Tone • Links • Titles and Article Organization • Location Pages • Media • Outdated or Unused Content • Miscellaneous
This section of the Style Guide concerns formatting considerations specific to Location Pages. It also contains important guidance for the creation and visual appearance of location maps.
The Locationbox Template
Every location page must use the Locationbox template. This template presents the basic information of the location. The template is used heavily to supply information for APIs.
The only location pages that should not use the template are multi-page locations.
JapaneseName
This field is used to display a location's Japanese name in the Yume 2kki Explorer for Japanese-language users.
For Yume 2kki maps, you must fill in the JapaneseName field. Use exactly one value, which is the map's original name written in Japanese. Do not add multiple values to this field.
If the map's equivalent name is available on the Japanese wiki, use the name provided there.
If the map is counted as a sub-area on the Japanese wiki, include the parent area's name, separating the names with the ： full-width colon. Use the format "[Parent area name]：[Child area name]".
Name
If a map's original name is not the same as the name used on the wiki, provide the map's original name(s) in the Name field.
If the map's original name is already listed in the JapaneseName field, do not list it again in the Name field.
If necessary, provide a romanization and translation of the map's original name, separating each item with a comma. For example, "Madotsuki no Heya, Madotsuki's Room".
Connections
The Connections field (and RemovedConnections field) of the Locationbox template makes use of the Connection template for each connection. The parameters are explained in the template documentation. For a full guide, see Help:Connections.
BGM
The BGM field must use the BGM template.
The title of the BGM is usually the name used in the game files. The filename is instead the name of the uploaded audio file on the wiki. More information can be found on the template page.
BGM field syntax:
{{BGM|title = examplesong|filename = game_examplesong_100.ogg|label = Plays in a subarea|soundroom = 008C}}For more details on naming and uploading files to Yume Wiki, see Media.
Authors and Contributing
The following guidelines apply to games with multiple authors, such as Collective Unconscious, Muma|Rope, Uneven Dream, and Yume 2kki.
Primary Authors
For the purposes of the LocationBox template, the term "primary author" is understood to refer to the creator, programmer, or designer of a given location. Locations can have multiple primary authors. List all primary authors in the Primary field.
Always use the original capitalization of an author's name, but do not include any special characters that are prohibited in article or category names.
Contributing Authors
The term "contributing author" refers to a developer that has made minor additions or changes to the location after its initial publication.
"Contributing author" also refers to a developer that has implemented the location by proxy, rather than "authoring" it themselves.
List authors that match this description in the Contributing field.
Maps
Insert all world maps intended for use in navigation by using the LocationMap template.
Image editing and digital painting software such as GIMP and Medibang are free to use. See help on creating location maps for more advice.
Labels
Add labels to all important features on the map. Important features include:
- Connections to other worlds
- Connections to subareas
- Pathways that require effects to progress through
- Notable NPCs
- Events
- In-game collectibles such as effects, menu themes, items, wallpapers, etc.
- Other points of interest
Do not include badges in map labels.
There is no need to include wallpapers or other collectibles obtained simply for entering a map. Only include collectibles that require players to reach a certain location on a map or to perform an action at a certain location on a map.
Be careful not to accidentally cover important map features or landmarks with labels. Keep labels reasonably-sized and no larger than necessary for text to comfortably fit inside them.
Label Formatting
Labels are usually white or beige bubbles/boxes with black text. If the background is very bright, consider using black bubbles/boxes with white text instead.
For accessibility reasons, avoid the use of color-coded text or bubbles/boxes to convey information.
Do not use multicolored text or bubbles/boxes for labels.
If the text is not black text on a white background, ensure the color contrast is high enough for the text to be easily readable. This tool by WebAIM can be used to check contrast ratios between two colors. We recommend a color contrast ratio of at least 4.5:1.
Use a simple, easy-to-read typeface like Arial, Century Gothic, Courier, Times New Roman, or Comic Sans. Do not use decorative, calligraphic, or otherwise hard-to-read typefaces, such as Jokerman, Mistral, Chiller, or Papyrus. Do not handwrite labels.
Internal Connections
For maps with internal connections (such as doors, warps, screen transitions, etc.), all connections need to be clearly indicated. Do not omit connections that are not on the shortest/main path to a point of interest. A map must be usable no matter where a player is located on it.
Internal connections may be indicated by either using connection labels, lines connecting the two endpoints, or by using matching sets of symbols such as letters or numbers.
Connection Labels
Connection labels are best used for locations with relatively few internal connections. All the advice for labels used for other purposes applies here as well.
If a map has a connection to a subarea that is mapped on a different file, use a connection label to indicate this. If an exit to the world is located in this subarea, indicate this too.
If the connection is one-way, indicate this as well.
If a connection has a requirement (such as effects, random variables, or some other prerequisite), indicate this with a label near the endpoint(s) this condition affects. If this condition is highly complex and cannot easily fit near the connection, expand on it in navigation instructions.
Connecting Lines
Connecting lines are best used for internal connections that are relatively close together. They are most useful for doors that are close together on the map, screen transitions where the screens are placed next to each other, and warps that are near each other.
Connecting lines between endpoints should usually be the same color throughout the map. Color coding these lines is usually superfluous and often confusing. The lines should contrast with the background enough to be clearly visible. We recommend a minimum contrast ratio of 4.5:1.
If the connection is one-way, this can be indicated by using a one-sided arrow. Two-way connections can be indicated using either double-sided arrows or a simple line. If a connection has a requirement (such as effects, random variables, or some other prerequisite), indicate this with a label near the endpoint(s) this condition affects. If this condition is highly complex and cannot easily fit near the connection, expand on it in navigation instructions.
As with labels, be careful not to accidentally cover important map features with connecting lines.
If two connecting lines are near each other or have to cross each other, using different dash weights for them can reduce visual confusion. However, if three or more lines are near each other, consider redrawing the lines or using symbols instead.
If the endpoints of a connection are far away from each other, it is not recommended to use connecting lines. Use symbols instead. If you find yourself making a map with several crisscrossing lines, or needing to draw long lines around the edges of rooms or the map itself, this may be a sign that connecting lines are not a good fit for these connections.
Symbols
Matching pairs of symbols such as numbers or letters are best used for maps with many connections, or for connections that are distant to each other. For example, if a warp pad connects to a distant warp pad on the far end of the map, you might place the letter A next to both warp pads.
It is best to enclose the letter or number within a circle or box. The conventions for label legibility apply to symbol text as well.
Do not indicate connections by using matching colored dots or shapes. Use text.
Corresponding symbols should match each other exactly, and symbols should generally all be in the same style. For example, if you decide to mark one door with a black letter Arial A in a white circle, the door it connects to should also have a black letter Arial A in a white circle. Similarly, the next symbol should be a black letter Arial B in a white circle, and so on. In other words, avoid using varying styles and colors for sets of symbols wherever possible.
If the connection is one-way, indicate this. If a connection has a requirement (such as effects, random variables, or some other prerequisite), indicate this with a label near the endpoint(s) this condition affects. If this condition is highly complex and cannot easily fit near the connection, expand on it in navigation instructions.
External Connections
Indicate all external connections using labels.
If the connection is one-way, indicate this. If a connection has a requirement (such as effects, random variables, or some other prerequisite), indicate this with a label near the endpoint(s) this condition affects. If this condition is highly complex and cannot easily fit near the connection, expand on it in navigation instructions.
For mazes, maps with many internal connections (such as teleport pads or doors), or maps that are otherwise difficult to navigate, draw navigation paths from the entrance(s) of the world to its important features, especially exits.
Do not use only color to convey important information about navigation paths. If navigation paths must be color-coded, include a legend explaining color correspondences. It is also recommended to use different dash weights to further differentiate navigation paths from each other.
As with labels, ensure the color chosen contrasts with the background enough for the navigation path to appear clearly. We recommend a color contrast ratio of at least 4.5:1 here as well.
Additionally, if you use color-coded branching navigation paths, ensure that branches contrast with the colors of the navigation paths they are connected to. In general, prefer red and blue or black and white over other combinations of colors for the sharpest contrast.
Avoid juxtaposing red with orange, brown, yellow, or green wherever possible. Similarly, avoid juxtaposing blue with violet or green. These color combinations can be hard to distinguish for people with red-green colorblindness or blue-yellow colorblindness.
Be careful not to accidentally cover important features of the maps or labels with drawn paths.
Some maps may have complicated or obscure internal mechanics, such as Desolate Hospital or Acoustic Lounge. In cases like this, it is encouraged to include a brief, clear explanation of these mechanics somewhere on the image file if possible.
Like other forms of map text, use an easy-to-read typeface with good contrast against its background. If the text is more than a sentence or two, put the text in a box. Avoid obscuring important map features.
Editing Maps
Although maps are ideally as accurate to the game as possible, readability takes priority. Remember, an unreadable map is useless.
You may edit the appearance of maps to make their content more clear.
This includes:
- Changing the background from the parallax background to a solid color. This is recommended if the background is cluttered or makes it difficult to distinguish between foreground and background objects.
- Dimming or desaturating bright panoramas or maps. This is recommended for very bright or pastel maps where it can be hard to create contrast.
- Dimming useless paths in mazes. This is recommended for mazes of dense visual complexity. However, make sure that the dimmed paths are still readable so a player can still use the map if they wander off the path.
- Circling or otherwise highlighting notable content that is hard to see. This is recommended for large maps or maps with dense visuals.
- Moving rooms around to better draw paths between them. This is recommended for maps where the rooms are arranged extremely non-linearly, but connect in a linear fashion.
Older Versions
Maps that are included for trivia or other purposes, such as maps of older versions, should not use the LocationMap template, even when annotated.
Directions
Priority
When listing the directions to an area, first, list the shortest possible path (in terms of worlds visited) that does not require any prerequisites (such as effects or unlockable shortcuts).
If there are multiple paths tied for the shortest length, list them all.
Next, if there is a shorter path that has prerequisites to reaching it, it should be listed in addition, specifying what would be required to follow that path.
Next, list any and all remaining paths that have prerequisites and are shorter than the first listed path.
You may also list paths that traverse more worlds but take less overall time to follow. Make a note that they are less time-consuming when listing them. For example, if the shortest possible path in terms of worlds visited involves a lengthy and difficult maze section, then you may list a path that bypasses this world if it exists, even if it is a few maps longer.
Example:
Nexus → Location A → Location B → Location C → Location D → Location E *With the <effectname> effect equipped: Nexus → Location A → Location X → Location E
Formatting and Links
All world names in the "Directions" section must be links to the location pages, excluding the initial location (usually the Nexus) and the location the article is about. This applies even if a world name appears multiple times across the multiple paths.
Do not bold any location names in the section, with the exception of locations at the end of the path (Location E shown in the example, commonly seen on pages for Yume 2kki worlds).
Location Categories
The Locationbox template used in location pages automatically inserts the appropriate Locations category for that game, as well as inserting the primary author's category if one specified.
Locations that currently connect to the game's Nexus (or Nexus equivalent) should be categorized under the Yume Wiki's specific Nexus Worlds category.
Locations must be categorized under the wiki's specific In Development category if a future update to the world is confirmed.
Removed content of any kind should be under the wiki's specific Removed Content category.