The Big Picture

This course is about programming games.
But what is the physical system are we programming?
What are its capabilities?
How does our code interact with these capabilities?

Capabilities: An Average Gaming Computer

diagram of gaming pc i/o

In short, and in abstract, we are writing code for an average gaming PC. It reads takes input from a number of devices (notably, a single mouse and keyboard, though you may want to go further in your final games). It writes output to a number of devices (notably, video output to a monitor and audio output to a set of speakers, though you may want to go further). And it may synchronize with other computers to enable non-local multi-player gaming.

Zooming in: Hardware

expanded diagram of gaming pc

If we zoom in on this generic gaming PC, we can understand in more detail at how our code is going to interact with these systems. At the hardware level, we're dealing with a soup of acronyms. (Can you expand them? Why did I add SSD?)

Zooming in: Operating System

expanded diagram of gaming pc

Of course, we're not going to be wrangling any of this hardware directly; we'll be relying on an Operating System (Linux, Windows, or MacOS) to wrangle them for us.

Zooming in: C++ and SDL

expanded diagram of gaming pc

Indeed, we're also going to be avoiding dealing any OS/Windowing System specific things, thanks (mostly) to the Simple Directmedia Layer (SDL) library. This is an low-level and industrial-strength library that handles common game use cases -- input handling, audio output, and OpenGL context creation.

Yep. We'll be developing three-platform games in this class. In C++. Which is surprisingly easy thanks to a careful choice of APIs and libraries.

Zooming in: More on Libraries

expanded diagram of gaming pc

Here is how our games will talk with the player's PC:

Input: our code will use the SDL event handling functions to read player input.

GPU: Our code will talk to the graphics card using the OpenGL API (v3.3). It can do this thanks to SDL's ability to create an OpenGL context.

Audio: Our code will use the SDL audio functions to render audio buffers and transfer them to the computer's DAC. (This is an asynchronous, callback-based API, which can be interesting to deal with.)

Networking: We'll be using simple and venerable BSD-style socket interface for networking.

Disc I/O: And, of course, we'll be using the C++ standard library for a host of things that it already does -- for example: file access, generic data structures, threading, timing, and pseudo-random number generation.

Zooming in: Libraries Summary

expanded diagram of gaming pc

Not pictured, but also relevant, code:

We will also be using a smattering of other code to smooth some of the rough edges of SDL, work around some platform-specific quirks, and give you a place to start. Collectively, we'll call this code 'nest' because it is a nice home built from a loosely coupled collection of parts which you can readily re-arrange and add to/remove from.

We'll rely on libraries for various compressed asset formats -- libpng and libjpeg-turbo (maybe) for images; libopus for sound.

That's everything that we ship to the player's PC. But that's not the whole story. (More on that next lecture, when we talk about Asset Pipelines!)

The Big Picture

So that's the details of everything we'll be running on the player's PC. But that's not the whole story. (More on that next lecture!)