Project:Wiki Conventions: Difference between revisions

From Dolphin Emulator Wiki
Jump to navigation Jump to search
No edit summary
m (Pre line test)
Line 2: Line 2:


== Preamble ==
== Preamble ==
This is a generalized outline of how things are done here on the Dolphin Emulator Wiki. These are all "common law" concepts; no one has ever set in stone how these things work, they are simply what has grown out of the wiki over it's many years of existence. And they will continue to evolve as the wiki grows. So these conventions are not "rules" in any sense of the word, but guidelines, instructions, and help for those new to the wiki.
This is a generalized outline of how things are done here on the Dolphin Emulator Wiki. These are all "common law" concepts; no one has ever set in stone how these things work, they are simply what has grown out of the wiki over its many years of existence. And they will continue to evolve as the wiki grows. So these conventions are not "rules" in any sense of the word, but guidelines, instructions, and help for those new to the wiki.


== Methodology ==
== Methodology ==
The Wiki strives to be the best resource for accurate and up-to-date Dolphin information. Everything on the wiki is built around that goal. As such, pages, problems, ratings, and everything else on the wiki is aimed at the very latest Git release, updating and changing based on what goes on with development. Subjective information, such as favorite builds and controller configurations, is usually avoided in the main article, but is just fine in Testing, or adding a note to a problem that a build doesn't suffer from it. Furthermore, accuracy matters, and anything that can be reproduced is favored.
The wiki strives to be the best resource for accurate and up-to-date Dolphin information. Everything on the wiki is built around that goal. As such, pages, problems, ratings, and everything else on the wiki is aimed at the very latest Git release, updating and changing based on what goes on with development. Subjective information, such as favorite builds and controller configurations, is usually avoided in the main article, but is just fine in Testing, or adding a note to a problem that a build doesn't suffer from it. Furthermore, accuracy matters, and anything that can be reproduced is favored.


== Ratings ==
== Ratings ==
Line 62: Line 62:


Single player first person shooter on the Wii
Single player first person shooter on the Wii
:<pre>
<pre>
[[Category:Wii games]]  
[[Category:Wii games]]  
[[Category:Single-player games]]
[[Category:Single-player games]]
[[Category:First-person shooter games]]
[[Category:First-person shooter games]]
</pre>
</pre>


Platformer Action-RPG for the N64 with multiplayer
Platformer Action-RPG for the N64 with multiplayer
:<pre>[[Category:Virtual Console games]]
<pre>
[[Category:Multiplayer games]]
[[Category:Virtual Console games]]
[[Category:Platform games]]
[[Category:Multiplayer games]]
[[Category:Action role-playing games]]</pre>
[[Category:Platform games]]
[[Category:Action role-playing games]]
</pre>


== Console Pages ==
== Console Pages ==

Revision as of 13:56, 19 November 2012

THIS IS A WORK IN PROGRESS

Preamble

This is a generalized outline of how things are done here on the Dolphin Emulator Wiki. These are all "common law" concepts; no one has ever set in stone how these things work, they are simply what has grown out of the wiki over its many years of existence. And they will continue to evolve as the wiki grows. So these conventions are not "rules" in any sense of the word, but guidelines, instructions, and help for those new to the wiki.

Methodology

The wiki strives to be the best resource for accurate and up-to-date Dolphin information. Everything on the wiki is built around that goal. As such, pages, problems, ratings, and everything else on the wiki is aimed at the very latest Git release, updating and changing based on what goes on with development. Subjective information, such as favorite builds and controller configurations, is usually avoided in the main article, but is just fine in Testing, or adding a note to a problem that a build doesn't suffer from it. Furthermore, accuracy matters, and anything that can be reproduced is favored.

Ratings

Ratings show the compatibility of a game for the latest master branch Git release. The compatibility guide is below. Secondary branches are not included in these ratings.

Compatibility Description
Stars5.png Perfect: No issues at all!
Stars4.png Playable: Runs well, only minor graphical or audio glitches. Games can be played all the way through
Stars3.png Starts: Starts, maybe even plays well, but crashes or major graphical/audio glitches
Stars2.png Intro/Menu: Hangs/crashes somewhere between booting and starting
Stars1.png Broken: Crashes when booting
Stars0.png Unknown: Has not been tested yet

Game Articles

Description

A description can be anything the editor wants. But generally, they should be brief but include some basic information about what the game is and what its gameplay is like. Usually we put the name of the game fairly early in the description, and put it in '''''bold italics'''''. Links to relevant articles, such as prequels or the system the game is on, are always good. Most of the time we just pull descriptions from wikipedia and tweak them a bit, removing things like release dates and references to other systems.

Infobox

