A short outline of the common phases of game making, in roughly the order you should be embarking upon them, and some advice on how to go about them.

  • kentona
  • 05/26/2015 10:42 PM
GAM MAK /gam/ /mak/ (n.)
1. The process of developing games with a hobbyist mindset, being mindful of the limited scope of both your skills and potential audience but aspiring to create a meaningful experience for both the potential players who play the game and yourself while you work on the game.

2. Purposeful mispelling of "Game Make", in a facetious nod to the serious business of game development.

See also: Game Make; Game Development


Let's just jump right into it, shall we?

KEY DELIVERABLE: A ranked and evaluated list of game ideas

The phase that most people never escape is this first one - the brainstorming phase. It is so much fun coming up with ideas. At least, I think so. So many of my projects are stuck in this phase that it makes me wonder if I am qualified to speak on the subject.

1. Write your all of your ideas down in a big ol' list
2. Rate each list item on a few scales, like:
-Ease and effort of development
-What kind of art/assets it would require
-How fun it sounds to play
-How fun it sounds to implement
3. Go through the list and evaluate the items. Discard bad ideas.
4. Sort remaining into Needs and Wants

SIDETIP: Have handy a way to quickly jot down ideas that you have at any time. Besides helping prevent ideas being lost to the aether of spacetime, it frees you up from stressing about implementing them immediately.
  • Carry around a notepad and pen
  • Jot things down in a Memo app on your smartphone
  • Have an open text document at all times on your computer
  • Have a document going on something like GoogleDrive or Dropbox

Jot down your thoughts.

I like having a massive text file with all of my notes and high-level ideas handy at all times. At home I have a PC and at work I have a PC or laptop, so what I do is keep that text on my GoogleDrive and have it open all day and update it regularly. (I wrote a draft outline to this very article in said text file, in fact!)(As an aside, it is currently sitting at 2927 lines and 130kb in size)

This is an ideal time for creating a bit of concept art.

KEY DELIVERABLE: A refined vision of your game

To see your project through to completion you need a clear vision.

Answer these questions:

1. What do you do in the game?
2. What is the game about?
3. What feelings are you attempting to evoke?
4. What are you trying to express?

Like other art, games are a form of self-expression. They are a venue to express a part of ourselves to greater world, and to explore a part of ourselves in the process. Games can also be evocative, so you have to be mindful of what kind of emotions you wish to evoke in players. Are you trying to scare them? Make them feel powerful? Helpless? Answering this will help you determine how the player will derive satisfaction from your game - by, say, overcoming challenges or conquering their fear or solving the mystery. But last but foremost, games are an interactive medium, so you really have to nail down what a player would do in your game. Jump n' Shoot. Hack n' Slash. Move around on map, collecting resources, distributing those resources effectively to overcome the random number generator engine. Or whatever. Figure it out.

Next, write the pitch.

That's right. Based on your brainstormed ideas, and the way your framed your game, write a pretend pitch to a potential game publisher. Sell your game. What makes it exciting, engaging, worthwhile?

Now back up and revisit your long list of ideas, and reevaluate them in light of your focused intentions.

..:: DESIGN PHASE ::..
KEY DELIVERABLE: A master Game Design document

How you go about designing your game depends a lot on what kind of game you are making. But in any event, it is worthwhile to invest time into design BEFORE jumping into development. I know, I know - you are just brimming with excitement from that brainstorming phase and just can't wait to make it a reality. Slow down there, buster! It's time to take a step back, take a deep breath, and THINK.

