Video game programming: Where to Start - a High Level Overview
(2008.02.16)
I have had a few questions surrounding how to make a video game, or more specifically where to START making a video game. Over the course of several of these explanations I have started to see a trend in my answers and thought I should impart that upon the world.
Let me preface this with I am a programmer. I enjoy building code from the ground up on concepts and requirements I either have put together or I have worked out with a requester. I have poked around and tried a few 'drag and drop' game makers and found them to be useful for certain things but I would prefer building something from the basics up. If you are impatient and want you game now-now-now you can head out now... from here on out I am going to emphasis the WORK you would need to do to make your game.
Let me answer two question up front:
Yes you will need to know a decent amount of programming to truly make a game your own. There are classes, inheritance, properties, variables, functions, and objects that all go into building components for your game.
Yes you can do this for free. Microsoft is supporting c# and XNA development that allows you to build a game for a Windows PC and also for an XBOX (360 or regular). Go here for more details: http://creators.xna.com/
So you downloaded your tools, you poked around at c# and XNA, and you are trying to find a toe hold to begin. The progression I found to work well is the following: planning and requirements, back end coding, animation and graphics, menus and sound, and testing
1. Planning and Requirements
“What? Are you seriously saying I *shouldn't* just dive into the code?” Yes, that is exactly what I am saying. If you have never put together a system requirements document then this is a good time to look into it. At the bare minimum have the following sections:
A. Small paragraph outlining the goal of the game. What do you want out of it? What should the players get from playing it? The style of game? Possibly a name.
B. A list of components in the game (users characters, enemies, NPCS, items, exits, menus, scoreboards, inventories, gravity, etc).
C. If you have components that interact write out the allowable interactions (including keyboard command and mouse interface with your game).
- Of these components list out their available actions, and values they will hold (health, attack power, defense, jump height, speed, etc)
- After you outline what they can do sketch out what they SHOULDN'T do.
- I would highly suggest grouping similar functionality into an abstract class and having classes inherit from that super class. Write out this class flow here as well.
D. Level development – what would a level look like? Is this a hugely rendered area? What are the visible render bounds? Is it a tightly focus top down view? What happens when a user transitions between levels?
- For example if you have a player-character and an enemy – what happens when one or the other touch each other? How would either damage the other?
- How does combat work?
- How do the over arching game mechanics work?
E. Art and Graphics – is this 2d or 3d? What sort of animations would you need for each object? What sort of animations should exist for the interaction of components (section c)
F. Sound – what points in the game should sound be present? Player-character actions? Interactions of components in section c? What sort of sound will you need to gather up?
G. Rough sketches of the over all game layout. Are you going to have an interactive menu on the left? Where would the player know how much health do they have? Is there going to be a right click short cut for the user?
H. Testing – how would this game be tested? Who will test it? A generic test plan write up would be good here (a more descriptive and exhaustive one should be made up when you know what components you are keeping or not).
I. Time line and division of duties. Do you have a team that is helping you out? What are you goals and milestones? Is this a three day game build? Three months? A time line helps keep you on task and pushes a sense of boundaries on when you should be turning over major parts of the game.
J. Marketing – do you plan on releasing this to XBOX live for sale? If so how are you going to get this on xbox live? How about as download able content from the web – what is needed then? If you just plan on doing this for personal value then not much needs to be outlined here.
2. C# - the back end.
Once you got the requirements beat out the you can start coding the back end. This would be where you become intimately familiar with your C# code for the XNA development. I mean concepts such as: classes, inheritance, object creation, and so on. You would need to unit test most of the classes as you build them, and arrange for them to be as descriptive as possible. If you stick to your design document above you should have no problem putting those descriptions to code. It is always easier to follow a design document than shooting from the hip – it ensures you did not miss anything from being coded and keeps you honest to your initial vision.
3. XNA side
Everything else. So your back end interaction is down start going through sections D, E, and F. Get your graphics up and running, figure a style and stick to it. Remember to animate for component interaction. Here is where you start delving into the XNA side of the game development. Timing, clipping, meshes, and other tools of the XNA API (application programming interface).
4. Testing.
Try and rack your brain for every conceivable way a user can interact with your game, force components to interact, and ferret out any issues that might arise. Push the game on to your little sibling to try out, offer a beta for the internet to poke at, and open up a support bug email box for your game (assuming you are making it for public consumption). Track your bugs in your spreadsheet program of choice. Make sure you have all bugs tested, exercised, and removed – who wants to look like a n00b and your game be released with glaring holes in it.
5. Release.
Follow your marketing release plan under section J. Get your hosting, support email line, forums, and pricing figured out if that is the angle you are going. If not at least provide a user manual and good description of your game for the rest of the world to know how to interact with your vision.
Wheew.. that's a chunk of high level information to impart, but it is needed. If anyone has a request for specific drill downs on any subject above just drop me a note on my blog.