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

Contribute to the Wiki (style guide)

You're welcome to improve existing pages, fix typos or write new documentation - thank you for doing it! To ensure high quality documentation, please follow these simple rules.

Use Markdown syntax

The use of Markdown syntax is preferred. Not everything is supported, but use Markdown whenever possible to allow the wiki to be ported to another wiki system in the future.


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

Avoid fancy wiki extensions like WRAP. They exist, but should be avoided because they are 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 at 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 your writing concise and direct in the reference pages. It's ok to refer to the reader by “you” or “we”, but only as needed.

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! And you can also use events to make some changes on properties.”

Write: “Text objects display text on screen. You can customize text properties (for example, size and colour) upon creation. You can also modify text object properties during gameplay using events.”

Tips for naming the sections 💡

We recommend the use of gerunds (verbs ending with “ing” as a subject) whenever possible for headings. Usually people go to the wiki because they’re wondering “How do I…?” By ensuring wiki subheadings are in the form of gerunds, it will be easier for someone to find what they’re after… even if they don’t know exactly what it’s called within GDevelop.

Header example #1:

  • A wiki section was titled “Joints”. If someone new to game creation read that header, it would mean very little to them. What does a joint do? When would they ever need to read that section?
  • Changing the heading to a task-based gerund: “Controlling object movement with joints” helps the reader quickly understand what a given topic will be about.

Header example #2

  • Original header: Admob
  • Better header: “Integrating ads using Google Admob”

Distinguish between a reference page and a tutorial

  • A tutorial provides detailed instructions about how to do something, with step-by-step screenshots and explanations. Tutorials are in the “Tutorials and Guides” section.
  • Almost everything else in the wiki is a reference page. It should contain a quick introduction to the concept, but be more concise than a tutorial. Assume the reader has already completed the tutorials and that they understand the basic game making concepts when writing a reference page, and only explain what is new.
  • For example, avoid explaining how to add an object in a page about a specific type of object. People reading these help pages will already have added objects. They want to know what this specific object is used for and why, not how to add it on the screen.
  • Similarly, in specific object pages, avoid explaining things that are common to all objects, like rotating the object. This should be part of this common page.
  • This being said, it's fine to add more in-depth explanations, GIFs, or screenshots for complex features - in particular when related to extensions (Physics, Tween, etc…).
You may be asking: “Sure, but does extra explanation really hurt?”. No, but it should take the form of links to other pages whenever possible. 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.