While every project may be different and be built differently, there often many common considerations and decisions that need to be made. This article aims to provide a sort of “framework” that you can use when planning and making decisions for your team and project.

This article is a mix of our own discoveries along with content from articles found in the Additional Resources section below.

Ideation #

Most games revolve around a 10-30 second gameplay experience that is repeated endlessly. This concept was described as a core foundation behind the design of Halo. This should be the core of your game and if this isn’t fun, it’s unlikely the final game will be any fun either.

Create a Game Design Document #

If you have a game idea in mind, the first step is to get it out of your mind for others to be able to understand your vision and help evaluate it. Such a document is referred to as a “Game Design Document” or GDD. This document will serve as a foundation for your idea as well as a guide to follow throughout the development¹. Your GDD does not need to outline every last detail for your game. Focus on the broad, critical strokes that are unique to your vision².

This document should help you (and your team) iron out details about how mechanics and concepts work, especially in concert with one another. It also makes it easier to onboard others to your project and ensure everyone involved has a clear understanding of the end goals. If the people you ask for help can’t see your vision right at the get go, they’ll quickly lose interest. Even if you plan to make a game on your own, things can get out of control if you don’t have a solid plan to follow.

To help get you started, here’s a list of questions you should try and answer in your game design document:

• What’s the core “hook” of the game that makes it fun and brings players back?
• What would the player(s) experience in a typical play session?
• What’s the genre(s) of the game (action, adventure, RPG, battle royale, etc)?
• What’s the planned perspective for the player(s) (1st person vs. 3rd person)?
• Does it have multiplayer?
  • If so, is multiplayer the focus of the game? Or is there a single player component?
• What type of interactive structure will there be (chapters, levels, maps, acts, etc)?
• What’s the basic interactive design?
• What’s the planned interface (UI and controls)?
• How difficult is the game?
• How long will it take the average player to complete?
• How long should a typical play session last?
• If there’s a story or narrative:
  • What’s a synopsis of the overall story?
  • What’s the full story (going more in-depth)?
  • What sort of scenarios are in the game? Are there cinematics and cutscenes? Where in the story do they fit?
  • Who are the actors / characters involved?
    • Who are the primary, secondary, and tertiary characters?
    • Who are the heroes and who are the villians?
    • What are their motivations and why should we care?
• Do characters talk? Or is dialog handled through a written/visual medium?
• Describe each mission or level of the game (as applicable).
• Describe the preliminary maps of each level or missions of the game (as applicable).
• Does this game target one core audience or multiple audiences?
• Who’s the target audience and what are their expectations of a game like this?
• Is this a game for hardcore gamers or more “mass market”?
• What’s the key competition for this game?
• How does this game compare to its competition?
• What does this game offer that the competition doesn’t?
• What does the competition offer that this game doesn’t?

Create a Paper Prototype #

A paper prototype doesn’t actually have to be made of paper. Instead this refers to the concept of creating simple visual elements that further expand on your game’s concepts and allows you to test the game without writing an actual line of code. This can allow you to explain, test, and iterate on your concept much more quickly than jumping into a game engine. Especially since it can be incredibly easy to turn your prototype session into a yak-shave where you wind up implementing more than originally intended.

For example, if your game is an RPG you could test your stats / battle systems / story through a simple pen & paper representation of it. Grab a friend and have them test the concept with you, Dungeons & Dragons style.

If you have something less analogous, make some loose mockups/drawings showing the different states that the game could be in with an explanation of how you go from one state to another.

Create your Technical Prototype #

The goal of the prototype is to create that core 10-30 second experience³ to ensure that it’s as fun in reality as it was in your imagination and paper prototypes.

• If it’s not fun, tweak it until it is.
• Don’t waste time on fancy graphics at this stage⁴.
• If you can’t make it fun now don’t assume that adding more crap around it will make it fun later. That’s highly unlikely.
• Once it’s fun, continue to add the core features (in a very rough but functional way) that you believe are essential to your game concept. It’s better to make sure the whole concept works now before you waste too much time on a dud.

The prototype can take anything from an hour to a month depending on the complexity of your final game.

If it’s not enjoyable now it’s unlikely that it ever will be. Don’t build a game on broken foundations.

Implementation #

Now that you have a decent prototype it’s time to plan out in a very rough way your schedule for the project. If you don’t have a schedule you will fumble around endlessly wasting time and never get the thing done.

Create a Milestone Outline #

List all the core features that your game will need.

• Don’t detail how you will achieve them, just list them. You may not even know how you will achieve them at this stage. It’s also worth listing all the essentials that every game needs eventually - things like save game functionality, a website, settings menus (key rebinds, audio, graphics settings, etc).
• Do this in broad strokes. We are not looking to list every minute detail here, just an overview of the big picture - each big job.

• Total up the time for everything. Now double it! Seriously. Even if you are very conservative in your estimates, almost everything is going to take longer than you expect, and you are going to run into endless jobs that you never predicted.
• If the final total is not something that you think you can achieve reduce the scale of your project and repeat the above process until you arrive at something manageable.

Break the Milestones Down #

Validation & Iteration #

Additional Resources #

• Pluralsight: Practical guide to planning your first game
• r/gamedev: My tips on how to plan a game, stay motivated and get it finished.