How is a video game different than any other application?
Building a video game will help you understand how to build any type of application. It’s a fun way to learn how to program. But how are video games different? And will understanding these differences help you to build better games? Yes, listen to the full episode or read the full transcript below to learn about event-driven programs and how this is different from a game loop.
Transcript
I’ve mentioned in this series that building a video game will help you understand how to build any type of application. It’s a fun way to learn how to program. But how are video games different? And will understanding these differences help you to build better games?
Yes, and I’ll explain some of the differences here. I can’t explain all the differences because there’s lots of ways to program. If you’re writing software to control a toy robot micro controller, that’s very different than writing software that controls food or drug manufacturing. And these are different than writing software to keep track of your sleep patterns. Writing software that runs deep inside your computer operating system is also different than writing a word processor.
I’ll focus on a simple user mode application compared to a simple game both running on a modern computer operating system. The application will have a graphical user interface, or GUI for short, which means there’s windows, buttons, edit boxes, etc. and you use the mouse to point and click. I’ll sometimes call this type of application a gooey instead of GUI. The game is also graphical but uses fewer things like buttons and focuses more on a single window with custom graphics.
When I say user mode application, I mean an application with no special privileges that you start normally. This includes just about any program you install and run on your computer. It does not include things like device drivers that the operating system gives extra permissions to be able to interact with your computer’s hardware.
Most GUI applications spend their time waiting for events. There’s an event loop that runs over and over and each time, the application asks the operating system if there are any events that need to be processed.
Every time you move the mouse, the operating system is sending your application mouse moved events. Whenever you press a keyboard key, the operating system sends your application key pressed events. If you resize your application window, you get window resize events. The operating system sends lots of events that your application needs to handle or sometimes ignore.
The point is that a GUI application waits for the operating system to let it know what’s happening and responds appropriately. Have you ever had an application either get too busy or confused so that it stops responding? The window will go blank white or show leftover images from other windows. The title bar might say “not responding”. And you have to force the application closed usually losing any unsaved work. This is what happens when an application stops handling the events that the operating system is sending to it.
Sometimes, a poorly designed application will stop processing events for a while to do something else. Maybe it needs to request information from another computer and makes a blocking call to get that information. A blocking call is where the thread making the call stops to wait for the call to complete. This will result in an application that looks like it’s stopped responding to events. All it needs, other than a better design, is just a little more time to complete.
The main thing to understand is that when writing an event-driven application, you need to respond to events quickly. There’s no specific timeline. Just don’t do anything that you think might take a long time to complete inside the event loop. Each time your application handles an event, it should return the result back to the operating system and go back to waiting for the next event. There’s also no specific time that your application will have to wait. This is up to the operating system. If the operating system has no events for your application, then it just waits.
The waiting is done efficiently so the CPU can rest if there’s no work to be done. This is good for your computer and saves battery power for mobile devices. If you want to see what I mean, just write an application that does some small task nonstop in a loop. You’ll hear the fan turn on after a few seconds as your computer tries to keep the CPU cool.
A game will also have an event loop. Any application that displays a window needs one. This is how GUI applications interact with the operating system. And even a game with its own graphics needs a window to draw them.
But here’s where a game starts to differ. Games don’t just sit around waiting for events. They have their own game loop where timing is everything. If you play a lot of graphic intensive games, you probably know about frame rate, or frames per second. A high quality game looks best at 60 frames or more per second. What this means is that the game needs to completely redraw the screen 60 times or more every second. But it’s more than just drawing. The game needs to be updated and any input handled too. All of this goes into a frame.
Here’s something you might not have asked yourself though. Why does a motion picture film look good on your TV at just 30 frames per second. Or maybe only 24? Anything less than about 24 frames per second is noticeable to our eyes. We’ll see a definite flickering. Above 24 frames per second, and the flicker goes away. So why does a TV go above and beyond with 30 frames per second while a video game needs more?
This is because of blurring. A motion picture or any video footage is captured from real life images that are moving. Each image will be blurred slightly due to the movement just like when you take a photo with shaky hands. When all these blurred images are played back 30 times each second, our eyes skip over the blurry movement and we see smooth action.
When a video game draws the screen, each frame is drawn precisely with no blurring. Our eyes are sharp enough to detect the tiny, precise movements in the game. So a game needs to be even faster than the best high definition motion picture in order for us to see smooth action.
This doesn’t give a game much time to work with. If you use your calculator to divide 1 by 60, the answer is about 0.016. That’s 16 thousandths of a second or 16 milliseconds. The game needs to do everything it’s going to do in those 16 milliseconds because it has to do all that over again in the next 16 milliseconds. And it just continues like this as long as the game is being played. This is the game loop.
Hopefully, your game will complete it’s work before the 16 milliseconds is up so that you can let the computer rest a little. Otherwise, you have a power hungry game that drains player’s batteries until they uninstall your game and leave you a bad review.
I also mentioned that games don’t wait around for events. Instead of waiting for some operating system to let the game know that a key or button is pressed, the game will check itself to see if any input from the player needs to be handled. Usually, each iteration through the game loop involves checking the state of the keyboard, mouse, and keypad. If any button is pressed or if the keypad sticks are moved, then the game will find out about it and deal with the input.
Maybe the right arrow key is currently being pressed. The game will add a little extra velocity to the hero which will be handled next. Any other input is dealt with in the same way. Once all the input has been checked, the game needs to update the state of the game.
This is where the hero’s new position will be calculated. Movement is nothing more than speed times how much time has passed. Remember when I said that timing is everything to a game? The game will record the exact time each game loop begins and ends. This time can change slightly from one pass through the loop to another. That’s okay though. The game knows how much time has passed and how fast the hero is moving and can decide how many pixels the position has changed since the last time the screen was drawn.
Once the hero has been moved into the new position, the game needs to check to see if anything is colliding. I mean, the hero usually can’t just walk through walls, right? So if after moving the hero slightly to the right, the game detects that part of the hero is inside a wall or something, then the game will adjust the location so the hero is back outside of the wall.
Or maybe, you want your game to start something special when the hero runs into a wall. Maybe play a sound or cause the hero to fall down. It’s up to you. Just remember that you only have a fraction of a second to figure all this out before the drawing has to begin. And then you get to do it all over again.