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
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.