The Game Plan: Getting Started

Leave a comment Standard

Your game design can run fairly smoothly or it can be a continuous cesspool of hardships and setbacks and pain points. In the next few series of posts I’m going to try and help walk you through the process of getting your game up and off the ground, from what you’re envisioning in your head to an actual working version. So, let’s get started.

1. Get It Out Of Your Head

It’s time you pull out a pencil, pen, or open your laptop to a writing program. First thing’s first, you have to get your game out of your head. Write it down and put it somewhere you can reference it later.

2. Writer’s Block

So if you’ve opened a text editor or you have a pen in your hand you’ve successfully completed step one. Now, what do you write? I like to start with the five W’s:


  • Does your game appeal to a specific age range or interest group or gender or even ethnic background?
  • Will you have a large audience your game will appeal to or a small audience?
  • What are the benefits and downsides of the audience you’ve identified?


  • What kind of game are you trying to make?
  • What programming language best suits this kind of game?
  • Does it fit into a specific genre of game or does it span multiple genres?
  • Does it embody a completely new genre?
  • Can you find other games that are similar to the game you are trying to make? If so, what do these games do well and where do fall short?
  • Are there lots of other games on the market similar to the type of game you’re trying to make?
  • What will your charge for your game?
  • What do other, similar games of this type charge?
  • What are the benefits and downsides of the type of game you’re trying to make?


  • Where does your game take place?
  • What kind of maps or features or environment are unique to your game?
  • What are the benefits and downsides of where your game takes place?


  • When will you have time to work on this game?
  • When can you start this game?
  • When can you fund the development of this game?
  • What are the benefits and downsides of developing this game?


  • Why are you making this game?
  • Why is your game unique?
  • Why will your game stand out from the crowd?
  • Why will people choose to play your game over other similar games?
  • Why will people pay for your game?
  • What are the benefits and downsides of making this game?

3. Make A Design Document

Your design document is a refined version of everything you’ve written down in step 2. Go back and really analyze what your goals for the game are and if what you’ve written down makes sense in the larger picture. Sometimes a good idea you have for one area of the game will conflict or make another part of the game tedious, uninspired or downright frustrating. For a game design document I like to use the following format:

  1. Intro
    • What is the vision for your game and a short description of how the game is played
  2. Audience, Platform & Marketing Strategies
    • Who the game is for, what platforms you’re making it for and what sets your game apart that will make it marketable and different from others
  3. Core Gameplay & Mechanics
    • How the game is played including physics, rules and limitations
  4. Characters
    • What characters are in your game including what they look like, their names and backgrounds and personalities
  5. Story, Themes & Twists
    • If your game has an overarching story then you’ll outline your plot and how the game progresses with the story line
  6. World
    • Describe the world your game is set in, including maps and locations and their purpose or importance
  7. Assets
    • All the different images, music, animations, etc that you will need to have a fully functional game
  8. Technical Specs
    • What language you’re using, how games are loaded/saved, where games are stored, the number of servers you’ll need and anything else relating to the technical setup of your game
  9. Interface
    • What the game interface looks like and how the player will interact with it
  10. Outside References
    • Articles, links, design inspriations, or anything else that you’re using as a reference for the game you’re making
  11. Appendix
    • Code style guidelines, dictionary of terms, and anything else that is important for understanding your design document that may not necessarily relate to your game directly

Once you’ve fully fleshed out your game design by going into depth about the features, physics, economy, weapons, characters and how the game works it’s time to break it down. Start by creating lots of of small, easy tasks you can accomplish in order to see your core game mechanics to completion enough that you could play a simple version of your game without any extra bells and whistles. Set yourself up to do as little as you have to but as much as you need to in order to get a really simplified, yet completed, version of your game.


Scrum Mastering

Leave a comment Standard

Note: this is not a comprehensive post, just stuff I picked up during my recent scrum master certification class. Take from it what you will 🙂

What Is It?

Daily standup meeting, maximum of 15 minutes. 7 people per scrum team is the best setup, 10 is iffy. Open space is best for scrum because it keeps people alert and standing means they’ll be paying more attention. Best to do the standup meeting in an empty room.

Product Backlog

Composed of user personas (ie who will use your software, what kind of person are they) ordered from highest importance to lower importance based on who is the largest user base, how much $$ they have, how frequently do they will use it, what kind of social impact do they have, features specific to them and features shared. This is used to help the product owner determine the business value and priority of each user story. These are then taken to the release backlog. This is who the product is for. In the picture below, features are placed horizontally for the user persona they apply to and turned sideways to indicate they are core functionality. These features are turned into user stories. Typically agile teams will tackle core functionality first since it spans multiple user stories.


Sprint Task Board

Kanban board (Japanese work meaning status, graphic). Has three columns, TODO, IN PROGRESS and DONE. TODO section contains the tasks to be completed also known as Sprint Backlog.

User stories are high level concepts that are broken into tasks which can be completed. User stories should be completed in a single sprint.

Tasks are estimated according to time.

User stories are assigned story points according to complexity of the story.

When you’re planning a story/tasks you plan to keep them busy for 70% of their time since the other 30% might be discovering things that you’ve missed.

Decomposing user stories into tasks is done in the sprint planning meeting.

QA testing should be done once the story is done rather than each individual task.

If you have a separate QA team then you need a QA task for each user story. The QA team would estimate the value.


Sprint Burndown Chart

A chart of the progress done over time. It starts with the total number of estimated minutes and drops as time passes.

