Invent Your Own Computer Games with Python

February 22, 2010 9:05 AM

Invent Your Own Computer Games with Python: PDF
posted by vostok (45 comments total)

This seems similar to how I imagine a lot of self-taught programmers learn. For a couple different languages, I set myself a simple project -- say, the Traveling Salesman problem -- and looked up what was needed to implement the idea.
posted by lostburner at 9:07 AM on February 22, 2010 [5 favorites]

Thank you! I've been meaning to (1) learn more Python and (2) experiment with choose-your-own-adventure storytelling.
posted by dontoine at 9:11 AM on February 22, 2010

import physicsengine
import firstpersonshooter

firstpersonshooter.go()
posted by Plutor at 9:17 AM on February 22, 2010 [12 favorites]

My 11 year old has been writing games in Python lately. I emailed him this link but I guess he wasn't interested in reading about it. Instead he's been pestering me to help him debug his pygame problems. I would have devoured this book at his age, but it's harder to take a "guess the number" example seriously when you can pause to play some physics-implementing Flash games online. Still, he's been doing pretty well. Well enough that his 2.5 year old younger brother begged to play a game that he (the 11 year old) had made for him...

The experience of helping him has been interesting in a way similar to the "I'm an imposter" thread is talking about. I remember being at his level of total ignorance. Seeing just how far you've come and how much you've even forgotten you once didn't know is pretty revealing. I really DO know a lot of stuff that the general public doesn't, but I've known it so long that I never think about it anymore.
posted by DU at 9:19 AM on February 22, 2010 [5 favorites]

This is a great find. I wish that I had the time to really get down with Python and beef up my programming chops, but it seems like any spare time I would have allocated to learning the glowbox better ends up getting sucked up by the frustrating devil that is Matlab.
posted by solipsophistocracy at 9:20 AM on February 22, 2010

import programmer

game = programmer.writeCoolGame(type="firstpersonshooter")

game.start()

posted by Salvor Hardin at 9:20 AM on February 22, 2010

Oooh, neat. Thanks for this, on behalf of myself and an 11 yr old I know who's interested in making games.
posted by brundlefly at 9:21 AM on February 22, 2010

I really DO know a lot of stuff that the general public doesn't, but I've known it so long that I never think about it anymore.

Whenever I have doubts about the amount of your knowledge and the extent to which it towers head and shoulders over that of the average person, you offer helpful comments like this to remind me. Thank you, sir.
posted by solipsophistocracy at 9:23 AM on February 22, 2010 [4 favorites]

Some more links:
http://www.pygame.org/wiki/tutorials
http://www.pygame.org/docs/tut/newbieguide.html
http://rene.f0o.com/mywiki/PythonGameProgramming
http://osdcpapers.cgpublisher.com/product/pub.84/prod.11/m.1?
http://eli.thegreenplace.net/category/programming/python/pygame-tutorial/
posted by vostok at 9:28 AM on February 22, 2010 [1 favorite]

No son of of my is going to use a popular dynamically typed languages! This is an ANSI C household!
posted by geoff. at 9:28 AM on February 22, 2010 [12 favorites]

No son of of my is going to use a popular dynamically typed languages! This is an ANSI C household!

Python's written in ANSI C, though, so you can always treat the runtime as a pure C library and the scripts as configuration files for that library.
posted by effbot at 9:31 AM on February 22, 2010 [5 favorites]

No son of of my is going to use a popular dynamically typed languages! This is an ANSI C household!

I've been learning Scheme and considered teaching him that. But he's already running Linux (and was very interested to learn he could download the source code) and I feel I have some duty to keep him at least someone socially integrated.
posted by DU at 9:34 AM on February 22, 2010 [2 favorites]

Compiled languages bug me. I have no patience for less-than-realtime debugging. Guess I'll stick with web development for now. Been doing a lot of CFML lately, but I still prefer PHP.
posted by The Winsome Parker Lewis at 9:45 AM on February 22, 2010

