Making a Video Game from Start to Finish: An Overview for Beginners
by Joseph Tkach and Zach Aikman

Game development starts with an idea or inspiration. It's kind of like magic. You think, "Hey, what if there were a game like this, and like that, and with elements of this?"

But building a game is like any other formidable task, like building a cathedral or writing a novel or painting a picture. Building a video game takes passion. It takes dedication. Some might even say it takes obsession. It takes a great deal of your time, energy, and thought. It's never finished. Even when it's technically finished, you find things, new things, little things, that you could correct or change or fix.

It's a very demanding and highly stressful endeavor. If you don't love it completely, with all its misgivings, you'll quickly grow to hate it.

There are several things that a person who has an idea might do in order to make it into a reality, and that's what we'll share with you today, based on our experiences creating a games as students at DigiPen Institute of Technology.

The Game Design Document
One of the first things you need is a game design document.

The game design document, or GDD, is a collection of information that describes every aspect of the game from a design perspective. It describes how the menus will react to user input, the backstory behind the main character, the art, and what experiences the player should have while playing the game.

In theory, a person with your GDD should be able to make your game without ever needing you to discuss it and clarify. It should be a perfect and complete guide to realizing your idea as a finished game.

The GDD serves multiple important purposes. It helps you to explain your ideas to other people so that they can join you in realizing them, and it allows the development team to share a common conception of the project on which they are working.

After you have a design and your idea has taken shape, you need two groups of people: some people who will make your game and some people who will cough up the money to pay all the people who will make the game. The first group of people is your development studio or game studio. If you're an employed developer, you're already employed by one of these; but if you're working independently or are part of a student group, you sort of become this entity of your own accord.

The second group of people is called the publisher. A publisher pays your development studio for the production of the game. It also pays for the marketing of the product, and in exchange, it keeps most of the profits. To win the financial backing of a publisher, it is usually necessary to make a pitch.

The Pitch
When you pitch your game to a publisher, you give the publisher a short presentation that describes your idea, target demographic (the people who will be most interested in the game), and why your idea is the one they should fund, instead of any hundreds of others. It's often helpful to have a demo, a rough and incomplete version of your game, so that you can effectively communicate what your game will be like. In other words, by the time you are ready to pitch an idea to a publisher, you should already have some kind of working game. It doesn't have to be a great big years-long finished product, but it does have to be playable. Publishers aren't interested in ideas alone. They want to see a prototype.

In our experiences as student game developers, passion is critical to a successful pitch. If you're passionate about what you're doing, your passion will be contagious, and people will be receptive to your project. If you don't care, then no one else will either.

If a publisher likes your pitch and agrees to publish your title, then production of the game begins. During the production process, the publisher will undoubtedly schedule several milestones that your development team must reach on time in order to continue with the next leg of the project.

The Technical Design Document
One of the first and most basic requirements of any game that has just started production is a technical design document.

Much in the same way the game design document describes how the game should look and feel, the technical design document describes how the game will function behind the scenes to meet the specifications of the GDD. Everything about the game, from a technical perspective, needs to be documented and planned out from the start. The rest of your teammates will be referencing this document heavily throughout the course of the project, so it's important that the architecture for your project is laid out as cleanly as possible.

Not only does the technical design document need to describe the structure of all your code modules, it also needs to list any additional software you'll be using, any coding standards you wish to enforce, and the minimum system requirements for your final product. The lead programmer on your development team would be a prime candidate for the writing of this document, though it's important to ensure that he or she has solid technical writing skills. A skilled programmer should not be put in charge of writing a document that everyone on the team will use if she or he is not capable of effectively communicating advanced technical concepts.

The Engine
Now that the game has been described inside and out, you can start assembling the pieces that were laid out in the technical design document to form the most critical part of your game, the engine.

