{"id":724,"date":"2019-01-14T12:00:44","date_gmt":"2019-01-14T11:00:44","guid":{"rendered":"http:\/\/david-bailly.com\/portfolio\/?p=724"},"modified":"2019-04-27T10:47:25","modified_gmt":"2019-04-27T09:47:25","slug":"a-simple-format-to-archive-design-decisions","status":"publish","type":"post","link":"https:\/\/david-bailly.com\/portfolio\/a-simple-format-to-archive-design-decisions\/","title":{"rendered":"A simple format to archive design decisions"},"content":{"rendered":"\n

This article written during Nanotale’s development describes how we kept an archive of decision-making within the design documentation with the help of a few simple icons.<\/em><\/p>\n\n\n\n

Before starting production on Nanotale, we took some time to prototype various typing gameplay ideas. When prototyping, you have to focus on the things you want to test, and iterate on them as fast as possible. There is no time to document everything. But the prototypes do not always speak by themselves. (Sometimes there is no playable build to keep, like the time I tested interactive dialogs by acting as the NPC and talking through Slack with a colleague. We will get back to that.) So we needed a way to archive what we learned from each iteration, in a format that would be quick to write and read.<\/p>\n\n\n\n\n\n\n\n

The Problem<\/h2>\n\n\n\n

This is a common problem of design documentation. How to keep an account of the decisions that led to a design as it is? It is interesting to keep a trace of previous iterations, to look back at the evolution of a design. But more importantly, it is a waste of time if another designer (or your forgetful self) makes changes that recreate a problem that has already been solved, just because they have no knowledge of the history behind that decision.<\/p>\n\n\n\n

For all those reasons, I was looking for a practical way to link each feature to the decision path that led to it. It needed to be quick to write and to read, because if we have to go back and read multiple paragraphs of history, we all know no one will do it. Surely, someone already came up with a solution, right?<\/p>\n\n\n\n

A Solution<\/h2>\n\n\n\n

Sadly, I could not find anything related to game design. The results I found were tools to keep track of programming design decisions in code, as it seems programmers need a similar solution for similar reasons. Eventually, I found a research paper about an experimental tool made to present design decision-making in a simple way. It gathers \u201cdecision elements\u201d from different sources (code annotations, designers\u2019 UML diagrams\u2026) and organizes them visually in a hierarchy, like bullet points. If you want to know more about the technical details of their tool, it is called \u201cDecDoc: A Tool for Documenting Design Decisions Collaboratively and Incrementally\u201d (Hesse, Tom-Michael & Kuehlwein, Arthur & Roehm, Tobias 30-37. 10.1109\/MARCH.2016.9)<\/p>\n\n\n\n

I took inspiration from their bullet points presentation. It is brief, the icons convey a meaning that does not have to go through text. When taking notes, only a few words are necessary. It is great for what we want. Here is a made up example of what it can look like for game design:<\/p>\n\n\n\n

  • \"!\" We need X to give game experience Y
    • \"✔️\" There are no other games doing X<\/li>
    • \"⚠️\" An aspect of X can be too costly
      • \"key\" X can be limited to a few occurrences<\/li>
      • \"key\" We can try the different way Z instead<\/li>
      • \u27a4 Give Z a test to decide <\/li><\/ul><\/li>
      • \"?\" How does this affect W? <\/li><\/ul><\/li><\/ul>\n\n\n\n

        And here is a real example form the prototype of the dialogue system I was alluding to in the introduction. To give a bit of context, it was a test for a typing based branching dialog. Typing highlighted keywords would make the conversion go forward on the topic of the chosen keyword. The playtest challenged the idea of having secret keywords the player could type by himself, that they would have learned from another NPC.<\/p>\n\n\n\n

        \"\"<\/figure><\/div>\n\n\n\n

        Our Version<\/h2>\n\n\n\n

        We took a few generic icon types from the original source and added others as they were needed. Here is the full list of the icons we have:<\/p>\n\n\n\n
        \"!\" Postulate<\/td>Let’s admit that\u2026<\/td><\/tr>
        \"👉\" Assessment<\/td>We already know that\u2026<\/td><\/tr>
        \"?\" Question<\/td>Uncertainty to be resolved or defined<\/td><\/tr>
        \"X\" Problem<\/td>Creates a problem \/ inconsistency<\/td><\/tr>
        \"⚠️\" Risk<\/td>May not be fun \/ doable<\/td><\/tr>
        \"flag\" Red Flag<\/td>Problem will probably come up later on<\/td><\/tr>
        \u2295 Intention<\/td>Motive behind a decision or design<\/td><\/tr>
        \"star\" Opportunity<\/td>Good thing that can be developed<\/td><\/tr>
        \"key\" Solution<\/td>Proposition of a solution<\/td><\/tr>
        \"lightbulb\" Idea<\/td>Proposition of an additional feature<\/td><\/tr>
        \"✔️\" Argument for<\/td>Argument in favor of<\/td><\/tr>
        \"❌\" Argument against<\/td>Argument against<\/td><\/tr>
        \"note\" Note<\/td>Additional information<\/td><\/tr>
        \u27a4 Decision<\/td>Final decision of what we are doing<\/td><\/tr><\/tbody><\/table>\n\n\n\n

        All the icons are basic unicode emojis and not images to gain time and ensure full compatibility. The bullet point notes of each prototype where copy pasted into Slack for the whole studio, and you can now see an example in this article, without extra work. They can also all be drawn quickly, at least in broad strokes, to be used when taking notes with pen and paper.<\/p>\n\n\n\n

        Extended Use<\/h2>\n\n\n\n

        When we entered into production and decided to use a wiki as our design document, we ported the icon system to it. The wiki tool that is made to convert => into \u21d2 was modified to change :idea: into 💡. Here is another example, taken from the wiki page about the consumption of \u201cmana\u201d to cast spells.<\/p>\n\n\n\n

        \"\"<\/figure><\/div>\n\n\n\n

        We ended up using those icons to add quick \u201cwork in progress\u201d notes in our design documents. The most common is the idea icon (💡), used whenever we want to add an idea to an existing page for later review. The couple problem (🛑) – solution (🔑) identifies problems and solutions to evaluate whenever we can take the time to redesign the feature. The intention icon (\u2295) has been added later, specifically for the wiki, to justify the purpose of a feature.<\/p>\n\n\n\n

        Game design documents are in a constant work in progress state, evolving during development. They are often out-of-date from the latest changes if you do not have someone dedicated to that (which, on our small team, we don\u2019t). The tool and format we use to write them should support that. With our system, whenever we see a bullet point with an icon, we know that the information is still part of an ongoing discussion. Other team members can trust what is written because what is unknown or unsure is also documented. The design process is transparent in the documents.<\/p>\n\n\n\n


        In the future, that system will evolve a bit like a new language. In one hand by adding the icons we need, and in the other hand by removing the ones that are not used to avoid cluttering. The list as it is now is probably a bit too long. Now that I have told you everything, I would love to know if that system can be useful to others, or if other solutions exist.<\/p>\n","protected":false},"excerpt":{"rendered":"

        This article written during Nanotale’s development describes how we kept an archive of decision-making within the design documentation with the help of a few simple icons. Before starting production on Nanotale, we took some time to prototype various typing gameplay ideas. When prototyping, you have to focus on the things you want to test, and iterate on them as fast as possible. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[29],"tags":[54,53],"jetpack_featured_media_url":"","jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p7TL8k-bG","jetpack-related-posts":[{"id":677,"url":"https:\/\/david-bailly.com\/portfolio\/solving-patterns-in-shift-quantum\/","url_meta":{"origin":724,"position":0},"title":"“Solving patterns” in Shift Quantum","date":"2018-05-11","format":false,"excerpt":"As level designers on Shift Quantum, when experimenting with newly designed blocks (even before they were implemented) we identified and listed the different micro problems they could generate. Complex puzzles are built later by combining them.\u00a0Each micro problem has a micro resolution pattern that the player has to figure out\u2026","rel":"","context":"In "Article"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/david-bailly.com\/portfolio\/wp-content\/uploads\/2018\/05\/SQ_mov_tuto-768x536.jpg?resize=350%2C200","width":350,"height":200},"classes":[]},{"id":503,"url":"https:\/\/david-bailly.com\/portfolio\/handmade-vs-randomized-level-design-in-epistory-placeholder-post\/","url_meta":{"origin":724,"position":1},"title":"Handmade vs randomized level design in Epistory","date":"2015-05-12","format":false,"excerpt":"This is an old article that was written as a dev blog post for\u00a0Epistory, a typing adventure game and the first project I worked on at Fishing Cactus. The problem As in most puzzle \/ adventure games, Epistory's level design, is designed manually from the world layout to the smallest\u2026","rel":"","context":"In "Article"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":465,"url":"https:\/\/david-bailly.com\/portfolio\/epistory-typing\/","url_meta":{"origin":724,"position":2},"title":"Epistory is not your usual typing game","date":"2015-04-01","format":false,"excerpt":"This is an old article that was written as a dev blog post for\u00a0Epistory, a typing adventure game and the first project I worked on at Fishing Cactus. It all starts with (good) intentions When you start creating a game. When you think you have a great idea to turn\u2026","rel":"","context":"In "Article"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":880,"url":"https:\/\/david-bailly.com\/portfolio\/exploration-feeling-in-spyro-the-dragons-level-design\/","url_meta":{"origin":724,"position":3},"title":"Exploration Feeling in Spyro the Dragon’s Level Design","date":"2019-09-07","format":false,"excerpt":"In the best levels, the level design structure makes you feel like you are exploring areas you are not supposed to, while never being stopped in a dead end. Most levels in Spyro the Dragon (and the other games of the trilogy) use (loosely) hidden treasures and secret paths to\u2026","rel":"","context":"In "Tips & Tricks"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/david-bailly.com\/portfolio\/wp-content\/uploads\/2019\/09\/ref_spyro_town_square.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":832,"url":"https:\/\/david-bailly.com\/portfolio\/prankster-comets-of-super-mario-galaxy-1-2\/","url_meta":{"origin":724,"position":4},"title":"Prankster Comets of Super Mario Galaxy 1 & 2","date":"2019-05-08","format":false,"excerpt":"Prankster Comets appear randomly on previous levels, giving them a new objective, sometimes with adaptations of the level design. A prankster comet level is shorter than a normal level, with an objective is only found with the comets. They add gameplay variation, but re-use most of the levels environment and\u2026","rel":"","context":"In "Tips & Tricks"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/david-bailly.com\/portfolio\/wp-content\/uploads\/2019\/05\/ref_mario_galaxy_comet.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":524,"url":"https:\/\/david-bailly.com\/portfolio\/the-problem-behind-the-solution\/","url_meta":{"origin":724,"position":5},"title":"The problem behind the solution","date":"2017-03-20","format":false,"excerpt":"To get to what I mean with that enigmatic title, I should start with an example. A few days ago, with a fellow designer, we started working on the level design of a puzzle game. Because the project is in early development, we try and playtest different approaches. One of\u2026","rel":"","context":"In "Article"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/david-bailly.com\/portfolio\/wp-json\/wp\/v2\/posts\/724"}],"collection":[{"href":"https:\/\/david-bailly.com\/portfolio\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/david-bailly.com\/portfolio\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/david-bailly.com\/portfolio\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/david-bailly.com\/portfolio\/wp-json\/wp\/v2\/comments?post=724"}],"version-history":[{"count":37,"href":"https:\/\/david-bailly.com\/portfolio\/wp-json\/wp\/v2\/posts\/724\/revisions"}],"predecessor-version":[{"id":777,"href":"https:\/\/david-bailly.com\/portfolio\/wp-json\/wp\/v2\/posts\/724\/revisions\/777"}],"wp:attachment":[{"href":"https:\/\/david-bailly.com\/portfolio\/wp-json\/wp\/v2\/media?parent=724"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/david-bailly.com\/portfolio\/wp-json\/wp\/v2\/categories?post=724"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/david-bailly.com\/portfolio\/wp-json\/wp\/v2\/tags?post=724"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}