As a high level rule of thumb, make a rough sketch of the game in action. Maybe storyboard it, if the game lends itself to that kind of abstract representation. HOW TO DESIGN GAM is a bit outside the scope of this article, though. (It's a big enough subject to warrant its own article. You should write one!)

Since I primarily make (made?) RPGs, I will give examples based on what I do.

  • I list out the main gameplay elements (classes, skills, equipment, game mechanics, stats) and jot down short descriptions
  • I plot out major plot points for the story
  • I make a list of the major characters (playable and unplayable)

  • I write out rough drafts of important dialogs (intro, major scenes, finale, etc...)
  • I make a list of important locations in the world
  • Do a bit of worldbuilding
  • I expand the main game mechanics and try to conceptualize them in full
  • I iteratively flesh out the characters, world, and story
  • I refine the other gameplay elements to work with or better complement the game mechanics
  • I sketch a world map or important areas

This eventually evolves into my master Game Design document, that is constantly referenced and updated when I am working on my game.

KEY DELIVERABLE: A game framework to base your game on

Make a no-art (or RTP-asset) early playable version of your game. The no-art approach is ideal for prototyping: it saves time, helps you figure out the bugs, and forces you to focus on the "feel" of the game.

This is the phase in which you test out the feasibility of some of those grand ideas you had. Remember: an idea is pretty much worthless until it is implemented. You'll often find that you will have to go back to your design, your games focus, and even your brainstorming after you begin prototyping.

I sometimes make a brand new dummy project at the beginning of a new game, to quickly test the feasibility of ideas right then before I invest too heavily in their design or incorporating them into my game.

It is during this phase that I tend to hunt down or request scripts, and test their intercompatibility.

At the end of this phase I hope to have a solid working framework for my game, that I can build my story onto. Because, trust me, you do NOT want to have to go back and retroactively fix or modify an essential part of your game's framework deep into its development. It is so tedious that it is a real motivation killer, and could spell doom for your project. All your systems should be a GO! (well tested, well thought out, fun) by the end of the prototyping phase.

I try to have all of my databasing done at this phase, too. If all of your planned items and equipment and skills are made, it makes implementing them in the game's maps much cleaner.

If you are building your game from scratch, or in a more open-ended tool like Unity, it is during this phase that you construct your engine.

..:: PRETTY PHASE ::..
KEY DELIVERABLE: Art and sound assets, and an overall aesthetic design

Start to add polish to your minimum viable product. Look for, create, or request assets now. (and don't do it before now, because chances are you will just be wasting the time of your artist or composer (even if that artist or composer is you! Don't waste your own time)). It is important to get your assets and aesthetic lined up

KEY DELIVERABLE: A playable game

Work on only one feature at a time. Avoid working on a little of this or that all at once. Focus on one task and finish it to the minimal basic complete state before moving on. Half-implemented tasks are useless.

This is core implementation and development phase of a project. It is here that you are doing all of your mapping, writing all of your dialog, animating all of you cutscenes, making all of your enemies and battles, and hiding all of your Tiny Medals in various pots, chests, bookshelves and buckets around the realm.

I tend to work chapter by chapter when I get to this phase, starting at the beginning and working my way one major plot point at a time to the very end. Some people like to jump to the more exciting parts first, but I find that the story evolves as you make it, which might render some of those later parts moot or unapplicable to the direction your story has taken.

Only once you achieve this "pretty feature playable" are you certain to hit the finish line because from now on you could conceivably ship it/release it.

SIDETIP: Keep multiple backups, savepoints and versions.
  • Remember to save this playable version of the game somewhere other than your working folder.
  • Always aim to create many iteratively improved and incrementally enhanced working, functional, executables.
  • Store backups in multiple places: GoogleDrive, OneDrive, Dropbox, RMN, thumbdrives, external drives, your work laptop...

KEY DELIVERABLE: A tested and polished complete game

Here are the three key components of this phase:
1. Testing
2. Testing
3. More Testing

Play the shit out of your game. Polish that shit up til it gleams.

You might have released a demo in the previous phase. Use the feedback from your players or testers to find bugs, plotholes, weaker areas of the design, or poor presentation and resolve them the best you can.

Once you have that polished, tested, gleaming game: release it.

...and then quickly patch it for that game-breaking bug you inevitably missed. It always happens. Don't feel too bad.

Congratulations! You have released a game!


Pages: 1
Thank you, Kenton. Your articles are always a great read, particularly in my present darkness of struggling with gam-mak.

At the end of this phase I hope to have a solid working framework for my game, that I can build my story onto. Because, trust me, you do NOT want to have to go back and retroactively fix or modify an essential part of your game's framework deep into its development. It is so tedious that it is a real motivation killer, and could spell doom for your project.

This is exactly what is happening to me atm.
Yup!! I agree with all of this stuff, especially all the parts about prototyping and brainstorming. I used to always play around with brainstorming and jump right into prototyping / prettying in RM or Unity, without seeing the major flaws smack in the center of my plan. I still do sometimes and it always comes back to bite me...

Every bit of time you spend in the Brainstorming, Framing, and Design phases saves you tons of effort later! I've found that, before touching an engine, paper prototyping is really useful. It's easy to do with turn-based RPGs and if you simulate little battles on paper, you can often spot conflicts in your mechanics, and save yourself a ton of time you would have spent coding first.
Thanks. I begin to wonder though if I am actually saying anything of merit at all. But my motivation for writing these is also a bit for myself, working through my own inertia and indecision.
For sure! It's a good way to crystallize your process.

You should totally write an article about how to gamedev when you only have 30-60 minute spurts XD
For sure! It's a good way to crystallize your process.

You should totally write an article about how to gamedev when you only have 30-60 minute spurts XD
When I figure out how to do this, I will.
Pages: 1