Get the latest Education e-news
 
  • A Comprehensive Guide To Successful University Group Projects

    [05.10.18]
    - Luke Haslett

  • Designer Tools

    Game Design Documents

    Commonly referred to as a GDD, make sure you use a design document when fleshing out the details of your game.

    A design document should act like a go to bible for every detail about the game, not only for your benefit, but for anyone on the team who needs to find information. Having this in place allows you to free up some time by not having to answer smaller questions from the group because they can refer straight to the document. This means it's important to make alterations and additions to the document as the project goes on, otherwise incorrect or outdated information can impact the team negatively.

    Besides being for the benefit of the team, I've also found that taking an idea and filling out the document's sections helps me to understand the idea in a lot more depth, allowing me to improve the design as I go.

    Another point for a GDD is that it improves management efficiency, as the project leadership is able to distribute tasks appropriately. That's why I would recommend that a game design document is the first thing your design team put together.

    For the structure of your document, there's a lot of common headers including: Game Overview, Gameplay & Mechanics, Concept Art, Asset Lists, Narrative, Setting & Characters, Levels, Interfaces, Controls, Audio, Artificial Intelligence, Technical Requirements, etc.

    Here's an example of a game design document I created for a group project I was involved with during my first year at university.

    Here a list of example design documents for commercially released games:

    Bioshock

    Doom (1992)

    Fallout

    Grim Fandango

    Grand Theft Auto (Race ‘n' Chase)

    Leisure Suit Larry

    Marble Madness

    Monaco

    Planescape

    Tron

    Information Architecture

    Information Architectures (IA) are a great way to visually represent organised systems. In UI design, forming an IA helps to serve as a wireframe and guide for implementation, as it should include all the key information required to represent navigation between screens.

    Here is an information architecture that I built recently for a project, with integrated legend explaining the colours and silhouette values:


    Key things to consider when building an IA like this include:

    • What information is displayed to the user?
    • What optioned routes can the user take?
    • How do the headed sections interact?

    Check out www.draw.io for quick and simple flowchart making.

    Reference Documents

    This was a useful technique I employed during a large group project where most of the team was comprised of artists.

    Create a document that lists all the environmental assets, characters, and UI elements needed for the game, and source imagery that you feel best represents each entry in their design. Then make sure to pass it to whoever in your team oversees the aesthetic vision. In the group I used this for, I passed it to the concept artist and we sat with the lead artist to discuss how exactly the world we were building was going to look.

    Here's an example reference document that I used on that project.

    One Sheets

    One Sheets are a useful exercise for when you want to convey a quick summary for an idea. All they need to contain are a few points of key information about the idea, and some relative imagery. This makes them great for a design that focuses on developing lots of a similar mechanisms, like characters, weapons, or vehicles.

    Here's some examples of one sheets I've thrown together for projects:


    Approaches to Tech

    Engine Choice

    A lot of the time your university will be pushing you towards a game engine to use, and that will likely be Unreal Engine or Unity. However, if this is a decision you are free to make then your team need to consider the circumstances that will influence your choice. These include:

    • Team Knowledge

    What programming languages is your tech team familiar with?

    Are they taking any modules to support an engine choice?

    • Team Size

    Are there enough techies to provide a crutch if there's a lack of knowledge and someone needs to spend time learning?

    • Scope

    How much work is there to do?

    How many features of an engine will you need to take advantage of?

    How big is the project predicted to be?

    • Schedule

    How much time do you have to complete the project?

    How much commitment can your team provide?

    • Design/Art Style

    Is the game art-heavy?

    Are you using pixel-based graphics?

    After discussing the answers to these considerations, your choice will likely be clear.

Comments

comments powered by Disqus