The templates resemble something like Pong or Breakout. Several red balls bounce around and with the arrow keys you can move a yellow paddle left and right. However, the paddle doesn’t interact with the balls. It’s far from a complete game.
Games need to execute at a constant frame rate regardless of the speed of the computer that it’s running on. To achieve this, start out by creating an in-memory representation of the game. This game model consists of states of all the enemies, the player, the virtual world containing them and so on, including the mode of the game itself (intro, demo, playing, ending, etc.). In essence, the model is nothing more than a set of flags that toggle as the game progresses between its parts and collections of simple objects containing things like the position of a particular enemy within the world. The model is updated by iterating over those collections and advancing the fields within each object. The fields are advanced with the assumption that the game is running at a constant frame rate. An update to the model should result in every entity within the game world repositioned for the next frame. The code used to update the model must be separated from the code that renders a visual representation of the model on the screen. It’s assumed that updating the model takes significantly less than drawing it. This means that if the game loop detects that it’s lagging behind where it aught to be, it can catch up by executing the update model code more often than the rendering code. The game loop in the Java template looks like this:
private void executeGameLoop() {
|
Prior to entering the loop, the current time (in nanoseconds) is captured into the variable nextFrameStart
. This variable represents the time that the next frame should be generated. The first part of the game loop is an inner loop that calls updateModel()
one or more times. After invoking updateModel()
, it advances nextFrameStart
by the frame period (the number of nanoseconds in each constant rate frame). The inner loop compares the nextFrameStart
time against the current time. If it’s behind, updateModel()
is called again until it catches up. Then, renderFrame()
is invoked once. Finally, if there is any time left over in the current frame, it sleeps it away.
The C# template uses a similar game loop:
private void OnApplicationIdle(object sender, EventArgs e) {
|
In this case, the game loop only executes when it detects that the application is idle. The concept is based on these articles:
http://www.codeproject.com/cs/media/ManagedRenderLoop.asp
http://blogs.msdn.com/tmiller/archive/2005/05/05/415008.aspx
The C# template also includes an extra little hack. F11 will apparently toggle the game in and out of full-screen mode. In reality, it’s just hiding the border of the frame and reducing the screen resolution. Unfortunately, when you change the screen resolution, Windows likes to change the positions of the icons on your desktop. The code to modify the screen resolution is based on this article:
http://www.codeproject.com/csharp/CSDynamicScrRes.asp
2007.12.08