Project Framework, Pt. 2


Hello, I’ve finally gotten around to combining the frameworks I described in a previous post.

I decided to use the Game Design Workshop process as the base since it’s designed specifically for game development. From there I tried to figure out where the steps from the Agile Development Framework might fit in. Here’s what I think the framework becomes when you combine the two:

  1. Brainstorming
    1. Come up with as many concepts as possible. Narrow these down to the top few.
    2. Draft a short, one-page outline describing the ideas. System metaphors may be helpful here.
  2. Develop Concept
    1. Choose an idea to proceed with.
    2. Form an initial plan of the project. It may also be worth developing a knowledge base, a risk management plan, & ethical design from this point onwards.
    3. Come up with user stories appropriate to the idea. Use these stories to come up with a list of requirements.
    4. Break down requirements into a series of tasks & analyse them.
    5. Write an overview of the design theme (look, feel, & style of interactivity) of the game.
    6. Use the analysed tasks to form dialogue diagrams.
  3. Physical Prototype
    1. Create a playable prototype using pen, paper, & other materials. You may want to create wireframes for this, depending on how closely the prototype emulates software.
    2. Playtest using the iterative cycle below.
    3. Once perfected, write a 3-6 page gameplay treatment describing how the game functions.
  4. Presentation (optional)
    1. Often needed to secure funds to hire a prototyping team. Going through the process of making a presentation can also be a good way of thinking through your game & introducing it to team members. Should include demo art & a solid gameplay treatment.
    2. If you do not secure funding you can return to step 1, modify the game to fit their needs, or find another source of funding.
    3. Minor note: this sounds a lot like the “technical defence” stage I went through at Polytech to prove that we had thought through everything before proceeding with development. In this case it was more focused on our system architecture & development platform.
  5. Software Prototype
    1. If you didn’t do so for the physical prototype, create wireframes.
    2. Create the entity-relationship diagram & system architecture. Work with programmers in forming these.
    3. Create a rough program that models the core gameplay. Try to do this without graphics, or use cheap temp graphics.
    4. Playtest the software prototype using the iterative cycle below.
    5. Once perfected, create the final interface designs (based on changes to the wireframes) & move onto documentation.
  6. Design Document
    1. Use the knowledge & notes gained from prototyping to write the first draft of a game design document outlining every aspect of the game & how it functions.
    2. Now would be an appropriate time to review everything before commencing production. Requirements, dialogue diagrams, interface designs, system architecture, everything.
  7. Production
    1. Work with all team members to make sure each aspect of the design is achievable & correctly described.
    2. Acquire your full staff & begin creation of the real game (art, programming, etc). Do the iterative cycle below for each aspect of the game. The problems encountered at this stage should get smaller as you go since all major problems should have been encountered during prototyping.
  8. QA
    1. Playtest with a focus on usability & accessibility. Gameplay should be solid at this point but problems can still arise.

The iterative cycle from Game Design Workshop remains very much the same, though I’ve added a note about changing documentation when appropriate:

  1. Generate Ideas
  2. Formalize Ideas (write down or prototype)
  3. Test
  4. Evaluate Results
    1. If results are negative & there seems to be fundamental flaws, return to step 1. If documentation from earlier in the process needs to be redone, ideally you should redo to the earliest document & redo proceeding documentation based on the changes.
    2. If results lead to improvement, modify then return to step 3. Make appropriate changes to documentation, diagrams, etc.
    3. Else, next major step

Finally, throughout the whole process, it’s worth having “daily” SCRUM meetings if possible:

  • What did I do last time?
  • What will I do now?
  • Are there any barriers in the way?

To me, this process seems to be geared towards medium – large scale projects. Sure, a lot of this would be useful for smaller projects but, if you’re like me & just trying to make your first few games, following every single step might be overkill.

On that note, I probably won’t be following this framework for the next while. I’m currently focusing on tutorial projects, but I hope to try out this process later on.

I hope this proves useful to someone.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s