In game development, the "engine" is not a physical machine. It's all the core code in the game, the code that's invoked to perform physics calculations, talk to other computers over a network, draw the graphical elements in the game, play the audio, run scripts, and manage the artificial intelligence. Though games appear to be made of swords and dragons and spaceships, under the hood they contain complicated mathematics and science.

Because all this math and science is quite difficult for a human being to churn out, many developers choose to license an existing engine, such as Havoc or Torque. By using someone else's engine in your game, it's often possible to save significant amounts of time and money, allowing your team to focus exclusively on making the game they have set out to make, rather than focus on building the engine on top of which to build a game. Using an existing engine saves you that huge extra step.

Some development studios create their own engines, such as Valve (Half-Life) or Epic (Unreal). Though this can be very expensive, there are two huge advantages. The first is that they can design and control the technology in their games to make sure it meets their technical specifications exactly; second, if a company creates a high quality engine, it can then license it to other companies and make big money doing so.

The engine of a car is not the car itself, and similarly, the engine of a game is not the game. It contains the technical framework on which the game is built, but it generally does not contain any of the game code, or the code that tells the game, for example, "If the player has 10 points, then advance the player to the next level."

Instead, engine code contains the mathematics that calculate when two objects collide, or process when another computer joins the game over a network. The game code invokes the engine code to achieve specific goals, in much the same way that a driver operates a car.

Content and Art
In addition to the engine, a video game must have content and art. Ideally, the content of a game -- that is, the levels, characters, music, and art, which includes textures, 3D models, and animations -- will be separate from the game engine, allowing the developers to easily make modifications to them as the needs of the project change.

One of the first lessons our development team learned since we started making games is that producing levels, stories, and other aspects of the in-game content is deceptively difficult. It takes a huge amount of careful consideration to make content that is both compelling and intuitive.

The content, everything with which the player interacts, must be complex and rich in a way that facilitates the player's suspension of disbelief while simultaneously being intuitive and approachable. Many of the things that seem, to a designer, to be easy to understand are quite difficult if you don't have the benefit of having designed them.

Producing all the content in a large game is a task that feels simple because when it's done well, the effort that went into producing it is invisible.

Focus Testing
At some point in production, the game theoretically begins to resemble the vision that the designers had for it. It's at this point that it becomes critically important to start focus testing.

As the project comes together, there's a kind of euphoria, a sense that you have built this wonderful and amazing thing quite literally from nothing at all. You created it from only the swirling visions inside of your own head (and a few computers and programs). It's an incredible accomplishment. But in order for everyone else to see your accomplishment in the same way that you do, it's necessary for other people, people who are in no way connected with the project, to play your game.

Focus testing is a series of really harsh blows to your ego. You've spent so much of your time and effort and energy working to make this project a reality, and now, when a bunch of strangers who have never even heard of you play your game, they don't understand it. They have trouble navigating the menus. They don't understand where they're supposed to go, what their objective is, who they're supposed to talk to, or where they're supposed to jump.

As the developer, all the answers to these questions are totally obvious to you, but to players seeing your game for the first time, these things may be difficult or impossible to understand.

However, by conducting focus tests it's possible to see what things are difficult for players, and then fix or improve them. During this phase of the production the original vision will likely change in small ways to correct the flaws in the project. By continually focus testing and refining the gameplay experience, you can create a polished final game.

Launchpad
Now that the game is ready to ship, you're ready to begin your career as an internationally acclaimed rockstar game developer.


Zach Aikman is a student of video game development and production at DigiPen Institute of Technology. Currently in his fourth year, he has completed three student game projects, including Synaesthete, which was recently featured in various independent game competitions. His technical interests are in game engine architecture, tools programming, and establishing himself as a Zach-of-all-trades.

Joseph Tkach is an aspiring game developer with a somewhat frightening fixation on particle systems and post-processing effects. Every time he tries to create a game design, it ends up being a psychedelic music game, and he's okay with that. Tkach is currently in his senior year at the DigiPen Institute of Technology