Infoboxes use the {{Infobox VG}} template, have a bunch of options. Most of the general information bits can be taken straight off wikipedia with minimal fuss, except for images: wikipedia's are too small for us. Ideally all of these bits of information will be filled but it's not necessary.

  • |image = must have the thumbnail size tag based on software type. We use 300px size for GameCube and Wii games, 350px size for Wii Channels screenshots and 160px size for WiiWare titles. If you image doesn't resize, only add some garbage in the end of tag such as the image name (for example [[File:FlingSmash.jpg‎|300px|FlingSmash]]). Cover preference order would be: US NTSC, UK PAL, Other PAL, JP, Other.
  • |developer = and |publisher = Only use developers and publishers for the Dolphin released versions. You can either just list the information, or use <br /> for multiple, or use the {{vgrelease}} template to divide out regions.
    • Example of the vgrelease template use for developers or publishers -
  • |series = Series are ''italized''.
  • |release = Release dates use the {{vgrelease}} template, and should be in chronological order. We cut out any outside systems from our release date entries, as it doesn't matter to us when a game came out on the PS2, for example. Usually we can copy paste these straight off wikipedia, but if the page uses the "vgrelease new" template, it'll have to be adapted.
The final code for a release date will look something like the below. Note that the last call is disconnected from the others; sometimes it has to be done to keep the list in chronological order.
{{vgrelease|JP=December 5, 2009|EU=July 9, 2010|AUS=September 23, 2010}}{{vgrelease|NA=November 1, 2010}}
  • |genre = Just get it off wikipedia
  • |modes = Simple-player, Multiplayer, Co-op, WFC. That's all the modes we use here. Modes are presented one after another, with a comma between, going through in that order. WFC is of course the "WiFi Connection", the Wii's online system.
  • |input = Displays all input combinations, shown with commas inbetween. For example: Wii Remote, Wii Remote + Nunchuk, GameCube Controller, Classic Controller. Wikipedia doesn't have this information, but a quick google or looking up a review will usually find it very easily. The Wii Zapper, Wii Wheel, and the like are accessories for controllers and not controllers themselves, so they should not be included.
  • |forumlink = The forum link directs the user to the forum thread that has the same wiki page embedded within it.

Problems

The problems area is a list of problems that affect the current Git version. If a problem is fixed in the current Git version but is still in the current Release version, it should be moved to the bottom and crossed out, with a note on when and how it was fixed if that info is known. Each problem is listed on its own without grouping, to make it easier to deal with. Problems are generally ordered with the most severe ones first, such as crashing or hanging bugs, then going to down to the least severe. Fixed problems are at the bottom.

Configuration

Only non-default settings for maximum emulation accuracy should be used in the Configuration area. An ideal configuration setup lists all the settings needed for flawless emulation regardless of performance, with short explanations beside the suggestions.

Performance information, like telling users to go with EFB to Texture because it works fine, shouldn't be included. The principle is that if a more compatible isn't mentioned, then the high performance setting should work ok. If an unusual setting improves performance and does nothing else, it still shouldn't be included here, but a note may be placed elsewhere in the article (such as in a problem related to it) or in testing.

Hacks not related to compatibility should also be left off the configuration list. For example, if someone turns on the widescreen hack or 3D Vision, they know what they are getting, and we don't need to tell them not to turn it on cause it might glitch out. The exception to that is if it causes something usual, like a crash.

Testing

THIS AREA IS RESERVED FOR KOLANO

Gameplay Videos/Screenshots

Due to changes from the site move, standards for gameplay videos and screenshots are still being discussed and adjusted. This will be updated once things stabilize.

Categories

Each article should have categories for its console, modes, and genres, in that order. The most important ones are the console it is on, and the genre, as it helps in finding games. Modes are a little tricky; if something has both Single-player and Multiplayer, we tend to just list Multiplayer, and only use the Single-player category if it's a Single-player only game. All categories use "games" plural at the end. Variations occur a lot for categories, so compare to existing articles for anything weird. Below are some examples.

Single player first person shooter on the Wii

 [[Category:Wii games]] 
 [[Category:Single-player games]]
 [[Category:First-person shooter games]]

Platformer Action-RPG for the N64 with multiplayer

 [[Category:Virtual Console games]]
 [[Category:Multiplayer games]]
 [[Category:Platform games]]
 [[Category:Action role-playing games]]

Console Pages

Description and Infobox

List

Images

The sidebar has an "Upload file" link, use that to upload images. So we can actually find the images, they should be appropriately named, and they should have categories for whatever they are. Below are the most commonly used image categories.

  • Cover art - [[Category:System Here game covers]] (example: Wii game covers)
  • Glitches/problems pics - [[Category:Bug images]]
  • Screenshots - [[Category:System Here screenshots]] (example: Wii screenshots)

Formatting

Disagreements

If two editors are changing things back and forth in a disagreement, they need to STOP and head to the talk pages. The wiki is entirely open, anyone can edit it, so disagreements need to be settled with communication and compromises.