How do you document your game mechanics and dynamics?

I think Chess is the best example to understand this -Mechanics: How the pieces move, and how they kill another piece. Pawn moves forward, but kills in diagonal for example. -Dynamics: Pins, skewers, discovered attacks, etc. If your Queen is behind a pawn, and your opponent has a rook on the other side, that pawn can be attacked, since it cannot move, otherwise your queen will be killed. -Patterns: check mate patterns, openings, end game concepts, all these are patterns that appear time and time again in different situations, but are still familiar to the player. Best games provide very few mechanics, that are easy to understand but create so many dynamics that is hard to master, and is fun because it lets the user find and solve patterns

This is a huge topic and designers could talk about that for hours and hours, I will try to make a quick easy guide: Mechanics: Rules, Pieces, Input, Tech, these things tend to all fall in the mechanics (based on different designers opinion) in general mechanics are the part of the game where players have no controls over. I what you are thinking, I control the pieces and the tech, yes you control how the behave within restriction (or rules are mechanics) example we freely move within gravity limits. Dynamics: Strategies, mental models, and behaviour. These section describe how the player behave in the game, think soccer, the counter attack tactic, is a dynamic that emerged from the mechanics.

The intent of documentation is to convey relevant information to the team and stakeholders in a format that is easy to understand. It helps convey important information on how different systems within the game are working together and why your audience engages with the game in a certain way.

I like to work on a wiki style, linked based navigation. Every design document that i create contains the following structure: 1. Intent (What's the feature about? why is fun/important for players?) 2. Summary and context of the feature in the game 3. MDA summary 4. User stories (mostly to guide development) 5. Diagrams, flows, references, etc. (the more visuals the better!)

Documentation has 3 purposes: 1 Convey information in an efficient and clear manner Making games in a team effort therefore use document to communicate can be an efficient way to do it (depends on the team. 2 Retain information for the future (verba volant scripta manet) Making games can take up to 15 years, which means that is very possible that you forgot, why and how you have designed a certain mechanics, have a document solve the problem. 3 Review and analyze information in an efficient manner Within our minds, everything always work, and its perfect or viceversa nothing works and its all terrible. Write down your design is a way to watch it and review in a more objective way, adding or removing details.

Another important note here is to realize that the effectiveness of a game documentation depends on anyone but yourself. In other worlds, the rest of the team should be able to understand the mechanics, systems and more of the game in a clear way thanks to the documentation. Some designers make the mistake of documenting in a way that it ends up only making clear sense for them and not for the rest of the team. So, how to document your mechanics? If anyone can understand exactly what they are and how they work by reading it (specially if they are not designers) then you are on the right path.

All documents fallow the same golden rules: Show don’t write use videos, images, flow-charts, music ecc Brief and short documentation Write ONLY THE ESSENTIAL The right tool for the right job Word, powerpoint, excel, vertical/horizontal Implement visual layering and separation Tables, included spaces, a/symmetry No week language Avoid words like: might, maybe, in the future, in my opinion Avoid Junk Decorations, When differentiating, use the ‘smallest effective difference’ Graphs Use graphs and tables to simply concepts and data Colors To give meaning, separate, aggregate, enhance Use soft colors, use color matcher Black&White is the best readability look it from afar, to see if it beautiful

the missing ones Beautiful Make the document visually appealing (watch it from far away) Know your TA A document for a creative director is different from a document for the programming team Update UPDATE CHECK: look at your document few hours or days later (after its completion)

Document your game design in tools that make for a frictionless experience for your teams, making sure they understand how each piece of information is connected. Not all tools are designed to have multiple features so it helps to first have a general template of how information is presented; be it a spreadsheet, document or markup document, paper designs etc.

Keep it simple 1. Overview: The intent of the mechanic or feature. How it's fun and what need it covers for the user? 2. Behavior: What does it do and how it works(mechanically)? 3. Controls: What's the user's input like? 4. Sound and visuals: What feedback does the user receive before, during and after the mechanic or feature? 5. Edge cases: How other mechanics and systems will interfere with the feature when used? what risks are there?

Documentation tends to fall behind design decisions; so it's important to update it as soon as something changes, using meeting minutes as a guide to amend the relevant sections. It is also useful to have a version control system that keeps track of the changes along the way.

Use a platform like Confluence to keep track of changes. It's real time, easy to use and everyone on your team has access to it. Make sure to update, relevant information, after every meeting. Not everybody was part of the discussion and the decisions made but everybody needs to know the current state of the mechanics/feature.

First trick watch your document from far away or highly reduce the size (so you can is as small), in that way you can see if the document is unbalanced in anyway (too much text, too much images, one giant paragraph etc). Take time before review your document (at least a day). Always and constantly ask yourself, how you can say the same thing with less word, or even better with a video or a gif. Use examples. Keep the document update or write OLD, NOT RELEVANT, or similar things if is not useful (do not delete it). use simple languages and simple terms, do not try to impress anyone.