DD/Article Structure

From Unknown Horizons

This page is ment as a recommendation for new design document articles. This structure was designed to make writing new articles easier and to support further refinement. Of course another structure can be used if the resulting design is in a usable state.

Contents 1 Overview 1.1 Proposal 1.1.1 Summary 1.1.2 Implementation related note 1.1.3 Workings 1.1.4 Graphical content 1.1.5 Audio content 1.2 Open questions 1.3 Use Cases 1.4 Phasing 1.4.1 Details 1.4.2 General 2 CODEBLOCK TO COPY

Overview

An design document article contains the following section:

Template:Part of design document

• Proposal
  • Summary
  • Implementation related notes
  • Workings
  • Graphical content
  • Audio content
• Open questions
  • Template:Question
  • Template:Answer
• Use Cases
• Phasing
  • Details
  • General

Category:Design document

Note: For comments and notes from the author the Template:Note might be of use. signature of author

---

(Due to some problems with this template it is recommended to use a br-tag after the template tag to force a line break, otherwise the wiki will mess up the headline structure.)

Proposal

Content of this design article. This is the most important section in a finished article, since the following 2 sections are meant to help refining it during the development of the design document. This part is divided into 5 more sections...

Summary

The basic idea written in a few sentences.

Implementation related note

Key points being important for the technical implementation of the features.

Workings

The description of how the feature will get used by players.

Graphical content

Details about the graphics (including design) needed for this feature - if needed.

Audio content

Details about the sounds needed for this feature - if needed.

Open questions

When the proposal is written, it is often hard to keep focused when you think of different fields of resulting problems. These problems should be noted here as questions, which are answered in later iterations. This way, we encourage to release unfinished articles which are easier to write, without forgetting problems.

This section is also used by peer reviewers to note the problems and uncertainties they found in the article.

Questions are answered by editing the relating part of the proposal and be removed when the author of the question is satisfied. This means, in a finished article this section is empty.

Open question: Is there a template I can use for questions and answers? signature of author

Suggestion: Yes, there have been created two templates for this pupose - Template:Question and Template:Answer. signature of author

Use Cases

Use cases are description of how a feature is used in the game. They should be mentioned in one or few sentences. They should be refined in an iterative process, some bigger use cases may even be exported to an own article.

By writing detailed use cases, the designer is forced to break the problems into smaller pieces, just like a programmer does while implementing a feature. This way, the designer can detect technical difficulties, before the programmer has to find them while implementing the feature.

Phasing

This section estimates the importance of the feature and may associate it with a milestone. If only a part of the features should be implemented for a certain milestone, the exact compromise is described here.

Details

General

CODEBLOCK TO COPY

{{Part of design document}} <br>
=== Proposal ===
==== Summary ====
==== Implementation related note ====
==== Workings ====
==== Graphical content ====
==== Audio content ====

=== Open questions ===
{{Question||}}
{{Answer||}}
 
=== Use Cases ===

=== Phasing ===
==== Details ====
==== General ====

__NOTOC__
[[Category:Design document]]