Project Framework, Pt. 1


It’s been a while since I did any form of game development, & in my attempts at game development last year I didn’t get very far. One of my main issues was that I didn’t have much of a plan or process for my projects. Really it was just do whatever I felt needed to be done, which just left me feeling aimless.

So I’m endeavouring to come up with something I can reliably follow for most of my projects. First, I’m going to look at existing frameworks, in this case a process from a book Game Design Workshop: Designing, Prototyping, & Playtesting Games, & the framework I followed back in Polytech to develop a sex ed game up to the “beta stage”.

Game Design Workshop

I tried to do what many designers do & create the game design document way too early when I was still just brainstorming everything. Thing is, in a professional setting, designing the game right at the start of production often leads to hardship, simply because it becomes increasingly difficult to change things the further down the production line you are.

The author’s way of getting around this is to never begin production, or even the software prototype, without a solid understanding of the game.

  1. Brainstorming
    1. Come up with as many concepts as possible
    2. Narrow down to the top few
    3. Draft a short, one-page outline describing the ideas
  2. Physical Prototyping
    1. Create a playable prototype using pen, paper, & other materials
    2. Playtest using the iterative cycle below
    3. Once perfected, write a 3-6 page gameplay treatment describing how the game functions
  3. 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 or modify the game to fit their needs (I would also add the option of finding other ways to find funding).
  4. Software Prototype
    1. Create a rough program that models the core gameplay. Try to do this without graphics, or use cheap temp graphics.
    2. Playtest the software prototype using the iterative cycle below.
    3. Once perfected, move onto documentation.
  5. 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.
  6. 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.
  7. QA
    1. Playtest with a focus on usability & accessibility. Gameplay should be solid at this point but problems can still arise.

For each of these steps it emphasizes an iterative approach centred on player testing. Something like this:

  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
    2. If results lead to improvement, modify then return to step 3
    3. Else, next major step

The Agile Development Framework

The “Agile Development Framework” that I followed in Polytech can be thought of as a spiral consisting of three main loops, each focused on a different part of the project. It follows a similar iterative cycle to the process above:

  1. Understanding – communicating with the client to figure out what they want
  2. Functional Delivery – building a MVP (minimal viable product)
  3. Robust Delivery – building the final product

In all three loops are the following stages:

Taken from one of the powerpoints from Software Engineering.

Taken from one of the power-points from Software Engineering.

  1. Evaluate
  2. Functional Requirements
  3. Interaction Design
  4. Design Specifications
  5. Implementation & Deployment
  6. Return to Evaluate for the next cycle

Now to breakdown what each stage of the three cycles contain:

  1. Understanding
    1. Evaluation – Management documents, establish group & relationship with client
    2. Functional Requirements – Interview client, initial project plan
    3. Interaction Design – Ethical design, risk management
    4. Design Specification – System Metaphor
    5. Implementation – Conceptual Prototype
    6. Evaluation – Proposal to client
  2. Functional Delivery
    1. Evaluation – Project estimates, client feedback, knowledge base
    2. Functional Requirements – List of requirements, user stories => requirements
    3. Interaction Design – Interface design, user/environment analysis, design theme, ERD (entity relationship diagram), interactivity testing
      1. Task analysis => dialogue diagrams => wireframes => interface designs
    4. Design Specification – Style guide, system architecture, background development
    5. Implementation – Stable development platform then MVP
    6. Evaluation – Analysis of MVP, mid-point reflection
  3. Robust Delivery
    1. Evaluation – Direction for iteration 3, scoping for final delivery
    2. Functional Requirements – Revisit requirements list
    3. Interaction Design – Update designs & concepts, content production
    4. Design Specification – Style guide, system specifications, implementation & deployment plan
    5. Implementation – Robust delivery
    6. Evaluation – Project evaluation & completion

In a team setting, though this can prove useful even if you’re working alone, you also have daily (well, every time you meet up) SCRUM meetings. These are only supposed to be about 10 minutes & consist of:

  • What you did yesterday?
  • What you will do today?
  • What barriers, if any, are there to your progress?

Lastly, it’s important to keep the client in the loop as much as possible, typically in the form of weekly meetings.

Now with all of that laid out, I’ll be taking aspects from each of these to form a framework for my own projects. I haven’t gone through that yet, & this post is already quite long so I’ll have my results in part 2.


2 thoughts on “Project Framework, Pt. 1

  1. Try not to think of the design document as a set-in-stone commandments. Think of it as what they call a ‘living’ document. It evolves and changes are you and your concept evolve and change. I found thinking about it this way, and treating it in this fashion, prevents a lot of that issue.

    And agile is really great for game development. The sprints really lend itself to adding features, and the consistent testing phases at the end of each sprint help iron out a lot of bugs.

    Are you going to use it in your development?

    • I’m planning on following a revised framework I came up with in part 2 as closely as I can. Since it’s early days, I won’t be doing every single thing on the list, but to me it seems like a good way to go about it.

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