Difference between revisions of "Guidelines"

(Games)
(Notes.)
Line 44: Line 44:
 
* Functions
 
* Functions
 
* Enums
 
* Enums
 +
* Notes
 
* Examples
 
* Examples
 
* See Also
 
* See Also
Line 57: Line 58:
 
* Supertypes
 
* Supertypes
 
* Subtypes
 
* Subtypes
 +
* Notes
 
* Examples
 
* Examples
 
* See Also
 
* See Also
Line 75: Line 77:
 
** Arguments
 
** Arguments
 
** Returns
 
** Returns
 +
* Notes
 
* Examples
 
* Examples
 
* See Also
 
* See Also
Line 89: Line 92:
  
 
* Constants
 
* Constants
 +
* Notes
 
* See Also
 
* See Also
  

Revision as of 12:18, 27 February 2010

All registered users can edit the wiki, but please follow these guidelines for consistency. If you think the guidelines should be changed, or should contain additional information, please don't hesitate to contact Rude.

Purpose

The main purposes of the wiki are as follows.

  1. To document the LÖVE API, and provide tutorials.
  2. To provide information about games and libraries using LÖVE.

That said, it is fully allowed to add information about other things which fall way outside these categories.

If you would like to make major changes in the wiki, like deploying a new structure for built-in types, for example; don't do it. You must talk to Rude first, otherwise there's a high chance your changes will be reverted.

Name Conflics

To avoid too much parenthesized URLs, documentation pages have plain titles without prefixes or suffixes. For instance, the type Image can be referred to externally as http://love2d.org/wiki/Image.

This may occasionally lead to name conflicts, in which case the documentation page will always win. If you create a game called Awesome, and LÖVE later decides to expose a type called Awesome (not completely unlikely), then your game will be moved to another title.

Style

If you're talking about types built into LÖVE, link to them. For instance, Image is an object which can be displayed on screen.

When referring to variables and code inside a regular sentence, use the <code> tag to improve the reading experience. For instance: when you add foo and bar, the result is foobar.

Documentation

Documentation pages must follow the same structure if the documentation is to be usable.

All documentation pages must have a semantic link to their parent in their See Also section. Without this, the item will not appear in the automatic lists throughout the wiki. A semantic link is added like this for a function, type or enum in love.audio:

[[parent::love.audio]]

All documentation pages must also have a semantic, 'list-friendly' description. This is done by adding the following to the bottom of the page:

{{#set:Description=Draws an [[Image]] on screen.}}

Modules

The following 'level 2' headers are allowed, but should only be used if they contain anything.

  • Types
  • Functions
  • Enums
  • Notes
  • Examples
  • See Also

All modules must be assiciated with Category:Modules.

Types

The following 'level 2' headers are allowed, but again, don't use then and leave them empty.

  • Functions
  • Enums
  • Supertypes
  • Subtypes
  • Notes
  • Examples
  • See Also

All types must be assiciated with Category:Types.

Functions

For functions, all headers are required, except Examples and See Also. This means that if a function returns nothing, it should explicitly say that it returns nothing. The same goes for arguments.

Similarly, if there are no constructors for a certain type (e.g. Contact), this should be explicitly mentioned.

The outer items in the list below are 'level 2' headers, and the inner ones are 'level 3'.

  • Constructors
  • Function
    • Synopsis
    • Arguments
    • Returns
  • Notes
  • Examples
  • See Also

If a function has overloads, repeat the 'Function' header for each overload. This is not required for trailing optional arguments; just indicate the default value in parentheses instead.

Arguments and return values should be presented as a definition list, using Template:param.

All functions must be assiciated with Category:Functions.

Enums

For enums, these headers are allowed:

  • Constants
  • Notes
  • See Also

The constants should be listed as a definition list.

All enums must be associated with Category:Enums.

Games

For games, you can choose your own structure, but you should always add some semantic properties to the page to make it appear correctly in the list of games:

{{#set:Name=NoGame}} (Should be same as page title)
{{#set:Author=User:Rude}}
{{#set:LOVE Version=0.6.1}}
{{#set:Description=A short description of your game.}}
{{#set:Screenshot=File:ScreenshotURL.png}}

Screenshots will automatically be resized to fit a box of 161x100 pixels.

Also, put your game in Category:Games to make it appear automatically in the Games page. To put your game in the correct category, add this line at the end of the page.

[[Category:Games]]

It is also recommended that you provide screenshots of your game.

Libraries

No strict rules, but as for games, you should add these semantic properties:

{{#set:LOVE Version=0.6.1}}
{{#set:Description=A short description of your library.}}

Put your library in Category:Libraries to make it appear automatically in on the Libraries page. To put your library in the correct category, add this line at the end of the page.

[[Category:Libraries]]