Compiled languages bug me. I have no patience for less-than-realtime debugging.

We all miss QBASIC, man.
posted by Pope Guilty at 9:51 AM on February 22, 2010 [2 favorites]

So how do you debug php? I mostly smash my forehead against the keyboard and hope whatever is broken falls into place.
posted by Dr Dracator at 9:52 AM on February 22, 2010 [2 favorites]

I don't think PHP debugging is particularly different from debugging in other languages, it's just faster. Make a change, switch to Firefox, hit reload. Repeat ad nauseum. Dump variables to the page like there's no tomorrow. PHP.net is probably the best online programming reference I've ever seen, too.
posted by The Winsome Parker Lewis at 9:57 AM on February 22, 2010 [2 favorites]

Compiled languages bug me. I have no patience for less-than-realtime debugging. Guess I'll stick with web development for now.

I hope this was in response to the ANSI comment and not the Python subject.
posted by DU at 10:08 AM on February 22, 2010 [1 favorite]

Yeah, it was. I have no experience with Python, personally.
posted by The Winsome Parker Lewis at 10:12 AM on February 22, 2010

I mostly smash my forehead against the keyboard and hope whatever is broken falls into place.

You wrote this application I've been hired to fix, didn't you? Admit it!
posted by ook at 10:32 AM on February 22, 2010 [3 favorites]

Make a change, switch to Firefox, hit reload. Repeat ad nauseum. Dump variables to the page like there's no tomorrow.

Thank you for reminding me why I hate scripting languages. If I can't pause program execution and introspect the run-time state, I have no use for you. And that goes doubly-so for software.
posted by Civil_Disobedient at 10:51 AM on February 22, 2010 [4 favorites]

Is this where we talk about the ever shifting business requirements? Oooh business person, you're so cagey with your "I always wanted that" new feature requests!
posted by cavalier at 10:59 AM on February 22, 2010

Very neat, I wrote a small roguelike in python a while back and I should polish it up and add graphics with pygame. /one of these days
posted by rainy at 11:14 AM on February 22, 2010

Hmmm. Not to start a flame war here, but I highly recommend Microsoft's as a starting environment for the young ones.

It's a simple language with good integrated help, a companion PDF and it allows you to publish your games online. (As silverlight). Here's Tetris.
It also comes with built in turtle graphics. Which are awesome.
posted by seanyboy at 11:37 AM on February 22, 2010

Bugger. I fubarred the links there. Sorry all.
posted by seanyboy at 11:38 AM on February 22, 2010

> Thank you for reminding me why I hate scripting languages.

Don't think all scripting languages repeat the many, horrible mistakes of PHP.

When I'm not busy saving the world at night I make a living as a Python (Zope) web developer. Just put a pdb.set_trace() in the right place, and voila, reloading the page dumps the server instance into a gdb-like debugger.

With PHP (which I had a fun time with as a teaching instructor in uni) you're basically stuck with adding print statements for debugging, and if you have a syntax error you're likely to have to figure out where it is yourself, as the interpreter will unhelpfully tell you that the problem is with the last character in the script.
posted by brokkr at 12:22 PM on February 22, 2010 [1 favorite]

can anyone recommend any other good resources for learning python? it's one of the things i have on my list of things to learn in the near future.
posted by sentinel chicken at 12:27 PM on February 22, 2010

Install IPython and have a go at Dive Into Python.

Even if you're not already a programmer I think Dive Into Python is a very good and accessible text with non-trivial examples.
posted by brokkr at 12:37 PM on February 22, 2010 [1 favorite]

My 11 year old has been writing games in Python lately.

Ok, NOW I'm motivated to start learning how to program.
posted by zardoz at 12:37 PM on February 22, 2010 [1 favorite]

