I completely do not understand how a video game can be coded.

I'm a beginner programmer and only have experience writing console applications that do math and what not. I do not understand how these logical processes can make images move on the screen (video games). Obviously if I jumped into a game development book or something like that I would understand but I am currently still getting a grasp of the fundamentals of programming in general. Could anyone give a simple explanation, coding wise, on the jump between making a computer do simple math to making a computer produce amazing graphical programs such as video games? Maybe there are some introductory videos someone can point me to?


5 Answers 5


Assuming you're an absolute beginner in programming, and in order to base my example on something you might know, while writing a console application which has a menu where you want the user to choose among the available option, what will you do first?

If you thought about creating your menu, you got a point, but what if after the user pressed a key which is not part of the available option,

  1. will your application exit, or
  2. shall it continue until the user presses the "Exit" key?

My bet would be #2, the application shall continue until the user expressly press the key to exit from the console application.

A game is somehow the like! When do you want the game to exit? When the user chooses to, right? Hence, the action or the game menu has to last until the user wishes to exit. Then, you will have to create a loop that tells the program to continue until this very key to exit has been pressed.

You've just been introduced to the Game Loop. A game is just another program that runs until it is expressly exited by the user.

While in the game loop, when you're playing the game, the moves are images drawn on the screen at specific coordinates. When the user/player presses a directional key such as [Left], then you make your image refresh its coordinates while decrementing its X coordinate so that you give the impression for a motion toward the left direction. You got to get these inputs in order to get what action the player wants his character/ship to do next. Then, the Game Loop continues to loop until you can get another desired action from the player, until the game is exited.

Well, I'm afraid this answer begins to be fairly long enough, so allow me to point you to two other questions that might be of interest to you, I hope.

  1. Where to start writing games, any tutorials or the like?
  2. Moving my sprite in XNA using classes.

This third link is not about how to begin to write games, but about how to make a sprite move on the screen. Since you also asked about how to make the graphics move on screen, I thought this could interest you.

I hope this helps! =)


While you're making console applications, you most likely use functions called print() or read() or write(). Instead of these, graphical games use other functions which can be as low level as set_pixel() to set the color of an individual pixel on the screen, to entire frameworks that allow you to draw three-dimensional models with lots of effects.

But the main idea is the same as for a simple math console application. You get input from the user, act according to it to modify some variables, and then print (or draw) some output. Games and other interactive programs perform 30, 60 or more of these input-calculation-output cycles happen every second. Of course, every part can be as complex as you want, but it all usually comes down to input-calculation-output. So don't worry, you're on the right path.

As for recommendations, I'd say you keep programming, as much as you can. If you're interested in focusing on game programming, and you only know console programming, try and make a small text based adventure or RPG. That way you'll practice a lot on how to manage your variables, use random numbers and organize your code.

After you get some experience with that, take on to the basics of a graphics library. If you're doing procedural programming, I'd recommend OpenGL, while if you're doing object oriented programming, I'd recommend XNA.

However, don't take too many things at once. It's very easy to get disappointed over learning a complicated tool, while you're learning how to manage a source tree, while you're learning how to iterate over an array, while you're learning how to get input and sound, all while you're designing your game.

There's a long way ahead, but remember that the fun is actually walking through it.

Keep up the good work!


A computer game is an endless loop of:

  • Update: Advance the game state one tiny time slice (like 1/80 second).
  • Paint the current game state.

There are variations of these. Some games have more updates between each paint, or it can vary them to make the game flow equally smooth on different machines. But that is technical details.

The update phase that occurs between 50 and 100 times each second (yes it's that often) does this:

  • Update the games physics. Say that an actor have a velocity. The update should move him one tiny bit in the right direction. Also, if you use a physics engine, it should check for collisions with other actos or obstacles.
  • Update the games rules. This is what makes it a game and not a physics experiment. Say that a bullet hit the player actor. The game rules tell the player to deduct X points of health and the bullet to disapear.
  • AI updates. Sometimes the computer controlled actors should deside what to do. Go left or right? Find a path to a nice place to be. Fire a weapon.
  • Input control. Update the player actor according the buttons pressed on the keyboard.
  • Update scene graph. This can be advancing an animation one step, or updating the GUI to show that the player now has 10 points less health. It's only purpose is to make the game look and feel nice.

Where do you start?

The basic requirement for a graphical game is to program graphics. Make sure you can open a window, and draw a ball in it.

I assume you can make some kind of classes. Make a Ball class. It have the following members: x, y, deltaX, deltaY. All are integers and in pixel scales. Now, write this loop.

forever, do this {
  start measure time (in milliseconds)
  //physics part
  add deltaX to x
  add deltaY to y
  if x is bigger than the screen width, assign -deltaX to deltaX
  if y is bigger than the screen height, assign -deltaY to deltaY
  if x is less than 0, assign -deltaX to deltaX
  if y is less than 0, assign -deltaY to deltaY

  paint the ball at x, y
  stop measuring time, assign this to workTime
  make the thread sleep for (25 - workTime) milliseconds

This will make the ball bounce of the windows boundaries. It is not a game yet, rather a physical simulation. If you write the balls physics update inside the ball class, it is easy to add several balls. Store them in a list and update and paint each one for each frame.

You can add a paddle (simulate physics for it and make it controllable with the mouse or keyboard) and a game objective such as stopping the ball from reaching the left wall. If the game adds more and more balls over time, the difficulty will increase. You have a game.

Why sleep for (25 - workTime) milliseconds? If you do it like this, the simulation will run at a contant pace of 40 updates and paints per second. It will be quite smooth. If you would skip the sleep part, the animation would be jerky, and take up 100% CPU. Also, the speed of the ball would depend on the speed of the machine running it. Now, the ball vertical speed is 40 * deltaY pixels per second.


Take your console program that does math, and then when you put in a correct answer make it shoot off some confetti... It has become a game (Anyone besides me play Math Blaster as a kid? :)).

As for how computers are made to create game environments, it can be a bit much to wrap your head around at times but it comes down to an application of human's understanding of the world around them. Games use the same math, physics and sciences to define themselves as we apply to the world around us to explain how it works.

The Sim games are a good example of real to virtual. Long while ago I read an interview with the guy behind the Sim games and almost all of them, with out exception, were born from reading about a topic trying to explain the world around us, then harnessed with mathmatical formulas and put into a virtual environment to represent it. SimCity for example, was stemmed from trying to simulate the basics of economies.

As for the specifics of how you make a 3D game environment, put physics in it, add in some audio, let a user start to interact with it.. Well that is what this site and many others are here for and would be impossible to sum up into a more specific answer.

At the end of the day I describe video games as very fast limited data-set databases. They are highly focused on relational data and high speed data access.. I mean if you are rendering a frame every 60th of a second, you are processing potentially large amounts of data very fast based on the relationship of where the player is in the game to all the other data tracked by the game :)

  • \$\begingroup\$ Lol, "video games as very fast limited data-set databases" is probably just adding to the confusion. \$\endgroup\$ Commented Feb 25, 2011 at 4:53

What you need to understand is matrices. They underpin games. Once you understand the power of matrices, you will see how games reduce to simple mathematics.

You take a vertex position in game space. You project it using a matrix on to the screen (find it's screen co-ordinates). You interpolate some pixels between it and it's neighbour vertices, and you're done. That is obviously an exceedingly large simplification, but the fundamentals of rasterization are not at all complex once you grok matrices.


Not the answer you're looking for? Browse other questions tagged .