The Game Design Model

 

If there is a feature in HacknPlan which is unique and completely game dev oriented, is the game design model (GDM). One of the most common pains development teams suffer when working on a game is the difficulty of defining a proper game design document (GDD) and, most importantly, keeping it updated and alive. This is key for a proper project organization because it’s the resource used to define your vision of the game and to keep your team aligned. The way projects are managed has changed a lot over the years; there was a time when having a fixed document containing the full design of a game from the beginning was accepted; that’s how the waterfall methodology worked. However, in today’s world,  projects are approached in a more agile and iterative way which encourages prototyping, iteration, and constant evaluation. The GDD is now a document in constant evolution, being built iteratively as the game does.

The purpose behind the GDM is to provide a dynamic and integrated way of defining your game design, replacing the linear document or wiki pages with a tree structure of design elements which not only contain unstructured content like text and pictures, but also tasks, progress, and metrics. This way, your tasks are not just a bunch of tickets on a list, they have something that connects them as a whole giving context and meaning, and at the same time your design is not isolated from the project itself, it has a new dimension now, which is how that design is implemented over time.

web_gdm_dark

Defining your design model

Important: The game design model requires specific writing permissions.

You can create a new design element by clicking on the plus icon button on the header or by pressing C on your keyboard from the game design model section. You can also create a child element to another one by clicking on “Add child element” on the context menu (right click or gear icon), or clone it by clicking on “Clone” or pressing “Alt”+”C” on the keyboard. The basic fields of a game design element are:

  • Name: The name of the design element.
  • Type: A categorization field to give more context, which is normally added before the name where the element is referenced. The available types can be customized by a project administrator.
  • Starting date: The date where the development of the feature described by the design element will start. When this date is set, it automatically updates the starting date of the parent element up to the root level, unless they already have a value and is equal or previous to the one added. Besides this, a starting date which is later than the one from any of the element children will be considered invalid. This date will be used by some premium features like the Gantt chart and the Calendar.
  • Due date: The deadline for the development of all the tasks of the design element. The same behavior related to parents and children applies.
  • Content: This is a free markdown-based text field you can use to add a complete definition of the design element. You can add formatted text, links, pictures, reference users, and attachments… It also supports HTML, so you can create advanced layouts.

When a new element is created, it’s automatically selected and a panel is open for editing several fields like the name of the element, the type (a categorization value to give it more meaning) and a description, which contains the definition of the design element with text, links, and pictures. The content of the design element can be formatted using Markdown syntax for a better display, and also supports HTML in order to create more advanced layouts. After your element is created, you can update it at any time by selecting the element from the tree. There are a few shortcuts to go directly to the edition of the name, you can open the context menu and click “Edit” or press “E” on your keyboard while the element is selected.

Besides editing the fields we already mentioned, you can also relocate the design element by using drag and drop. You can also drop an element as a child of another one by dragging the element below the parent and then moving the mouse to the right before dropping, which will indent the placeholder as a visual representation of this process. For this operation to work, the parent element needs to be expanded if already has children.

You can delete design elements by clicking “Delete” on the context menu or by pressing “DEL” key while the element is selected.

Adding tasks to your design model

One of the biggest advantages of the GDM over a traditional GDD is the direct relation between design and planning, and this is achieved by connecting design elements and tasks. These two entities, along with the definition of milestones, connect the tree basic pillars of a project: what to do (GDM), how to do it (tasks / team), and when (milestones / deadlines).

Adding a task to a design model is as simple as creating a new task like we explained earlier in this guide. The creation dialog will allow you to choose the desired game design element, including the possibility of leaving it blank to create a detached task, although we strongly recommend putting everything under the GDM for a better organization. When you create a task while in the GDM section and an element is selected, the task creation will have that element selected by default.

The tasks belonging to a specific design element are listed under the “Tasks” tab of the design element editor. You can also see the design element of a task at the top of the cards in the
kanban boards, which helps to quickly identify them. If you want to move a task from one design element to another one, you can do so by opening the task editor by selecting a task from the GDM or the board and then clicking on the design element field. You can also change the design element of a task from the context menu.

 

hacknplan

This entry has 0 replies

Comments are closed.