A typical sprint has little work and then the work is added and then it falls over time. If that’s happening then you’re not planning your sprints properly and you’re not protecting the sprint (ie adding more work) when you should be. In this case you can see the team has a clear planning issue, therefore the curve of the sprint burndown will be more of an downward trend.

When you start achieving complete sprint burndown you might not even need to use this chart anymore. It’s like training wheels on a bike, once you’ve figured it out you won’t need it anymore.

Release Burndown Chart

This is a similar concept to the sprint burndown except it’s used with sprints instead of with sprint tasks. By calculating the velocity you can add and remove user stories from the release planning in order to get all the story points done in the year.

Definition of Done

The processes that need to be completed for each User Story are put up on a checklist and then each part is checked off as it’s completed. Once all checkboxes are marked the User Story is considered done.


Sprint Backlog & User Capacity Chart

Setup a user capacity rundown chart to help organize the team and figure out how much capacity you have for the sprint. The picture below shows the sprint taskboard and the sprint backlog. The white piece of paper is the user capacity chart. User capacity starts with 80 hours for the 2 weeks and then goes down if team members will be out/vacation. Then you add some buffer for other stuff they might end up working on or tasks taking longer than expected. Next you start asking who wants to take which tasks and use up the remaining capacity. This will also help you figure out if you can take on more work or have too much work for the sprint. This is how the team plans to accomplish the sprint goals.


Team Calendar

Recommended team calendar setup. Backlog grooming will help you start to plan your user stories for the next sprint. DSM = daily standup meeting.


The Agile Manifesto

Winston Royce invented the waterfall model by documenting what his team was doing during their development process. The core values of the Agile Manifesto are:

Individuals and Interactions – over processes and tools
Working and Software – over comprehensive documentation
Customer Collaboration – over contract negotiation
Responding to Change – over following a plan

The principles behind agile are:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
  2. Welcome changing requirements, even late in development. Agile process harnesses changes for the customer’s competitive advantage.
  3. Deliver working software frequently. from a couple of weeks to a couple of months, with a preference to the shorter timescale
  4. Business people and developers must work together daily throughout the project
  5. Build projects around motivated individuals. Give them the environment and support they need, and thrust them to get the job done.
  6. The most efficient and effective method of conveying info to and within a dev team is face to face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity — the art of maximizing the amount of work not done — is essential.
  11. The best architectures, requirements and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts behavior accordingly

Empirical vs Defined

Defined is something that has architecture and structure, ie a sewing pattern. Empirical is something that isn’t well defined, ie a custom made garment made without a sewing pattern. Software is inherently empirical. The first time you make a feature that you’ve never attempted before you won’t know how long it’s going to take and how much effort it requires therefore you can only provide an estimate. Something that is well defined has been done before therefore you can give a set amount of time and effort to complete the task.

Output vs Outcome

We often focus so much on the output that we forget about the outcome. Producing more code/features doesn’t necessarily mean you’ll have a better outcome. In terms of Agile and Scrum outcome is more important than output.

Product Owners

Agile Is Just That

Since Agile is a set of principals there’s many different ways you can accomplish it. Here’s a look at the Spotify engineering culture which has been using Agile from the beginning. You can quickly see how they’ve deviated from what most people consider the “traditional” ideas.

Scrum Developers

6 people per team, 1 of them is scrum master, is a good idea because it allows them to pair up for pair programming.

Motivating Your Team

Autonomy and mastery and contributing are better motivators than money or bonuses or prizes.

Golden Circle

A. Why you want to create the product (should invoke a vision/feeling)

B. How you’re going to create the product

C. What you’re going to do to create the product backlog

Useful Team Activities

2-Dimensional Axis Chart

X axis is used to denote how much something was successful or unsuccessful (loved it vs hated it). Y axis is used for time. Sticky notes are then added to correspond with the features/activities that occurred. This lets people vote someone anonymously and gives you a feel of what you could work on improving.

Planning Poker

Create cards (100, 60, 20, 8, 1) that represent the story points which are tied to the complexity, effort and cost to create the feature. Assign those values to the user stories via vote (majority wins, hear from outliers and re-vote after). Adding all of those up will give you the total user story points for that release.

Dot Chart

Take the items you can improve from the previous chart and put them on a new graph. Now have people come up and put a dot next to those they feel most passionately about, a larger dot indicates they feel more strongly about it. This will help you identify the areas where the majority agrees there is room for improvement. Sorry it’s blurry.


After a Team commits to sprint goals what authority do they have?

The team does whatever is necessary to achieve the goal.

How are development teams guided during a sprint?

By their collective knowledge and experience.

From Product Vision to Your First Sprint

  1. Create the product backlog from the golden circle design
  2. Create the user personas
  3. Create the user stories (product backlog)
  4. Move the stories into the release backlog
  5. Move the stories into the different sprints
  6. Create tickets for the sprints
  7. Move the user stories from the release backlog into the sprint task board when your release backlog is done being planned.
  8. Now create 7-10 tasks for the user story
  9. Discover any dependencies between the tasks
  10. Now we have to estimate how long it takes to complete the task using 8, 4, 2 and 1 hours (finger voting). Any task that everyone votes for an 8 is too complex and needs to be split into additional tasks. User stories should be completed in under a week, if your user stories are indicating more than 40 hours then you need to split them up.
  11. Once you have the sprints planned it’s time for capacity analysis.
    1. For someone with an 80 hour sprint you should expect that they only have 55 hours of actual work time — this accounts for buffer time.