(Caveat: Dive Into Python is a tad old, and therefore doesn't cover the newest, greatest, shiniest Python 3000. I don't use Py3k, so I can't say what good resources for that might exist.)
posted by brokkr at 12:39 PM on February 22, 2010

PHP has at least one proper debugger, Xdebug.
posted by meandthebean at 12:56 PM on February 22, 2010

oh this is fantastic thanks
posted by empath at 1:23 PM on February 22, 2010

Thank you for reminding me why I hate scripting languages. If I can't pause program execution and introspect the run-time state, I have no use for you.

By and large you're talking about implementations of languages and tools surrounding languages, not the languages themselves. And it turns out that PHP has both debuggers and a REPL or two. And it's hardly the best of the scripting languages out there.
posted by weston at 1:58 PM on February 22, 2010

(Caveat: Dive Into Python is a tad old, and therefore doesn't cover the newest, greatest, shiniest Python 3000...)

He also wrote Dive Into Python 3. (Why the old page doesn't link to the new one is a mystery).
posted by Gary at 2:06 PM on February 22, 2010 [1 favorite]

Compiled languages bug me. I have no patience for less-than-realtime debugging.

What compiled languages don't let you real-time debug them? It's certainly not a problem with Java in Eclipse.

The worst programming language I've ever used has got to be Actionscript 2. It's like JavaScript with this bizarre type system grafted on. JavaScript is actually a pretty interesting language. It's actually a functional language like python, and you can do things like pass closures around. But because of Actionscript 2's "type system" (which was really just labels on variables) you can't actually use any of that functionality.

Other then that, the type system doesn't actually do anything. But the worst part is that any variables that haven't been initialize just get default values. In fact the variables don't even need to be declared. So if there's a typo and you misspell a variable name, it gets a default value and your program silently fails. In most languages, you'd get a compiler error.

--

Anyway, I definitely think static typing is the way to go. I don't know why people find it so onerous. It may be more typing (in both senses of the word) up front but it will help you avoid more errors later on.
posted by delmoi at 2:28 PM on February 22, 2010

It may be more typing (in both senses of the word) up front but it will help you avoid more errors later on.

Meh. A lot of investment for a questionable value, unless you're squeezing the system for speed. The kinds of errors it catches aren't my biggest problem, and unit/regression tests can help pick those up as well as the ones that matter.

Then again, one could argue that unit tests are essentially a form of typing via defined behavior.
posted by weston at 3:45 PM on February 22, 2010

I've been looking into Python a lot lately for personal projects, and have written an article on writing a roguelike in Python, so I figured I'd dump some of my ideas & opinions here. I've yet to read the ebook presented here but rest assured I'll be checking it out very soon! All this is presented with the caveat that I am a self-taught, unemployed Python programmer who absorbed all his knowledge by random web browsing. (He does do a lot of random web browsing, though.)

Amazing things can be done with Python and the right library. ROM CHECK FAIL, a fast action game written a couple of years ago by Farbs (creator of Captain Forever), turns out actually to be implemented in Python with the PyCap library/interface to PopCap's graphics framework. Farbs also made PyCap, and it is surprisingly fast for a 2D Python library. The biggest drawback is that it's a bit hackish. It seems to work by interfacing with a special PopCap-written exe, passing commands to it while it does all the work. Still, it seems to work well. Another drawback is that, since it relies on a premade executable component, it's firmly Windows-only, which is coming to matter more and more.

PyGame is easy to use and the most flexible of the major Python graphics packages, but it seemed a bit slow the last time I used it. It is built off of SDL, which is in turn built on OpenGL. Despite having OpenGL at its roots, I remember it being mostly 2D only. It is not a bad choice if performance isn't an issue. This is the only module I mention that supports Python 3.x.

cocos2d is a surprisingly quick native Python module. It is built off of pyglet and is playform agnostic; I have seen its examples run with surprising speed even on a PowerPC-era Mac Mini. It has strong ties to iPhone development; while the iPhone version uses Objective C instead of Python, I have been given to understand that the steps are similar. (That could be entirely wrong however; I have not built an Objective C program and have no experience with the iPhone.) The biggest problem I've found with cocos2d is that it has a system for graphics effects that doesn't work on all graphics cards. It requires framebuffer access, which some cards may not provide, or only provide with suitably modern drivers. You don't have to use effects to write a game, but it means doing without a fair amount of graphics panache, and even if it works on your machine it might not on anothers'. The litmus test of whether your own machine will work is the Tetrico example in the samples folder of the cocos2d distribution.

All Intel Python games can benefit from Psyco, a near-magical module that translates Python bytecode into machine code at run time with only a couple of calls. No joke, it is not uncommon to achieve performance gains in excess of 300% with it. Psyco doesn't support the entirety of Python's features, but that is unlikely to matter for game work. Psyco's creator has moved on to another project called PyPy with similiar aims. (It is fun to ponder PyPy's basis, which is nothing less than a reimplementation of Python in Python. I am not quite sure how this would improve performance, but it is an entertaining idea all the same.)

If you're trying to write a real-time game you might want to look into module NumPy, which adds a high-performance array type to the language. Without it, one will probably quickly run into Python's lack of a true multi-dimensional array, but writing a custom array class is easy.

It must be said that, if you want to write a multithreaded game, you will probably run into the global interpreter lock, a long-standing Python limitation. Mainline Python design is very single-threaded; its internal thread system works by simulating threads through the lock, so won't make explicit use of multiple cores and thus won't be too helpful for improving performance; it seems to be offered mostly as a means of providing for asynchronous execution, useful for, say, making a processing-intensive activity interruptable by the user. I'm not too well-read on the topic, but it seems the main way of overcoming this is the Processing module, but I don't know anything about that. It seems to be for Pythons 2.4 and 2.5 only at the moment.
posted by JHarris at 3:46 PM on February 22, 2010 [4 favorites]

> He also wrote Dive Into Python 3.

Ooh, nice. We're stuck at 2.4 at work though, so that goes to the bottom of the to-read pile.

> Anyway, I definitely think static typing is the way to go. I don't know why people find it so onerous.

Conversely, I don't know why people find dynamic typing so hard. I'm hardly ever bitten by duck typing, which Just Works™. The most egregious annoyance I have is when I think I'm iterating over a list, but I'm actually iterating over a string (which might be the error message of a raised exception ... gah). Once you've written any amount of python, just thinking about the sheer verbosity of statically typed languages tends to give you pre-emptive RSI.
posted by brokkr at 3:51 PM on February 22, 2010 [1 favorite]

My 11 year old has been writing games in Python lately.

Ok, NOW I'm motivated to start learning how to program.

Python is amazing, awesome and wonderful. It is charming and witty too. You should date.

It comes with an interactive shell, so you can instantly test out any Python construct without having to write a shell program around it in a text editor. It is terrifically flexible. I didn't really get object oriented programming until I learned it in Python. With the possible exception of Ruby, it is probably the most accessible of modern programming languages.

Python is the QuickBASIC -- hell, the Commodore BASIC of the 21st century.
posted by JHarris at 4:00 PM on February 22, 2010 [1 favorite]

# “sheer verbosity of statically typed languages”

You should be using an inferred type system.
posted by ijoshua at 4:46 PM on February 22, 2010

The point of static typing is to increase the expressivity of a language. Say you have a function that accepts a string argument. The string has to be sanitized before you use it because its going to be used to do something potentially dangerous. So how do you make sure? You could always call the sanitize function on the string before using it, just to be safe, but if you're calling this function a thousand times, you'll be wasting time running the sanitization function that many times. Maybe you could just add a comment in the function's docstring saying "everybody that calls this function MUST sanitize the string first". But of course, you can't be sure that everybody's going to read the documentation and obey it.

Static typing just lets you specify this requirement you have in a way that the compiler/interpreter can enforce the rule and make sure everybody follows it. Doing so saves cycles since you don't have to make run-time checks like how we had to keep calling the sanitization function, and it also helps you weed out bugs very early on, especially those like forgetting to sanitize a string which might only manifest months later in the form of a hacker performing an SQL injection attack.

I think part of the reason why a lot of people dislike static typing is that they might come from a programming culture where the first thing you do it compile the program, and then run it, and then debug whatever goes wrong; compiling should always be easy, and the bulk of the work is runtime debugging. In statically typed languages like ML however, compiling is often the most time-consuming process because all the type errors are going to stop compilation. So that gets on people's nerves.. "I've spent 2 hours on this and I can't even get the program to compile!"

What they don't realise is that all that's happening is the debugging is being moved from the run-time phase to the compilation phase. I've had countless times where I took ages to get an ML program to compile, but once it compiled, it worked perfectly; I doubt it was totally bug-free, but it was very much doing exactly what it was supposed to, even though the algorithm I was implementing might be really complex and I barely understood it to begin with. And half the time what I was doing during the "debugging" phase was just making sure types matched. Its like magic.

And yeah, an inferred type system lets you avoid having to enter too many extra characters. I think ML is one of the tersest languages out there (altho Lisp and friends probably have it beat); its definitely far terser than Python.

All that being said, Python still rocks. I just get a bit annoyed that I can't specify types sometimes. Sorry for the massive derail.
posted by destrius at 9:58 PM on February 22, 2010

Hi, I'm Al, the author of Invent Your Own Computer Games with Python (aka Invent with Python).

I wrote this book because I saw a lack of materials that gave complete examples of game source code with line-by-line explanation (like the stuff I had when I was young that taught me BASIC programming). Giving examples really takes learning to program out of the purely abstract. So I wrote this book and put it out for free under Creative Commons. Thanks for linking it!

There is a print version that will come out soon (I'm doing edits right now.) The HTML version is usually more up to date than the PDF.

Invent with Python fits in between overly complicated C++ or Java programming tutorials, and the "game creation kit" software that doesn't go into "real" programming. Some people have criticized the text-based games that make up the early chapters, so I added a few chapters dedicated to Pygame.

If you have any comments about what you love or hate about the book, please email them to me at [e-mail]. And thanks again for mention on Metafilter, I was blown away by the interest. :)
posted by AlSweigart at 10:38 PM on February 22, 2010 [13 favorites]

Thanks for all the work, AlSweigart! I'm going through the book as we speak!
posted by brundlefly at 10:42 PM on February 22, 2010

> You should be using an inferred type system.

Standard ML - actually, Moscow ML - was the first programming language I learnt (discounting autodidactic forays into BASIC on my C64) and while I love and have written a cryptographic implementation of DES in MosML, it can't compete with python for ease of use for me. It did teach me that functions should always be first order objects, which is another reason I like Python better than Java or C#.

At my alma mater, the interactive web applications like the course base and student's self service systems were implemented in SMLServer. Now that is effed up code if I ever saw any.
posted by brokkr at 12:41 AM on February 23, 2010

No, I do love Python, and I would recommend it without reservation for many tasks, particularly for beginners. I just wanted to dispel the false notion that a static type system means writing lots of extra boilerplate code. In fact, with a language capable of pattern matching, like Standard ML, it usually means a lot less code for highly polymorphic programs.
posted by ijoshua at 8:40 AM on February 23, 2010

Thanks for this, I've been wanting to check out PyGame for a while now and a resource aimed at 10-12 year olds is probably just about what I need.

RE: Debugging PHP, if you get tired enough of dumping variables into your source code, you can use Zend Debugger or XDebug, either of which let you set breakpoints in your IDE and debug much more usefully while stepping through a web page request. PHP has its issues, but it's quite debuggable without having to do the <pre><?php print_r($foo); ?></pre> thing.
posted by usonian at 8:49 AM on February 23, 2010