-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This is the GitHub repository for the official Krunker Editor Docs. Unlike many other official resources, this one is fully open source and welcomes contribution from community members. This project was founded and is managed by the Map Makers of Krunker admin team. We want to demystify the extensive set of editing tools and make the esoteric sides of the editor accessible to anyone willing to look. It also serves as a valuable resource to our own helpers.
The documentation should be written in clear, grammatically correct, American English. Use the imperative and subjunctive mood for tutorial content and indicative mood for purely informational content. Limit first-person prose to user guides and the questions within the FAQ section; ensure "FAQ" answers remain in the third-person. Diction should be precise and avoid room for misinterpretation, even if it lengthens explanations slightly. Minimize parentheticals.
Each section follows a strict outline—the structure of the editor's GUI—so properties and objects are as easy as possible to find visually, without requiring a search.
The structure hierarchy is similar to semantic versioning. Majors are for sections, minors for subsections, and patch for individual items. Lower-ordered topics like individual properties will be labelled but will not receive a number.
Markdown is the standard format for all documentation and user guides. Its main appeal is its human-readability and compatibility with HTML. There are specific guidelines for certain items.
- When mentioning an editor GUI item, bold it, and refer to it by the exact name used in the editor. Preserve spelling errors, capitalization, etc. If referencing a GUI element in a different scope, writing out its entire path is preferred.
Ex: "Help > Controls > Movement > Speed and set Sprinting to a higher value. A value of 300-400 will be sufficient for most large maps."
- At the bottom of each property description, leave one line of whitespace, followed by an inline code block for each of these pieces of information: input type (including data type), input range (if a range input), and the default value.
- In headers, always use an ampersand (&) instead of a written "and," except in FAQ questions. Use standard capitalization and forgo punctuation unless for FAQ.
- Use inline code blocks for references to object ID numbers, property values, etc.
Ex: "Look at the start of the file. If it starts with
{"map":{"name":, you tried to use the save file. The save file cannot be used to host maps. Use the export file instead. See 1.3.8."
- Cross reference other things by using the number, especially when referencing something niche.
- Define terms before you use them, at least once in each section.
- Do not put whitespace after headers. Content is to be directly under the headers.
There are a few things to take note of when writing explanatory pieces.
- State the purpose of the item.
- Always provide examples of the purposes of an item.
Ex: "This is necessary in maps that are open to the void, and prevent infinite falls, allowing players to spawn back in."
- State dependencies, if any.
Ex: "Determines if bullets interact with the object. Collidable must be enabled for this to have an effect."
- Mention deleted features, but note that they are removed. If possible, specify removal update.
- Use video examples when possible. Do not cite anything but official MMOK videos unless discussing something marginal, like THREE.js or Blender.
Since the documentation has many redundant instances of property references (Like for color and emissive), they must all be changed if there is a major edit. One way this can be accomplished is by using multi-cursor editing in Visual Studio Code.
Be specific and concise. Failure to abide by this guide will result in rejection of your PR.