Mobile Zone is brought to you in partnership with:

Hello! My name is Ed Donahue and I'm a Technical Evangelist for Microsoft in the Mid-Atlantic region. I work with students and professional developers in Maryland, Washington, DC, Virginia, West Virginia, North Carolina and South Carolina. My favorite part of my job is enabling people to create awesome projects based on Microsoft technologies like Windows Phone and Windows 8. I'm passionate about getting women more involved in the creation of technology. (Start building your Windows 8 app today!) When I'm not working, I love traveling, cycling, going to my local farmer's market and sometimes attempting crafts I've seen on Pinterest. Ed is a DZone MVB and is not an employee of DZone and has posted 2 posts at DZone. You can read more from them at their website. View Full User Profile

Windows 8 Game Development 101, Part 1

09.29.2012
| 6570 views |
  • submit to reddit

In this series, I’m going to go over some basics of game development. While this series is targeted at beginners, you’ll find yourself going through these motions for every game you create. I hope you find something useful and happy developing! UPDATE: Go back and read Part 0 or move forward and read Part 2!

Game development is an industry that involves tons of different areas. Programmers to MBAs can find a place in the video game industry. If you’re starting out with game development, things generally fall into three categories:

  • Planning & designing
  • Programming & testing
  • Asset creation: art & sound

As this is Part 1 for Game Development 101, I’m going to focus on the Planning part of game development. The very first thing you need to get started with game development is an idea. Based on this idea, you’ll want to create some game design documents that will help guide the game as it gets further into development. These documents will be used to express the vision of your game to others, such as developers or designers. It’s best to put as much detail into these documents as you can, however they are living documents and you should update them as necessary.

While you can have as many documents as you need to describe your game with what ever titles fit best, you should think about including three core documents:

  • Storyboard: This is where you draw out what you want your game to look like. Storyboards can be complex and detailed or simple. In the story board you can map out how you want a level to look or character design. Check out these examples of storyboards. Think you don’t need to storyboard? Pixar storyboards games!
  • Game summary: This where you describe you game, its objective, the story and other details that might not have fit into the Storyboard.
  • Flow chart (great for simple gameplay, like Rock Paper Scissors Lizard Spock): This is where you map out the interactions and game updates for game play. Here are two examples of flow charts that have been made for games. By using a flow chart, you can map out all the player’s decisions and it can help you decide where to put things like sound effects, animations or help screens.

db2e_lizard_spock

These documents should outline and describe your game in such a way that someone else would have a pretty good idea of what your vision is for the game. The documents should cover the core objectives of the game and talk about features of the game & implementations. They should also cover things like characters, enemies, levels, music & sound effects, dialog, player interactions, user input, etc. When you’re done with creating your planning and design documents, you should have at least answered the following questions:

  • What kind of game is it?
  • What is the game objective?
  • What are the game play elements?
  • What are the engineering elements?
  • What art assets will you need?

Now you should have a pretty good idea of what exactly is needed to create your game. Art assets, sound effects, transitions, animations and more should all be referenced in your design documents. Taking the time to plan out your game can show you where you are missing documentation and it can save you time later in the game development process.

Stay tuned for the next Game Development 101: Part 2 where I talk about the game loop.

 

 

Published at DZone with permission of Ed Donahue, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)