Should the GDD contain the GUI layout?

Started by
3 comments, last by LorenzoGatti 7 years, 2 months ago

hi all,

Should the Game Design Document contain the layout of the GUI (Graphical User Interface)?

Or is it enough to list the items needed on the GUI and their types (eg. Name, Password [Input boxes]; OK, Cancel [Buttons]), and let a specialist design the layout somewhat later?

In case you say it should include the GUI layout, then how detailed/precise should that be, or is a rough sketch enough?

Advertisement
Vaclav, it depends on your certainty about UI element positioning, and the strength of
your convictions. If you just want the elements to be on the display but you don't have
strong feelings about where they should be, and you don't have a UI designer on your
project, then you can leave it to the art director to make that determination (or you
can discuss it with him or her to make that determination). But if you are certain that
an element needs to be placed in a particular location and needs to be a certain size
and shape, then you should put that in the GDD.

-- Tom Sloper -- sloperama.com

I--and most people, I think--view GDDs as a living document that's anything but sacrosanct; they're not meant to set things in stone and then be followed verbatim, or for what's written in them to go forever unchallenged and unchanged.

I think the answer to what should be recorded is to record what seems important, when it's important, to the level of detail that's necessary to keep the team operating together -- not what's inconsequential, not sooner, and not in more detail than is useful and--more importantly--can be clearly seem. Over-planning carries risks just like underplanning -- working in perfect lock-step towards the wrong goal can waste just as much time, energy, and morale as working haphazardly at unclear ones. Resist the urge to codify your speculations as anything but that -- "We don't know the answer yet, but we think this is an important question." Is a perfectly fine thing to write down, and in fact far better than pretending to know.

throw table_exception("(? ???)? ? ???");

I--and most people, I think--view GDDs as a living document that's anything but sacrosanct

There are many types of design documents.

Some are high level, wide-ranging overviews. Some are called the 'ten thousand foot view' or similar, where a wide range of features are explained in abstract forms, nothing is concrete.

Others are very specific details. A design document for a specific game object may detail exactly what features it has, exactly what formulas must be used, exactly what values must be adjustable.

Depending on your development processes and where you are along the development cycle, the documents may be easily adjusted with a quick discussion where the designer types it in as you go, or they may be nearly fixed in stone requiring a meeting with all the leads and directors to discuss why the thing must change.

If the GUI layout is important in that specific document, it should be there. If the GUI buttons are important but layout is something that can be discovered or modified based on feedback and art design, the document should state it; programmers can implement the button functionality and leave the rest to the UI artists. If the design does not mandate a specific functionality or specific look and feel, that should be documented instead, and updated over time.

GUI layout for interactions involving passwords, buttons etc. (as opposed to user interface for the game itself) is unlikely to be interesting. There are three obvious detail levels:

  • An abstract specification of GUI states, screens, navigation, and their inputs and outputs. For example, a "network game" button on the main screen leads to a dialog asking for username and password, with "cancel" and "login" buttons, and "login" leads either to the countdown for starting the network game or to a screen containing an error message and a "cancel" button that goes back to the initial screen. Very important in the design document, and subject to frequent changes.
  • Graphical guidelines, including selecting a GUI library depending on what widgets are needed, "themes", layout rules, etc. For example, unusually thin borders and paddings to accomodate long text on small screens. Important in the design document because GUI appearance should be good and consistent, but not urgent.
  • Exact layouts and copy texts of every GUI page: boring but possibly useful for QA purposes, and added to the GDD late (if at all) when GUI structure and appearance has ceased to change..

Omae Wa Mou Shindeiru

This topic is closed to new replies.

Advertisement