Ah good ol' game programming, such a rewarding and fustrating hobby at the same time. You could be trying to create the next quake, or maybe you are looking to just mess around and see what you can do. Either way its going to be a blast.

But before we get started, there are a few things you have to take into consideration. First off, What are you going to be programming on? Are you looking to code for Windows or Xbox 360? If you are going the Windows approach, all you will need is a copy of the XNA Workshop. And if you are developing for the Xbox360, you will need XNA Workshop and an active subscription to XNA Creators Club which is around $35 a year.

That being said, the whole development environment revolves around C#. There is no C++/C/ASM, so dont even look for it. If you are new to C# or have never coded in it, it can be a bit different to work with. If C++ and Visual Basic had a baby together, we could call it C#.

Once you install the development kit, there are a few tutorials kicking around on that install. Take a look at them, because it can be helpful in learning this new API.

Alright lets face it if your new to game design or not too familiar with it; Starting off wrong can fustrate the hell out of you.

Every game out there has some sort of "state management", from a menu system, to a pause screen, they are all game states. The best way to think of states is like some nice pankcakes. I dont know how you eat your fluffy cakes, but I eat mine on a stack. If you are unfamiliar with what a stack is (in computer terms), a stack operates on a "Last In, First Out" basis. Whatever is on top of the stack is what is next to get processed, and all other processes are idle. Now on that stack item is known as a "node".

Confusing as Hell? Oh yeah. But it gets easier.

What do you need for the most simple games? Lets lay it out. Were going to need:

1) Title Screen
2) Game Play
3) Pause Screen

Some games will have more then others, but your going to at least need 3.

You can create an enum to hold what state your currently on like:

public enum GameState
{
StateMainMenu,
StatePlaying,
StatePause,
etc,
}

After that, you can create a nice construct to hold your current state, and what your previous states are. Why is this important? Well you want to prevent the game from starting when the menu screen loads; Sure you could create an if-statement to wait until a certain button/option was pressed before it starts the game, but then your code is going to start getting very sloppy and hard to follow. Not only that you now have the option to load objects and resources dynamically. Without a state manager your going to have to load all your resources from the get-go.

A great place to check out how to manage states is
XNA Creators Club: State Management Tutorial

Hope that helps you get started, good luck!

I'm sure you have all heard of the term "Game Engine". Simply put its just that. We can simplfy a game engine into nothing more then rods, belts and a block just like any old car. That being said, if something goes wrong with that engine it can impact the perfomance of the car which could bring it to a screeching halt. If your looking to build your own engine, you would like to start off with a solid block with more belts then there is rods in the engine. What the hell does that mean? Well if a car were to pop a rod, the engine suffers dramatically and you may have to rebuild your engine. If an engine breaks a belt, well swapping parts is going to be easy.

Simply put, make the engine modular. Don't cram a bunch of crap somewhere if you can just as easily split it up. Now you know your code best, and really if your developing a game engine thats what it should be... your very best. All programmers will use little lines here and there to hack our way to the end goal to 'test' theorys here and there... we've all done it. The trick is, not forgetting to go back and making sure that all your code has error checking and calls that you may be missing. That leads me to documentation...

When you are coding an engine, make sure to document the internals. I know I'm personally bad with this. If this is a few months--or year long project, you may have to revise something later on. Comments make it easier. There is nothing worse then revising a file you have not touched in 3 months, and scratching your head over what the hell is contained within. We are human, it happens. Comments however make it less likely.

Now with my last and closing statement, _do not_ bite off more then you can chew. Just because you have played around with making shapes or putting a model on the screen does not instantly make you fit for developing your own game engine. Get familiar with calls from input to drawing sprites, study it all, then when you think you can create something cool try it out. Dont start off with a 3D engine (even though XNA makes it pretty easy); Make a simple 2D engine first with sounds and input. This will ready you for when you want to make the step into 3D.

Good Luck!