216: How To Start Building a Video Game. Part 6.

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 ev