 If you're going to follow this series, the expectation is that you have at least a basic understanding of how to program. Specifically, you should have a basic familiarity with Python and the concepts of object-oriented programming. As long as you're comfortable with basic uses of variables, functions, classes, if statements, while statements, etc., you should be fine. It will also help to have some understanding of how text and numbers are represented as bits. In particular, it would help to understand the accuracy issues with floating-point numbers. It's also good to have an understanding of the context in which a program runs, namely the operating system and the hardware. What's the difference between a process and a thread? What's a file? What's a system call? What's a relationship between memory and the CPU caches? Things of that nature. You'll also want some basic familiarity with using command line. Nothing advanced, just navigation between directories, starting programs, and possibly modifying the system path. As for math, we may cover a bit of linear algebra, which mainly concerns matrices, but the only expectation coming in is that you at some point in your life covered basic geometry and trigonometry. If you can't remember now, which is sine and which is cosine, don't worry. I'll probably remind you when it comes up. And finally, if you want to follow along with the code and play with it yourself, the code will all be made available on Bitbucket, which uses the mercurial versioning system. So you'll want to familiarize yourself with mercurial's basic usage. Now, if you're totally new to programming, you can work your way through the videos at Codeschool.org, but that's quite a lot of material. So if you just want to do the bare minimum, you should watch the videos called a first programming language, the JavaScript language, and the Python language in that order. The JavaScript video is necessary not because we're going to use JavaScript, but because the Python video won't make sense without it. And of course, if you need help with any material in this series or the Codeschool series, you can post questions in the Codeschool discussion group, the link to which is on the Codeschool front page. As you may know, C++ is generally considered the language of choice in most professional game development. Virtually every commercial PC and console game of the last decade and earlier has been written mostly or wholly in C++, and this language preference will probably continue into the indefinite future. However, well into the 1990s, many PC games and almost all console games were written in assembly. Assembly remember refers to any language in which the programmer specifies the precise CPU instructions one by one. The use of assembly was of course mainly for efficiency reasons. Games are among the most taxing programs around, so in order to maximize the current hardware, it makes sense to use the language with the least performance overhead. In theory, the precise control of assembly provides sufficiently smart programmers the ability to produce the most efficient code possible. By about the mid 90s though, consumer hardware, PCs especially, became fast enough that the tiny efficiency gains programmers can eke out when using assembly instead of languages like C and C++, those efficiencies began to matter less and less in the overall performance picture. Past a certain point of code size and complexity, small efficiencies stopped making much of a visible difference and so just aren't worth the programmer time and effort. Besides, when code is slow on today's hardware, the first culprit is the choice of algorithms, not the minute details of the exact instructions. So better to use a more convenient language like C and C++ that makes it easier for programmers to experiment and find the right algorithms. Today, we leave minute optimizations of the precise CPU instructions up to compilers. But now, why the choice of C++ rather than some other non-assembly language? Well, first, C++ still allows the programmer a high degree of control over precisely what goes on on memory. The programmer in C++ explicitly manages memory and can create data types that use minimal space. Also, the built-in numeric types into short, long, double, and so forth, the primitive types as they are called in some other languages, these types can generally be processed efficiently. For example, the int type is defined as an integer, which is the same size as the CPU's general purpose registers, the optimum size for basic computations like addition and subtraction. And lastly, because C++ is statically typed and gets compiled to machine code, the compiler can aggressively optimize the compiled code in a way that cannot be done for dynamic and interpreted code. And in fact, this aggressive optimization in C++ is often the slowest part of the compilation process. In Python, in contrast to C++, the programmer does not explicitly manage memory. Instead, the interpreter is responsible for garbage collecting any created objects. For the most part, the Python programmer creates objects without worrying about deallocating the memory which those objects occupy. On the downside, this lack of control means that Python programmers cannot specify the precise byte-by-byte memory usage of data types. Python's numeric types also favor convenience over efficiency. A Python integer, for example, can be of arbitrary size, meaning that, say, two Python integers cannot generally be added to each other in a single CPU instruction in the way that two ints in C++ can be added together with just a single CPU instruction. And lastly, in a dynamic and interpreted language, a lot of information about what will happen at runtime only gets discovered at runtime. It's only knowable at runtime. And it's this lack of foreknowledge that makes aggressive compiler optimizations not possible with Python code the way they are with C++ code. So the cost of Python's conveniences are overhead, both in space, meaning extra memory usage, and time, meaning extra CPU work. If you're trying to push current hardware to its limits, C++ is clearly the preferable choice. However, we're going to use Python because today's piece of hardware is sufficiently powerful that less taxing games should run perfectly well in Python, especially games with just 2D graphics. To give you an idea of what's possible, there's a game called Save the Day, programmed not in Python but JavaScript, which has all the same basic efficiency disadvantages compared to C++. This game actually runs in the web browser, but it uses OpenGL for its graphics rendering like we will be doing in Python. Here's another JavaScript game in the browser, this time in 3D. Though certainly not up to snuff with the latest and greatest here in 2012, this is just a proof-of-concept experiment. More work and better art assets seem like they might produce results comparable in graphical fidelity to a shooter of around the early to mid-2000s, which is pretty cool for something written in JavaScript and running in the browser. But if after this series you're interested in learning more about game programming and C++, I recommend starting with this book, Game Engine Architecture by Jason Gregory. Gregory covers many of the same fundamentals we'll cover here, but he also covers some topics applicable to C++, but not Python, such as manual memory management. Now, if you want to follow along with the code and try coding yourself, you'll need to install a few programs. First, of course, you'll need Python, and then two Python libraries, a framework for games called Piglet, and the Python Imaging Library, which allows us to work with image files in many formats. Though I cover Python 3 in my Python video, we're actually going to use the older Python 2 for better compatibility with the Piglet framework. The apparent differences between Python 2 and 3 are small enough that this shouldn't be a problem, and I'll point out any differences along the way. Specifically, we'll be using Python 2.7.3, Piglet 1.2 Alpha 1, and Python Imaging Library 1.1.7. If later versions are available when you're listening to this, you'll probably be fine with those later versions, but I can't make any guarantees. Just be sure to use a version of Python 2, not Python 3, as Piglet currently does not work with Python 3. I also recommend installing Apptana and Notepad++. Apptana is a repackaging of the Eclipse IDE that includes the PyDev plugin. PyDev is nice because it gives us some conveniences like an easy-to-use Python debugger. You could alternatively use Eclipse and install the PyDev plugin yourself, but downloading Apptana is easier. Both Apptana and Eclipse require Java, so you'll need Java installed either way. Notepad++ is my text editor of choice on Windows. When you don't want to use a full IDE like Apptana, Notepad++ is a good choice for writing your Python code. And even when you do use an IDE, Notepad++ is very convenient for viewing and editing text files. Let's talk a little bit about what the Piglet framework will do for us. First off, the term framework is used for libraries that act as incomplete programs into which we insert our own code. For example, most web development these days is done with web frameworks. We're in the skeleton, the framework of a web app is provided along with many web-related conveniences, and we write our web app by filling in these pieces specific for our app. That said, Piglet is a very minimal framework, so it's not obscuring too much of the underlying system from us, which is why I prefer it to another Python game framework called PyGame. Piglet spares us some bother without obscuring how game code really works. Moreover, Piglet handles many cross-platform differences, such that our code will run on Windows, Mac, and Linux. So the features of Piglet include, first off, creation of our game windows with an option for full-screen mode. Piglet also handles the messages, the so-called events which the operating system sends to our windows. These include mainly the input events sent when the user clicks the mouse on the window or hits a keyboard key while the window is focused. Piglet also can capture game controller events so our games can support joysticks and gamepads. We'll talk more about window events in later videos. To draw on our windows, we use the OpenGL library, which as we'll discuss in detail later, is a standard cross-platform interface to the graphics hardware. The OpenGL library is provided as a C code library, but Piglet wraps the C code such that we can invoke it in Python. This wrapper isn't 100% complete, but it's close and more than adequate for our purposes. Though using OpenGL from Python instead of CRC++ naturally introduces some overhead, it's very much the same OpenGL you would use in CRC++, so don't worry that we're covering a dumbed-down version of OpenGL. Piglet gives us proper OpenGL. However, if you want to make 2D games in Piglet without using OpenGL directly, Piglet provides a simple abstraction layer for drawing what are called sprites. Sprites are simply 2D images positioned and rotated on the screen. Many 2D games can be rendered simply by composing the screen out of a bunch of sprites, some rendered on top of others. In a side scroller, for example, the background might be one or more sprites and the characters are sprites drawn on top. Be clear, though, that Piglet's sprite abstraction itself uses OpenGL, so, in fact, you can easily mix these sprites with direct use of OpenGL. Piglet also provides for a simple playback of sounded video, and lastly, Piglet provides the basic framework required in any game, what's called the game loop. As we'll discuss in the next video, writing a game loop is easy. The hard part is handling the timing, and that's where Piglet helps us out. The Piglet code is organized into a number of Python modules. Piglet.app and Piglet.clock both concern the game loop and timing, just mentioned. Piglet.window creates our windows. Piglet.GL is the OpenGL wrapper, while Piglet.graphics and Piglet.sprite provide a simple layer of abstraction, as just discussed. Piglet.text provides convenient methods for drawing text, and Piglet.image provides for the loading and managing of image files. Piglet.media contains the sound of video facilities. Piglet.font is an older module for loading fonts and rendering text, though it's mostly superseded by the newer Piglet.text. Piglet.resource provides a more convenient way to load resource files, namely sound and image files. And finally, Piglet.input provides the ability to get game controller input. Note that a few of these modules share overlapping features. In some cases, this overlap is for the purpose of providing both a low and high level API, such as Piglet.GL for direct OpenGL and Piglet.sprite for convenient simplified API. In other cases, though, the overlap is a result of changes to Piglet over the course of its development, such as the case with Piglet.font, which is really deprecated at this point, I believe. In any case, where there's such overlap, I'll try to steer us towards the most up-to-date features. Now, when using this Piglet modules, you could import them by their full name, just like with any other module, but in the name of convenience, Piglet does some weird import trickery such that you only ever need import Piglet. All the other Piglet modules get assigned to attributes of the Piglet package module. For example, Piglet.app can be accessed as Piglet.app after having imported only Piglet, not Piglet.app itself. I could go into a long explanation of how exactly Piglet pulls this off, but it would require a long refresher on how exactly Python imports modules. Before ending here, let me give you a quick sample of some Piglet programs. Here's a program written with Piglet that displays balls bouncing around the window. By itself, the program is unimpressive, but for a program that displays text in a window, takes keyboard input, and animates moving objects, it's impressive that the whole thing is written in just 60 lines. Similarly, here's an Asteroids clone written with Piglet that, while merely competent as a simple game, the whole program, complete with proper menus, is written in less than 800 lines. We should have no trouble getting similar bang per line of code when we write our own clones of classic games such as a Tetris clone in less than 500 lines.