Goal of the Burnout Wiki

The Burnout Wiki aims to be a source of objective, unbiased, and accurate information on the Burnout video game series by comprehensively documenting each game.

Unlike a wiki such as Wikipedia, which is a tertiary source, the Burnout Wiki is a primary source. The goal of each article is to present original research on a particular aspect of a game in an organized, easy-to-understand manner. This research should be conducted with the game itself as the subject of study; decompilation, runtime analysis, asset examination, and actual gameplay are all valid ways of gathering data.

Secondary goals

Although the Burnout Wiki is dedicated to the Burnout series, similar documentation for Criterion's other games—namely Black, Need for Speed Hot Pursuit, and Need for Speed Most Wanted—is allowed and encouraged.

General guidelines

Do:

Produce documentation on the Burnout games.
Write objective, unbiased articles in a formal tone.
Address a specific topic in each article.
Be as comprehensive as possible.
Cite your sources.

Don't:

Add content to the wiki that is not related to Criterion's games.
Write opinion pieces with no factual backing.
Make vague/ambiguous claims that cannot be proven.
Partly document something and leave it for someone else to take care of.

Example content

Regarding objectivity and sources, sentences should be structured following these guidelines. For example, take the following sentence:

The Rai-Jin Turbo is the fastest car in Burnout Paradise.

This may be true, but it is also ambiguous and potentially subjective. A more appropriate sentence for the wiki would be:

At 201 MPH, the Rai-Jin Turbo has the highest MaxSpeed attribute of any vehicle in Burnout Paradise.

Here the user is informed of the source (the vehicle's attributes), the specific field being referenced (MaxSpeed), and the value (201). All these things help to create a clearer understanding of what is meant by the text and where the information came from.

Citing sources

While external sources effectively follow the same guidelines as Wikipedia, the Burnout Wiki inherently gets much of its content directly from the game being documented. As such, the source is automatically assumed to be that game unless explicitly stated otherwise. The question becomes what specific version of the game is being researched and where within that version the information comes from.

Game citations should contain the following information. Sections may be excluded if the information is unavailable, irrelevant, or redundant.

Type of source (asset, symbols, etc.)
Game name (only if multiple games are being researched for the same article)
Build date of the specific version being used
Title ID, media ID, or build name
Platform
Version or CL number
Name of the file(s) being referenced

Examples:

Debugging symbols, 2007-10-31 "Burnout Paradise - Review Build" (PS3, CL 63412), Burnout_Internal_PS3.self.
Asset, 2007-10-31 "BLUS30061" (PS3, v1.0), VEHICLES/VEHICLELIST.BUNDLE.
Preprocessed source, 2007-02-21 (PS3), BrnEntityModuleUnity.ii.

Documentation

General

Gathering information

As content accessed during normal gameplay varies widely, the method of documenting it does as well. However, there is always objective information that can be collected and displayed. Any of the following, and potentially more, are valid ways of presenting information:

Captured media (e.g., screenshots or video of gameplay)
Custom representations of object data (e.g., viewing 3D models outside the game)
Tabular transposition of object data (similar to structure documentation)

Direct use of game assets on the wiki is discouraged but allowed if no better option is available or if exact accuracy is desirable.

Handling versions

The focus of any article should be on the latest available version of a game. Old versions and changes between versions can be documented in subpages.

Some assets may have significant differences or even entirely different variants between platforms. If this is the case, it may be worth having subpages for each platform.

Development versions

If documenting a build, create a page titled "<game name> (<build date> build)" dedicated to that specific build. If two or more builds have the same date, append other available information—platform, region, version/CL, or ID/name (in that order)—until the names no longer conflict.
If documenting development versions of an asset or other element of a build, create a subpage of the relevant retail page.

Data structures

Structures are typically documented using tables. An overview of a known good template is provided here. Use of this template is not a requirement; anything that documents the structure and aids the reader in comprehending it is acceptable.

For more details, see the structure documentation guide.

BrnExample::Structure

Offset	Length	Type	Name	Description	Comments
0x0	0x4	int32_t	miExample	Example field for documentation guide	This is just an example
0x4	0x4	Enumeration	meEnum	Enum value
0x8	0x4	uint32_t	?	Number of examples present
0xC	0x4			Padding

BrnExample::Enumeration

Name	Value	Comments
E_EXAMPLE_ENUM_ZERO	0	An example with the value 0.
E_EXAMPLE_ENUM_ONE	1	An example with the value 1.
?	2
E_EXAMPLE_ENUM_FORCE_INT	0x7FFFFFFF	Forces the enum to compile to a signed 32-bit integer (minimally).

Executable

Documenting an executable is considerably more complicated than documenting any other part of a game. Whereas assets contain structures that can be displayed as tables, executables are primarily made up of functions (in the form of machine code) which can be disassembled or decompiled for viewing. The problem is that neither of these options produce an output that is understandable by the average reader. The relevant functions must instead be summarized, either in plain English or by creating a flowchart. This results in a loss of accuracy and introduces a degree of subjectivity pertaining to the importance of certain parts of a function.

Due to the above, the way an executable is documented is almost entirely up to the author. However, one generalized method of doing so is to follow the path of execution from main() down through the class hierarchy while logging any major events that take place, such as object construction. It is also critical to document the classes in question, or their data structure at the very least. (Every Criterion game from the first Burnout onward, and possibly before that, uses C++ and is guaranteed to use classes and construct objects.)

One other issue is that people unfamiliar with the executable often mistakenly interpret it as just another asset and view certain global, static, and constant variables as the most important content within. While this is an incorrect trivialization of the executable, it may be worth providing a list of some of these variables if the information is frequently sought.

Running code on the wiki

Sometimes, it is beneficial to recreate certain functions from an executable in a standalone program for users to run. Hash algorithms are a common example of this. In these cases, the most accessible way of implementing them is to port them to JavaScript, allowing them to be hosted on the web.

The wiki supports running custom JavaScript. Since plain HTML is unsupported, you will have to make a template with a div (like this) and create a script that writes the HTML into the div (like this). An administrator will need to approve the script, add it to the appropriate page, and whitelist it for loading on specific pages before it can be used.

Style guide

If file name case is inconsistent between different versions of a game, either use the variant that is more common or the one that is more detailed (e.g., mixed case rather than upper or lower). If choosing between uppercase and lowercase, use uppercase. The difference can be noted, but do not use both variants interchangeably and never alter the case to something inaccurate.
Use the ISO 8601 standard (YYYY-MM-DD) for dates.
When referring to the numbered Burnout games, use their names without the subtitle (Burnout 2, Burnout 3). Otherwise, use the retail names (e.g., Paradise, Revenge, Burnout). Do not use development names like "Burnout 5" unless the topic is specifically related to development.

Content policy

In addition to following the Miraheze content policy, contributors are expected to abide by the law and not distribute ROMs, ISOs, or archives, or to engage in any other method of sharing game files on the wiki. This includes development builds, modifications, and other content derived from the games. Articles may include representations of data from game assets for research purposes, but this is not the place to share the games themselves.

The sole exception to this rule is linking to external pages which contain research or other relevant materials but might have download links to games or development builds as well. Examples include YouTube videos, wikis like Hidden Palace, or any other page that is not controlled by this wiki's contributors. This exception does not cover direct download links or links to file-hosting services. Additionally, any link with such content available, regardless of whether or not it contains research, may be removed at any time at the discretion of an administrator.