**This is an old revision of the document!**

Contribute to the Wiki (style guide)

You're welcome to improve existing pages, fix typo or write new documentation - thank you for considering doing it! To keep a good quality documentation, please make sure to follow these simple rules.

Use Markdown syntax

Prefer to use Markdown syntax as much as possible. Not everything is supported, but as possible use Markdown to allow the wiki to be ported to another wiki system in the future.

Notably:

  • Use Markdown headers:
# Header 1
## Header 2
  • Prefer Markdown italic (_italic_)
  • Use Markdown backticks for code/expressions: MyObject.Variable(Life)

Similarly, avoid fancy wiki extensions like WRAP. They exist but should be avoided because not standard. Adding <note> is fine and encouraged though.

Ordering of sections

  • Keep “Example” at the end of a page.
  • The first section must be a the top and be a Level 1 Header: # This is the title

Keep it concise and professional

The documentation is used by everyone, from kids to professional game developers. Keep a concise writing in the reference pages. It's ok to refer to the reader by “you” or “we” in tutorials, but in other page avoid refering to the reader.

For example:

  • instead of “So a Text object is as the name implies something that you can use to display a text on the screen. GDevelop even allows you to change the font. the size and tons of effects!”
  • prefer writing: “Text objects display text on screen. You can customize text properties (for example, size or colour) upon creation. You can also modify text object properties during gameplay using events.”

Make the distinction between a reference page and a tutorial

  • A tutorial is explaining the detailed instructions about how to do something, with lots of screenshots and explanations. Tutorials are inside the “Tutorials And Guides” section.
  • Almost everything else in the wiki is a reference page. It may contain a quick introduction to the concept, but should avoid using the tone of a tutorial and be more concise.
    • For example, avoid explaining how to add an object in the page of an object. People reading these help pages will already have added objects. They want to know about this object, not about how to add it on the screen, which is explained in all tutorials.
    • Similarly, in object pages, avoid explaining things that are common to all objects, like rotating the object. This should be part of this common page.
You may be asking: “Sure but a bit of redundant explanations are useful no?”. While it's true, it should take the form of links to other pages. Redundant explanations across the wiki make the articles harder to maintain when the software evolves - and the documentation is the most important asset after the software itself.

Triple check grammar and mistakes

A page full of mistakes and typos will have a negative impact on readers, that will think of GDevelop as something of bad quality and unreliable.

Proofread multiple times what you're writing. Prefer short sentences to longer ones.