ParadiseStation Wiki:Manual of Style/Content

From Paradise Station Wiki
Jump to navigation Jump to search
Return to Wiki Contributor Portal Content Return to MOS Main Page
Typography Prose Content Layout Templates Files Accessibility

This section of the Manual of Style describes Content rules and standard for our wiki. Content refers to the type of information we display on the wiki; This includes what information is appropriate and necessary to include, what type of information is inappropriate to include in our wiki, and how much information to include.

Secret Information

By server leadership discretion, no feature that would be discoverable through playing the game or searching through the github repository is to be purposefully excluded from the server wiki. There is no such thing as a secret feature on Paradise and this needs to be reinforced through availability of all information on the wiki. That being said, as discussed later in this page, there is such a thing as too much information or inappropriate information that violates the nature of our wiki or provides no actual value to the reader.

Information

What kind of information is correct for the wiki? The best answer to this question is ALL TYPES except in these cases below.

Technical Information

As a general rule of thumb, if it exists in the code repository, but has no actual in-game representation or serves only as a technical item to enable other items to work it should not be included on the wiki. Admin only items don't automatically fall into this category. Here are a few examples of information not to include

  • Shotguns and revolvers actually have "internal magazines" which serve as placeholders for actual magazines in order to enable the gun to actually fire. Or, laser based weaponry actually have bullets in them called a "energy weapon lens" which is where the charge for the gun is stored.
  • BRPD's range extends 2-3 tiles beyond the client's viewport which allow players to exchange machines just off the screen.

Both of these examples share information that explain technical aspects of features that provide no actual benefit to the read except in the context of game code. This sort of information does not belong in any content pages outside of a github contribution guide.

Too Specific Information

The danger of writing a wiki article is getting too specific or lost in all ranges of hypothetical/possible scenarios and situations. Information in an article should stick to only the topic and provide minimal context of the feature in relation to possible interactions with other features. The article should fully explain all the features mechanics and how players can access the features/interactions without telling the player all the possibilities of the features uses/interactions. This is a hard concept for authors to learn and comes with experience. Here are a few examples to understand this concept:

  • When explaining construction mechanics, the wiki details all the construction, their materials, and their steps. As part of the guide to construction, an author may find it relevant to include a section about how one would go about remodeling a room. This is relevant to construction, may help the reader better understand a few key aspects of construction, but is way too specific. It's an entire section addition to the guide to construction which will likely only cover a few recipes of it when there are well over 200 construction recipes. Instead a detailed and in-depth explanation of the construction/deconstruction process will go a lot farther for the reader in understanding how to utilize all provide information on the page.
  • In the guide to security, an author may find it beneficial to explain how using a bola and disabler combo will be extremely effective for taking down traitors who are using stimulative agent to move very quickly. This is correct and helpful, but the reader would have came to this logical conclusion by an explanation of the effects of using bolas aswell as a paragraph detailing how antagonists will use certain chemicals to achieve special effects.

The key point here is that the correct way to cover these points is through thorough explanation of game-mechanics that allow the reader to infer and discover the answer to these specific scenarios on their own. Game Mechanics and features are hard coded into the game and can be well-explained on the wiki, this mechanics create so many hypothetical and possible situations that to attempt to cover those would not only be fruitless but may also take away from teaching hardcoded mechanics that can't be learned any other way except through documentation and code-diving.

Telling Vs. Teaching

The wiki exists to explain information in a as unbiased as possible way. No article should ever tell a reader what the reader should or should not be doing except in cases where it dissuades players from breaking rules, directly killing themselves, or significantly harming the server/other players. This includes sharing dominant or "meta" strategies that a traitor may use to best fight security. As stated in previous portions of this page, an objective and detailed explanation of game-mechanics is the best way to teach players. Do not tell them which method is best, just explain each facet and mechanic of each method so the reader can infer and experiment to discover what is best.

It is difficult to distinguish between telling and teaching because in many articles, it makes sense to teach a player a certain strategy or setup. For example on the Guide to the Supermatter, a section offers the setup up for the round-start supermatter on the Cyberiad while also offering an optimized setup. However it does it in a way that doesn't specifically favor one setup over the other, it just explains them in detail. On Guide pages, one must tell the player how to perform certain tasks and how to attain outcomes in machine interactions or access end-game mechanics. Step-by-step procedures are extraordinarily helpful and useful and do not violate this concept. Here is a good example:

  • The Guide to genetics page details how one might approach identifying all genetic abilities by irradiating monkeys using the features available in the DNA modifier and writing down discovers on a list/journal in collaboration with the other genticist.
  • The Guide to genetics page does not tell the player that the best way to expediently identify all negative abilities at round-start is to make a monkey chug unstable mutagen

The clear difference between these to is that the first point is a foundational jumping point for a player to explore the mechanics in an informed manner and the second point skips all experimentation and just tells the players the dominant genetics strategy that one can achieve through exploiting very specific chemicals and mechanics. One may derive the idea that this is hiding information or restricting gameplay strategies from the playerbase but this is simply not true. Players develop meta/dominant strategies all the time, but these can quickly change with minor tweaks to completely unrelated mechanics with little context to the topic material itself. It's unmaintainable and really removes the enjoyment from the game. It is very difficult to make this distinction, however its important to understand the difference between hard-coded knowledge/interactions vs player formed strategy

Method of Presentation

When displaying large amounts of information to the reader, authors should take care to present it in a helpful way. Authors should be using a mixture of paragraphs, tables, images, bullet lists, and other UI elements to diversify the mode in which information is presented to the reader.

  • Bullet lists should be connected to and complement a paragraph; Bullet lists should not stand in for actual paragraphs but rather lists out elements of what is being explained or quickly explore less connected aspects of the paragraph topic.
  • Any images/diagrams being used to explain or display information should be limited to almost 2-3 images on the screen at a single moment. Again, images should serve as an extension to text on the page.
  • A cell in an in-line table shouldn't have more than a paragraph in it.