Feel free to email me any questions you have as always, but these forums are also now available to use:

/r/inventwithpython

Click the animated gif to view a larger version.

This is a tutorial on threads and multithreaded programs in Python, aimed at beginning programmers. It helps if you know the basics of classes (what they are, how you define methods, and that methods always have self as the first parameter, what subclasses (i.e. child classes) are and how a method can be inherited from a parent class, etc.) Here’s a more in-depth classes tutorial.

The example used is a “Nibbles” or “Snake” style clone that has multiple worms running around a grid-like field, with each worm running in a separate thread.

What are threads and why are they useful?

You can skip this section if you already know what threads are and just want to see how to use them in Python.

When you run a normal Python program, the program execution starts at the first line and goes down line by line. Loops and function calls may cause the program execution to jump around, but it is fairly easy to see from the code which line will get executed next at any given point. You can put your finger on the first line of code in the .py file on the screen, and then trace through the next lines of code that are executed. This is single-threaded programming.

However, using multiple threads is like putting a second finger down on your code. Each finger still moves the same way, but now they are executing code simultaneously.

Actually, they aren’t executing simultaneously. Your two fingers are taking turns at which one executes code. Computers with multicore CPUs can actually run multiple instructions simultaneously, but there is a feature of Python programs called the GIL (Global Interpreter Lock) that limits a Python program to one core only.

The Python interpreter will run one thread for a while, and then pause it to run another thread for a while. But it does this so fast that it seems like they are running simultaneously.

You can start dozens or hundreds of threads in your program (that’s a lot of fingers). This doesn’t automatically make your programs dozens or hundreds of times faster though (all the threads are still sharing the same CPU) but it can make your program more efficient.

For example, say you write a function that will download a file full of names, then sorts the names, and then writes these names to a file on your computer. If there are hundreds of files your program needs to process, you would put a call to this function in a loop and it would handle each file serially: download, sort, write, download, sort, write, download, sort, write…

Each of these three steps use different resources on your computer: downloading uses the network connection, sorting uses the CPU, writing the file uses the hard drive. Also, there are tiny pauses within each of these steps. For example, the server you are downloading the file from may be slow and your computer’s Internet connection has bandwidth to spare.

It would be better if you could call this function hundreds of times in parallel by using one thread for each file. Not only would this make better use of your bandwidth, but if some files download sooner than others, the CPU can be used to sort them while the network connection continues to work. This makes more efficient use of your computer.

What makes multithreaded programming tricky?

Of course, in the above case, each thread is doing its own separate thing and doesn’t need to communicate or synchronize anything with the other threads. You could just write the simple single-threaded version of the download-sort-write program and run the program hundreds of times separately. (Though it might be a pain to type & click each time to run the program each with a different file to download.)

Many multithreaded programs share access to the same variables, but this is where things can get tricky.

Photo from Brad Montgomery)

Here’s a common metaphor that is used: Say you have two robot ticket sellers. Their tasks are simple:

1. Ask the customer which seat they want.
2. Check a list to see if the seat is available.
3. Get the ticket for that seat.
4. Cross that seat off the list.

A customer asks Robot A for seat 42. Robot A checks that the seat is available from the list and finds that it is, so it grabs the ticket. But before Robot A can cross the seat off the list, Robot B is asked by a different customer for seat 42. Robot B checks the list and sees that the seat is still available, so it tries to grab the ticket for the seat. But Robot B can’t find the ticket for seat 42. THIS DOES NOT COMPUTE, and Robot B’s electronic brain explodes. Robot A then crosses seat 42 off of the list.

The above problem happens because although the two robots (or rather, two threads) are executing independently, they are both reading and modifying a shared list (or rather, a variable). Your programs can get very hard-to-fix bugs which are also difficult to even reproduce, since Python’s thread execution switching is nondeterministic, that is, done differently each time the program is run. We aren’t used to having the data in variables “magically” change from one line to the next just because a different thread was executed in between them.

When the execution switches from one thread to another, this is known as a context switch.

There is also the problem of deadlocks, which is commonly explained using the metaphor of the Dining Philosophers. Five philosophers are sitting around a circular table eating spaghetti but require two forks to do so. There is one fork between each philosopher (for a total of five forks). The method the philosophers use to eat is this:

1. Philosophize for a while.
2. Pick up the fork on your left.
3. Wait until the fork on your right is available.
4. Pick up the fork on your right.
5. Eat.
6. Put the forks down.
7. Go back to step 1.

Aside from the fact that they’ll be sharing forks with their neighbors (eww), it seems like this method will work. But sooner or later everyone at the table will end up with the fork on their left in their hand and waiting for the fork on their right. But because everyone is holding on to the fork their neighbor is waiting for and won’t put it down until they’ve eaten, the philosophers are in a deadlock state. They will be holding forks in their left hand but never getting a fork in their right hand, so they never eat and never put down the fork in their left hand. The philosophers all starve to death (except for Voltaire who is actually a robot. Without spaghetti, his electronic brain explodes.)

There is also a similar situation called a livelock. This is when no work gets done because the threads are too generous at making a resource available. The best metaphor of this is when two people are walking towards each other down a hall. They step to the side to let the other person walk past, but end up blocking each other. So they both step back to the other side, but end up blocking each other again. They continue doing this until they starve/electronic-brain-explode.

There are a few other problems that can come up with multithreaded programming such as starvation (no seriously, that’s what it is called) and generally fall under the label of “Concurrency” in computer science. But we will only treat a simplified case.

Locks

One way to prevent bugs with multithreaded programming is by using locks. Before a thread reads or modifies a shared variable, it attempts to “acquire” a lock. If it can acquire the lock, the thread goes on to read or modify the variable. If the thread cannot acquire the lock, it waits until the lock becomes available.

When the thread is done with the shared variable, it will “release” the lock so that some other thread waiting for the lock can acquire it.

Going back to our robot ticket seller metaphor, this is like having a robot pick up the list (the list is a “lock”), and then reading it the ticket is available, grabbing the ticket, and then crossing out the seat on the list. When the robot puts the list back down, it is “releasing the lock”. If another robot needs to pick up the list but it is not there, it will wait until the list is available.

You can cause bugs by writing code that forgets to release a lock. This will cause a deadlock situation since the other threads will hang and do nothing while waiting for a lock to bereleased.

Threads in Python

Okay, let’s write a Python program that demonstrates how to use threads and locks. This program is based off of my “Snake” clone in Chapter 6 of my Making Games with Python & Pygame book. Except instead of a worm running around eating apples, we’ll just have the worm running around the screen. And instead of just one worm, we will have multiple worms. Each worm will be controlled by a separate thread. The shared variable will have the data structure that represents which places on the screen (called “cells” in this program) are occupied by a worm. A worm cannot move forward to occupy a cell if another worm is already there. We will use locks to ensure that the worms don’t occupy the same cell as another worm.

The code for this tutorial can be downloaded here: threadworms.py or from GitHub. This code works with Python 3 or Python 2, and you need Pygame installed as well in order to run it.

Here’s a summary of the thread-related code in our threadworms.py program:

import threading

Python’s thread library is in a module named threading, so first import this module.

GRID_LOCK = threading.Lock()

The class Lock in the threading module has acquire() and release() methods. We will create a new Lock object and store it in a global variable named GRID_LOCK. (Since the state of the grid-like screen and which cells are occupied is stored in a global variable named GRID. The pun was unintended.)

# A global variable that the Worm threads check to see if they should exit.
WORMS_RUNNING = True

Our WORMS_RUNNING global variable is regularly checked by the worm threads to see if they should quit. Calling sys.exit() will not stop the program because it only quits the thread that made the call. As long as there are other threads still running the program will continue. The main thread in our program (which handles the Pygame drawing and event handling) will set WORMS_RUNNING to False before it calls pygame.quit() and sys.exit(). The next time a thread checks WORMS_RUNNING, it will quit, until eventually the last thread quits and then the program terminates.

class Worm(threading.Thread):
    def __ init__(self, name='Worm', maxsize=None, color=None, speed=None):
        threading.Thread.__init__(self)
        self.name = name

The thread’s code must start from a class that is a child of the Thread class (which is in the threading module). Our Thread subclass will be named Worm since it controls You don’t need an __init__() function, but since our Worm classes uses one we need to call the threading.Thread class’s __init__() method first. Also optional is to override the name member. Our __init__() function uses the string 'Worm' by default, but we can supply each thread with a unique name. Python will display the thread’s name in the error message if it crashes.

GRID_LOCK.acquire()
# ...some code that reads or modifies GRID...
GRID_LOCK.release()

Before we read or modify the value in the GRID variable, the thread’s code should attempt to acquire the lock. If the lock isn’t available, the method call to acquire() will not return and instead “block” until the lock becomes available. The thread is paused while this happens. This way, we know that the code after the acquire() call will only happen if the thread has acquired the lock.

Acquiring and releasing a lock around a bit of code ensures that another thread does not execute this code while the current thread is. This makes the code atomic because the code is always executed as a single unit.

After the thread’s code is done with the GRID variable, the lock can be released by calling the release() method.

def run(self):
	# thread code goes here.

A thread starts when the Worm class (which is a subclass of threading.Thread) has its start() method called. We don’t have to implement start() in the Worm class because it is inherited from the threading.Thread class. When the start() method is called, a new thread is created and the code inside the run() method is executed in this new thread. Do not call the run() method directly, as this won’t create the new thread.

This is important to know: to start the thread call the start() method, but the code that gets run in the new thread is in run(). We don’t have to define start() because it is inherited from threading.Thread. We do need to define run() since that is where our thread’s code will go.

When the run() method returns (or sys.exit() is called in the thread), the thread will be destroyed. All threads in a program must be destroyed before the program terminates. The program will still be running as long as there is one running thread.

So when start() is called, this is when you would place your second finger on the source code in run() to start tracing the code. Your first finger will continue tracing the code after the line that has the start() call.

A Simple Multithreaded Example

Before we go into the Threadworm code, let’s just look at a dead simple multithreaded program:

import threading
TOTAL = 0
class CountThread(threading.Thread):
    def run(self):
        global TOTAL
        for i in range(100):
            TOTAL = TOTAL + 1
        print('%s\n' % (TOTAL))
a = CountThread()
b = CountThread()
a.start()
b.start()

This program defines a new class called CountThread. When a CountThread object’s start() method is called, a new thread is created which will loop 100 times and increment the TOTAL global variable (which is shared between the variables) by 1 on each iteration of the loop.

Since we are creating two CountThread objects, whichever one finishes last should display 200. Each thread increases TOTAL by 100 and there are two threads. When we run this program, that’s what we see:

100
200

Because the first number is 100, we can tell that probably what happened is that one thread ran through the entire loop before a context switch happened.

However, if we change range(100) to range(100000), we would expect the second number to be 200000, since each thread increases TOTAL by 100000 and there are two threads. But when we run the program, something like this appears (your numbers may be slightly different):

143294
149129

That second number is not 200000! It’s quite less than that actually. The reason this happened is because we did not use locks around the code the reads and modifies the TOTAL variable, which is shared among multiple threads.

Look at this line:

TOTAL = TOTAL + 1

If TOTAL was set to 99, then you would expect TOTAL + 1 to evaluate to 99 + 1 and then to 100, and then 100 is stored as the new value in TOTAL. Then on the next iteration, TOTAL + 1 would be 100 + 1 or 101, which is stored as the new value in TOTAL.

But say when TOTAL + 1 gets evaluated as 99 + 1, the execution switches to the other thread, which is also about to execute the TOTAL = TOTAL + 1 line. The value in TOTAL is still 99, so TOTAL + 1 in this second thread gets evaluated to 99 + 1.

Then, another context switch happens back to the first thread where TOTAL = 99 + 1 is in the middle of being executed. The integer 100 is assigned to TOTAL. Now execution switches back to the second thread again.

In this second thread, TOTAL = 99 + 1 is about to be executed. Even though TOTAL is now 100, the TOTAL + 1 in this second thread has already been evaluated as 99 + 1. So the second thread also ends up assigning the integer 100 to TOTAL. Even though this TOTAL = TOTAL + 1 has been executed twice (once by each thread), the value in TOTAL has really only been incremented by 1!

The problem is, the line of code TOTAL = TOTAL + 1 is not atomic. The context switch can happen right in the middle of the line being executed. We need to use locks around this code to make this an atomic operation.

This new code fixes this problem:

import threading
TOTAL = 0
MY_LOCK = threading.Lock()
class CountThread(threading.Thread):
    def run(self):
        global TOTAL
        for i in range(100000):
            MY_LOCK.acquire()
            TOTAL = TOTAL + 1
            MY_LOCK.release()
        print('%s\n' % (TOTAL))
a = CountThread()
b = CountThread()
a.start()
b.start()

When we run this code, this is what is outputted (your first number might be a little different):

199083
200000

That the second number is 200000 tells us that the TOTAL = TOTAL + 1 line was correctly executed each of the 200,000 times it was run.

Explaining the Threadworms Program

I’m going to use the threadworms_nocomments.py version of the program since it doesn’t have the very verbose comments in it. The line numbers have been included at the front of each line (they are not a part of the actual Python source code). I skip a lot of the commented sections because they are self-explanatory. You don’t really need to know Pygame to follow this code. Pygame is only responsible for creating the window and drawing the lines and rectangles on it.

One thing to know is that Pygame uses a tuple of three integers to represent colors. The integers each span from 0 to 255 and represent the RGB (Red-Green-Blue) value of the color. So (0, 0, 0) is black and (255, 255, 255) is white and (255, 0, 0) is red and (255, 0, 255) is purple, etc.

  9. import random, pygame, sys, threading
 10. from pygame.locals import *
 11.
 12. # Setting up constants
 13. NUM_WORMS = 24  # the number of worms in the grid
 14. FPS = 30        # frames per second that the program runs
 15. CELL_SIZE = 20  # how many pixels wide and high each "cell" in the grid is
 16. CELLS_WIDE = 32 # how many cells wide the grid is
 17. CELLS_HIGH = 24 # how many cells high the grid is

The top part of the code imports some modules our program needs and defines some constant values. Feel free to edit these constant values. Increasing or decreasing the FPS value doesn’t change how fast the worms run around, it just changes how often the screen updates. If you set this value very low, it looks like the worms are teleporting since they move multiple spaces in between screen updates.

CELL_SIZE is how big each square on the screen’s grid is (in pixels). If you want to change the number of cells, modify the CELLS_WIDE and CELLS_HIGH constants.

 20. GRID = []
 21. for x in range(CELLS_WIDE):
 22.     GRID.append([None] * CELLS_HIGH)

The GRID global variable will contain data that tracks the state of the grid. It is a simple list of lists so that GRID[x][y] will refer to the cell at the X and Y coordinate. (In programming, the (0, 0) origin is at the top-left corner of the screen. X increases going to the right (just like in mathematics classes) but Y increases going down.)

If GRID[x][y] is set to None, then that cell is unoccupied. Otherwise, GRID[x][y] will be set to an RGB triplet. (This information is used when drawing the grid to the screen.)

 24. GRID_LOCK = threading.Lock() # pun was not intended

Line 24 creates a Lock object which our threads’ code will acquire and release before reading or modifying GRID.

 26. # Constants for some colors.
 27. #             R    G    B
 28. WHITE     = (255, 255, 255)
 29. BLACK     = (  0,   0,   0)
 30. DARKGRAY  = ( 40,  40,  40)
 31. BGCOLOR = BLACK             # color to use for the background of the grid
 32. GRID_LINES_COLOR = DARKGRAY # color to use for the lines of the grid
RGB tuples are kind of hard to read, so I usually set up some constants for them.
 33.
 34. # Calculate total pixels wide and high that the full window is
 35. WINDOWWIDTH = CELL_SIZE * CELLS_WIDE
 36. WINDOWHEIGHT = CELL_SIZE * CELLS_HIGH
 37.
 38. UP = 'up'
 39. DOWN = 'down'
 40. LEFT = 'left'
 41. RIGHT = 'right'

Some more simple constants. I use constants like DOWN and RIGHT instead of strings like 'down' and 'right' because if I make a typo using constants (i.e. DWON) then Python will immediately crash with a NameError exception. This is much better than if I make a typo like 'dwon' which won’t immediately crash the program will cause bugs later on, making it more difficult to track down.

 43. HEAD = 0
 44. BUTT = -1 # negative indexes count from the end, so -1 will always be the last index

Each worm will be represent by a list of dictionaries like {'x': 42, 'y': 7}. Each of these dictionaries represents a single body segment of the worm. The dictionary at the front of the list (at index 0) is the head and the dictionary at the end of the list (at index -1, using Python’s nice negative indexing which begins counting from the end) is the butt of the worm.

(In computer science, “head” often refers to the first item in a queue or list, and “tail” refers to every item after the head. So I use “butt” to refer to just the last item. Also, I am silly.)

The above worm would be represented with a list that looks like this: [{'x': 7, 'y': 2}, {'x': 7, 'y': 3}, {'x': 7, 'y': 4}, {'x': 8, 'y': 4}, {'x': 9, 'y': 4}, {'x': 10, 'y': 4}, {'x': 11, 'y': 4}, {'x': 11, 'y': 3}, {'x': 11, 'y': 2}]

 46. # A global variable that the Worm threads check to see if they should exit.
 47. WORMS_RUNNING = True

As long as one thread is running, the program will continue to execute. The main thread that does the screen drawing will also detect when the user has clicked the close button on the window or pressed the Esc key, so it needs a way to tell the worm threads to quit. We will code the worm threads to constantly check WORMS_RUNNING. If WORMS_RUNNING is set to False, then the thread will terminate itself.

 49. class Worm(threading.Thread): # "Thread" is a class in the "threading" module.
 50.     def __init__(self, name='Worm', maxsize=None, color=None, speed=None):

Here’s our Worm class. It is a child class of the threading.Thread class. Each worm can have a name (which appears if the thread crashes, helping us identify which thread crashed), and a size, color, and speed. Default values are provided, but we can specify these ourselves if we want.

 56.         threading.Thread.__init__(self) # since we are overriding the Thread class, we need to first call its __init__() method.

Since we are overriding the __init__() method, we need to call the parent classes __init__() method so that it can initialize all the thread stuff. (We don’t need to know how it works, just remember to call it.)

 57.
 58.         self.name = name
 59.
 60.         # Set the maxsize to the parameter, or to a random maxsize.
 61.         if maxsize is None:
 62.             self.maxsize = random.randint(4, 10)
 63.
 64.             # Have a small chance of a super long worm.
 65.             if random.randint(0,4) == 0:
 66.                 self.maxsize += random.randint(10, 20)
 67.         else:
 68.             self.maxsize = maxsize
 69.
 70.         # Set the color to the parameter, or to a random color.
 71.         if color is None:
 72.             self.color = (random.randint(60, 255), random.randint(60, 255), random.randint(60, 255))
 73.         else:
 74.             self.color = color
 75.
 76.         # Set the speed to the parameter, or to a random number.
 77.         if speed is None:
 78.             self.speed = random.randint(20, 500) # wait time before movements will be between 0.02 and 0.5 seconds
 79.         else:
 80.             self.speed = speed

The above code sets up a worm with random values for the size, color, and speed unless specific values were specified for the parameters.

 82.         GRID_LOCK.acquire() # block until this thread can acquire the lock
 83.
 84.         while True:
 85.             startx = random.randint(0, CELLS_WIDE - 1)
 86.             starty = random.randint(0, CELLS_HIGH - 1)
 87.             if GRID[startx][starty] is None:
 88.                 break # we've found an unoccupied cell in the grid
 89.
 90.         GRID[startx][starty] = self.color # modify the shared data structure
 91.
 92.         GRID_LOCK.release()

We need to determine a random starting location for the worm. To make this easier, all worms begin with a length of one body segment and grow until they reach their full maximum size. But we need to make sure that the random location on the grid we come up with isn’t already occupied. This involves reading and modifying the GRID global variable, so we need to acquire and release the GRID_LOCK lock before doing this.

(As a side note, you might be wondering why we don’t have a “global GRID” line at the beginning of this method. GRID is a global variable and we are modifying it in this method, and without a global statement Python should consider this a local variable that just happens to have the same name as the GRID global variable. But if you look closer, we only change values inside the GRID list of lists, but never the value in GRID itself. That is, we have code that looks like “GRID[startx][starty] = self.color” but never “GRID = someValue“. Because we don’t actually modify GRID itself, Python considers the use of the variable name GRID in this method to refer to the global variable GRID.)

We keep looping until we’ve found an unoccupied cell, and then mark that cell as now occupied. After this, we are done reading and modifying GRID so we release the GRID_LOCK lock.

(Another side note, if there are no free cells on the grid, this loop will continue to loop forever and the thread will “hang”. Since the other threads will continue to run, you might not notice this problem. The new worm will not be created but the rest of the program continues to run normally. However, when you try to quit, since the hanging thread never gets to check WORMS_RUNNING to know it should quit and the program will refuse to terminate. You will have to force the program to shut down through your operating system. Just be sure not to add more worms than you have space for.)

 96.         self.body = [{'x': startx, 'y': starty}]
 97.         self.direction = random.choice((UP, DOWN, LEFT, RIGHT))

The starting body segment is added to the body member variable. The body member variable will be a list of all the locations of segments of the body. The direction that the worm is heading in is stored in the direction member variable.

Technically, since this worm right now only has one body segment that is both the first and last item in the list, the worm’s head is the same as its butt.

100.     def run(self):
101.         while True:
102.             if not WORMS_RUNNING:
103.                 return # A thread terminates when run() returns.

The run() method is the method that is called when the worm’s start() method is called. The code in run() is executed in a brand new thread. We will have an infinite loop that causes the worm to continuously move around the grid. The first thing we do on each iteration of the loop is check if WORMS_RUNNING is set to False, and if so, we should return from this method.

The thread will terminate itself if we either call sys.exit() from the thread or when the run() method returns.

105.             # Randomly decide to change direction
106.             if random.randint(0, 100) < 20: # 20% to change direction
107.                 self.direction = random.choice((UP, DOWN, LEFT, RIGHT))

On each move, there’s a 20% chance that the worm randomly changes direction. (Although the new direction could be the same as the current direction. But I wanted to write this code out quickly.)

109.             GRID_LOCK.acquire() # don't return (that is, block) until this thread can acquire the lock
110.
111.             nextx, nexty = self.getNextPosition()
112.             if nextx in (-1, CELLS_WIDE) or nexty in (-1, CELLS_HIGH) or GRID[nextx][nexty] is not None:
113.                 # The space the worm is heading towards is taken, so find a new direction.
114.                 self.direction = self.getNewDirection()
115.
116.                 if self.direction is None:
117.                     # No places to move, so try reversing our worm.
118.                     self.body.reverse() # Now the head is the butt and the butt is the head. Magic!
119.                     self.direction = self.getNewDirection()
120.
121.                 if self.direction is not None:
122.                     # It is possible to move in some direction, so reask for the next postion.
123.                     nextx, nexty = self.getNextPosition()
124.
125.             if self.direction is not None:
126.                 # Space on the grid is free, so move there.
127.                 GRID[nextx][nexty] = self.color # update the GRID state
128.                 self.body.insert(0, {'x': nextx, 'y': nexty}) # update this worm's own state
129.
130.                 # Check if we've grown too long, and cut off tail if we have.
131.                 # This gives the illusion of the worm moving.
132.                 if len(self.body) > self.maxsize:
133.                     GRID[self.body[BUTT]['x']][self.body[BUTT]['y']] = None # update the GRID state
134.                     del self.body[BUTT] # update this worm's own state (heh heh, worm butt)
135.             else:
136.                 self.direction = random.choice((UP, DOWN, LEFT, RIGHT)) # can't move, so just do nothing for now but set a new random direction
137.
138.             GRID_LOCK.release()

The above code handles moving the worm one space. Since this involves reading and modifying GRID, we need to acquire the GRID_LOCK lock first. Essentially, the worm will try to move one space in the direction that it’s direction member variable says. If this cell is beyond the border of the grid or is already occupied, then the worm will change its direction. If the worm is blocked on all sides, then the worm reverses itself so that the butt becomes the head and the head becomes the butt. If the worm still can’t move in any direction, then it will just stay put for now.

140.             pygame.time.wait(self.speed)

After the worm has moved one space (or at least tried to), we will put the thread to sleep. Pygame has a function called wait() that does the same thing as time.sleep(), except that the argument to wait() is in integer of milliseconds instead of seconds.

Pygame’s pygame.time.wait() and the Python Standard Library’s time.time() functions (and Pygame’s tick() method) are smart enough to tell the operating system to put the thread to sleep for a while and just run other threads instead. Of course, while the OS could interrupt our thread at any time to hand execution off to a different thread, calling wait() or sleep() is a way we can explicitly say, “Go ahead and don’t run this thread for X milliseconds.”

This wouldn’t happen if we have “wait” code like this:

startOfWait = time.time()
while time.time() - 5 > startOfWait:
    pass # do nothing for 5 seconds

The above code also implements “waiting”, but to the OS it looks like your thread is still executing code (even though this code is doing nothing but looping until 5 seconds has passed). This is inefficient, because time spent executing the above pointless loop is time that could have been spent executing other thread’s code.

Of course, if ALL worms’ threads are sleeping, then the computer can know it can use the CPU to run other programs besides our Python Threadworms script.

143.     def getNextPosition(self):
144.         # Figure out the x and y of where the worm's head would be next, based
145.         # on the current position of its "head" and direction member.
146.
147.         if self.direction == UP:
148.             nextx = self.body[HEAD]['x']
149.             nexty = self.body[HEAD]['y'] - 1
150.         elif self.direction == DOWN:
151.             nextx = self.body[HEAD]['x']
152.             nexty = self.body[HEAD]['y'] + 1
153.         elif self.direction == LEFT:
154.             nextx = self.body[HEAD]['x'] - 1
155.             nexty = self.body[HEAD]['y']
156.         elif self.direction == RIGHT:
157.             nextx = self.body[HEAD]['x'] + 1
158.             nexty = self.body[HEAD]['y']
159.         else:
160.             assert False, 'Bad value for self.direction: %s' % self.direction
161.
162.         return nextx, nexty

The getNextPosition() figures out where the worm will go next given the position of its head and the direction it is going.

165.     def getNewDirection(self):
166.         x = self.body[HEAD]['x'] # syntactic sugar, makes the code below more readable
167.         y = self.body[HEAD]['y']
168.
169.         # Compile a list of possible directions the worm can move.
170.         newDirection = []
171.         if y - 1 not in (-1, CELLS_HIGH) and GRID[x][y - 1] is None:
172.             newDirection.append(UP)
173.         if y + 1 not in (-1, CELLS_HIGH) and GRID[x][y + 1] is None:
174.             newDirection.append(DOWN)
175.         if x - 1 not in (-1, CELLS_WIDE) and GRID[x - 1][y] is None:
176.             newDirection.append(LEFT)
177.         if x + 1 not in (-1, CELLS_WIDE) and GRID[x + 1][y] is None:
178.             newDirection.append(RIGHT)
179.
180.         if newDirection == []:
181.             return None # None is returned when there are no possible ways for the worm to move.
182.
183.         return random.choice(newDirection)

The getNewDirection() method returns a direction (one of the UP, DOWN, LEFT, or RIGHT strings) that is for an unoccupied cell within the grid. If there are no available cells the head could move towards, the method returns None.

185. def main():
186.     global FPSCLOCK, DISPLAYSURF
187.
188.     # Draw some walls on the grid
189.     squares = """
190. ...........................
191. ...........................
192. ...........................
193. .H..H..EEE..L....L.....OO..
194. .H..H..E....L....L....O..O.
195. .HHHH..EE...L....L....O..O.
196. .H..H..E....L....L....O..O.
197. .H..H..EEE..LLL..LLL...OO..
198. ...........................
199. .W.....W...OO...RRR..MM.MM.
200. .W.....W..O..O..R.R..M.M.M.
201. .W..W..W..O..O..RR...M.M.M.
202. .W..W..W..O..O..R.R..M...M.
203. ..WW.WW....OO...R.R..M...M.
204. ...........................
205. ...........................
206. """
207.     #setGridSquares(squares)

The setGridSquares() function can be used to draw static blocks on the grid by passing a multiline string. The period characters represent no change, a space character means “set this to be unoccupied” and any other character will represent a static block to place on the grid. You can uncomment line 207 if you want to see the “Hello worm” text written out in blocks.

209.     # Pygame window set up.
210.     pygame.init()
211.     FPSCLOCK = pygame.time.Clock()
212.     DISPLAYSURF = pygame.display.set_mode((WINDOWWIDTH, WINDOWHEIGHT))
213.     pygame.display.set_caption('Threadworms')

This is standard Pygame setup code to create a window for our program.

215.     # Create the worm objects.
216.     worms = [] # a list that contains all the worm objects
217.     for i in range(NUM_WORMS):
218.         worms.append(Worm())
219.         worms[-1].start() # Start the worm code in its own thread.

This code creates the Worm objects and then creates their threads by calling the start() method. The code in each worm’s run() method will begin executing in a separate thread at this point.

221.     while True: # main game loop
222.         handleEvents()
223.         drawGrid()
224.
225.         pygame.display.update()
226.         FPSCLOCK.tick(FPS)

The main game loop is pretty simple. The handleEvents() function will be checking if the user is terminating the program and the drawGrid() function will draw the grid lines and cells to the screen. The pygame.display.update() function tells the window to update the screen, after which the tick() method will pause for however long is needed to achieve the framerate specified in FPS.

229. def handleEvents():
230.     # The only event we need to handle in this program is when it terminates.
231.     global WORMS_RUNNING
232.
233.     for event in pygame.event.get(): # event handling loop
234.         if (event.type == QUIT) or (event.type == KEYDOWN and event.key == K_ESCAPE):
235.             WORMS_RUNNING = False # Setting this to False tells the Worm threads to exit.
236.             pygame.quit()
237.             sys.exit()

The Pygame events can tell us when the user has pressed the Esc key or clicked on the close button for the window. In this case we want to set WORMS_RUNNING to False so that the threads will terminate themselves and then the main thread shuts down Pygame and exits.

240. def drawGrid():
241.     # Draw the grid lines.
242.     DISPLAYSURF.fill(BGCOLOR)
243.     for x in range(0, WINDOWWIDTH, CELL_SIZE): # draw vertical lines
244.         pygame.draw.line(DISPLAYSURF, GRID_LINES_COLOR, (x, 0), (x, WINDOWHEIGHT))
245.     for y in range(0, WINDOWHEIGHT, CELL_SIZE): # draw horizontal lines
246.         pygame.draw.line(DISPLAYSURF, GRID_LINES_COLOR, (0, y), (WINDOWWIDTH, y))

This code draws the screen based on the values in GRID. But first it draws the grid lines.

248.     # The main thread that stays in the main loop (which calls drawGrid) also
249.     # needs to acquire the GRID_LOCK lock before modifying the GRID variable.
250.     GRID_LOCK.acquire()
251.
252.     for x in range(0, CELLS_WIDE):
253.         for y in range(0, CELLS_HIGH):
254.             if GRID[x][y] is None:
255.                 continue # No body segment at this cell to draw, so skip it
256.
257.             color = GRID[x][y] # modify the GRID data structure
258.
259.             # Draw the body segment on the screen
260.             darkerColor = (max(color[0] - 50, 0), max(color[1] - 50, 0), max(color[2] - 50, 0))
261.             pygame.draw.rect(DISPLAYSURF, darkerColor, (x * CELL_SIZE,     y * CELL_SIZE,     CELL_SIZE,     CELL_SIZE    ))
262.             pygame.draw.rect(DISPLAYSURF, color,       (x * CELL_SIZE + 4, y * CELL_SIZE + 4, CELL_SIZE - 8, CELL_SIZE - 8))
263.
264.     GRID_LOCK.release() # We're done messing with GRID, so release the lock.

Because this code reads the GRID variable, we will first acquire the GRID_LOCK lock. If a cell is occupied (that is, it is set to an RGB tuple value inside the GRID variable) the code draws in the cell.

267. def setGridSquares(squares, color=(192, 192, 192)):
268.     # squares is set to a value like:
269.     # """
270.     # ......
271.     # ...XX.
272.     # ...XX.
273.     # ......
274.     # """
275.
276.     squares = squares.split('\n')
277.     if squares[0] == '':
278.         del squares[0]
279.     if squares[-1] == '':
280.         del squares[-1]
281.
282.     GRID_LOCK.acquire()
283.     for y in range(min(len(squares), CELLS_HIGH)):
284.         for x in range(min(len(squares[y]), CELLS_WIDE)):
285.             if squares[y][x] == ' ':
286.                 GRID[x][y] = None
287.             elif squares[y][x] == '.':
288.                 pass
289.             else:
290.                 GRID[x][y] = color
291.     GRID_LOCK.release()

The setGridSquares() can write static blocks to the grid and was explained previously.

294. if __name__ == '__main__':
295.     main()

The above is a Python trick. Instead of putting the main code in the global scope, we put it into a function named main() which is called from the bottom. This guarantees that all the functions have been defined before the code in main() runs. The __name__ variable is only set to the string '__main__' if this program was run itself, as opposed to imported as a module by another program.

Summary

That’s it! Multithreaded programming is fairly simple to explain, but it can be tricky to understand how to get your own multithreaded programs to work correctly. The best way to learn is to practice by writing your own programs.

Actually, the way we have our code set up, even if we got rid of the locks it would still run almost perfectly. Nothing would crash, although there would sometimes be the case where two worms are approaching the same cell and end up both occupying it. They would then seemingly move through each other. Using locks ensures that only one worm can occupy a cell at any time.

Good luck!

• Download PDF of Hacking Secret Ciphers with Python
• View HTML version online.
• Buy a physical book on Amazon

100% of the proceeds from the book sales will be donated to the Electronic Frontier Foundation, Creative Commons, and The Tor Project.

Each chapter presents a new program and explains how the source code works. At the same time, various ciphers and cryptography concepts are explored. This book covers:

• The Caesar cipher (and how to hack it)
• The Transposition cipher (and how to hack it)
• Writing programs to automatically test our programs
• Encrypting files
• Programmatically detecting English
• The Simple substitution cipher (and how to hack it)
• Modular arithmetic
• The Multiplicative cipher (and how to hack it)
• The Affine cipher (and how to hack it)
• The Simple substitution cipher (and how to hack it)
• The Vigenere cipher (and how to hack it)
• Frequency analysis
• One-time pads
• Generating prime numbers that are hundreds of digits long
• Public key cryptography and the RSA cipher

I first started this book two years ago. The Word doc calculates my editing time for the file at 85,860 minutes (not including the time to write and debug the programs). The book is over 400 pages long with over 1700 lines of code written for the programs (not including whitespace and comments).

The book’s website is at http://inventwithpython.com/hacking

Feel free to email me questions or comments at al@inventwithpython.com or leave a comment below.

If you don’t think the low rates of women and minorities participating in the tech industry is fundamentally a problem that should be corrected, you can stop reading now and save yourself a few minutes. But software developers are in high demand. There’s a lot of great software out there waiting to be written. And while the current generation is much more technically literate than say, 30 years ago, raising the general level of technical expertise would blossom the possibilities for more sophisticated products and avenues of communication. We should get as many people across all demographics on board as possible.

I’m not going to talk solely about sexism itself in the tech industry (though at the front of my views on that are pointing out how widely the Internet blames Adria Richards for the dongle-joker’s firing rather than Play Haven, who did the actual firing.) But I also want to talk about inclusion and how to build community, and the attitudes that tear community down.

Again, there are a lot of people who don’t view it as a problem, or at least if it is a problem it’s one that doesn’t deserve addressing. Most of the time these are people who are already in the community, and see any active outreach as unnecessary or even unfair. “I didn’t need someone to hold my hand. If that’s what they need (or worse, demand) then they’re self-selecting themselves out of tech industry anyway.”

I simplify (perhaps oversimplify, but this just my casual commentary) the issue into the “Don’t throw punches” and “Learn to take a punch” camps but they encompass a lot of attitudes that I’ve seen before (especially in the last couple of days): “That wasn’t professional.” “Lighten up, it’s just a joke.” “Not cool.” “It was a private conversation anyway.”

I simplify the issue into two camps, and I completely, utterly place my chips in the former, not the later. Being able to take a punch may be sufficient to get along in a heterogeneous community, but discouraging people from throwing them is absolutely necessary for holding one together.

“I’ve taken worse and haven’t been bruised.”

The comment in poor taste, the slide with the technically-not-nude porn image, the staring, the unsolicited proposition, the following, the boys locker room humor, the unconsented photographing, the hired booth staffer in the skintight outfit meant to arouse “the crowd” (i.e. heterosexual men), the “not a real developer” comments, the flier with outright sexist garbage anonymously posted up on the public wall, the antagonism you get when you tear down the flier.

As common as these things are at tech and geek conferences (and they are common), they aren’t things people call the cops over. Often the police aren’t even brought in when it escalates to stalking or an arm-grab. But they are more than enough to make people give up on participating. Since it doesn’t involve law enforcement or courts, many people treat these things lightly. The common attitude (and it is common) is: If there’s a problem, it’s because the person bringing up the problem is creating it.

This trivializing of incidents as “you’re too sensitive” sends a clear message: “That’s your problem. You’re on your own.”

The later camp either hasn’t experienced this targeted at them or if they have, they’ve accepted it as a small part of the price of admission. This isn’t welcoming, it’s hazing. Hazing is neat little psychological trick: by undergoing some humiliation or pain, you can get someone to ascribe value to a community (after all, if it wasn’t valuable, why did they take those punches for it?) It further also makes them want (or at least allow) to continue hazing new members: if you had to do it, then why should they get a free pass?

I could criticize this as a race to the bottom, but there’s no bottom. Outside of something that brings in the police, there is no bound to how bad accepted behavior can get when “learn to take a punch” is your cover-all. And people can get very creative when it comes to socially-cruel ostracism when they feel entitled to it.

At the core, I see the “don’t be so sensitive” attitude as the well-intentioned cousin of trolling: It devolves into a staring contest to see who will break first. To admit offense is to lose. To win you will need either indifference or the strength to suffer in silence. That’s a sucker’s game and either way, you will live with the knowledge that tomorrow you will be dealing with the same bullshit that you had to deal with today, because if you speak up it will only get worse. Especially if you’re a woman or minority.

This isn’t the foundation you can attract and build a community on and it’s not something anyone who wants to grow a community can ignore. (I point to Anil Dash’s blog post “If Your Website’s Full of Assholes, It’s Your Fault” as a great take on this.) Learning to lighten up, to not be so easily offended, to not make a big deal out of it, or to take a punch is never the raison d’etre of any community. People don’t pay conference registration fees to test their emotional mettle for abuse. (If PyCon’s increased attendance and rates of women’s participation demonstrate anything, it’s that people pay money for the exact opposite.)

Having resilience to not let insensitive comments or outright abuse drive you away is a good thing to have. It’s admirable to be shatterproof. But it’s callous to demand it from others. I thank the PyCon board and volunteers for putting together a great conference and a great community. They’ve had the guts to stick to their guns about not just having a Code of Conduct (the mere existence of which hasn’t been without resistance) but also the spine to enforce it and provide guidance for attendees to do the same. They’ve had to take quite a few punches themselves for this (and not just in the last few days), but I’m grateful that they do and that they push to ensure others won’t have to.

(If you’re interested in more on this topic, I recommend John Scalzi’s blog posts “The Sort of Crap I Don’t Get” and “Straight White Male: The Lowest Difficulty Setting There Is” (and the rest of his blog in general) and the Geek Feminism Wiki.)

Dangerous High School Girls in Trouble is a 2D RPG by Keith Nemitz that was nominated for a Writers Guild Award, won “Most Innovative Game” by the Casual Games Association, and was also selected as a finalist for the 2008 IndieCade Festival of Independent Games. It is available for purchase off of Steam. Gameplay video

Analogue: A Hate Story is a visual novel-style game that was a 2012 IndieCade Finalist. As of December 2012, Analogue has sold at 40,000 copies. Steam store link (with videos).

Unity of Command is a turn-based, operational-level wargame that covers the entire 1942/43 Stalingrad Campaign on the Eastern Front. Trailer video. Available on Steam.

Frets on Fire is an open source Guitar Hero clone. Gameplay video

7 Grand Steps is a board-like puzzle game from Keith Nemitz of Mousechief and is a 2013 Independent Games Festival finalist. Trailer video

Metin2 is an Oriental-themed action MMORPG. Trailer video

Galcon 2 is a high-paced space shooter game. Gameplay video

SolarWolf is an updated clone of the 1983 arcade shooter Solar Fox. It is included with several Linux distributions. Download links Gameplay video

División Especial de Detectives is an original puzzle game in Spanish that explores the culture and history of Uruguay. Gameplay video

The Witch’s Yarn is an interactive story game from Mousechief. Gameplay video

While not a game, someone has mentioned that the Minecraft editor MCEdit used Pygame. MCEdit tutorial video

Feel free to add any other professional-quality games that have been made using Pygame in the comments section!

Disclosure: I sell a couple books that teach programming to kids (and are free to download). I don’t personally view them as being in competition with Hackety Hack, but someone else might.

Hackety Hack was a project originally started by _why the lucky stiff to teach kids programming in Ruby. It often comes up in “I want to teach my kid programming” forum threads. So I downloaded Hackety Hack and decided to give it a try.

I found Hackety Hack to be frustrating and was very unimpressed with it, and do not recommend it as a way to teach programming to a beginner.

It’s kind of crap.

Its main flaws are:

• It has little actual content. It is very short and covers programming neither widely nor deeply.
• The presentation style is sort of a “wall of text” format, where programming concepts almost never have more than one example.
• There are NO error messages or feedback at all if you make a typo in your code. (Pressing Ctrl-/ does not bring up an error console in the Windows version like the instructions say it does.)
• And at least for the Windows version, it crashes a lot. A LOT. I had to restart it at least a half dozen times before making it through all the way. It even crashed twice while I was writing this blog post. (Apparently this is also a problem with the OS X version as well.)
• The editor doesn’t have basic features: you can highlight text, but there’s no point because you can’t copy or paste. There is no Select All. There is no Undo. Pressing Ctrl-C, Ctrl-V, Ctrl-Z, or Ctrl-A just inserts a weird Unicode error character into the text. (There’s nothing like highlighting a bunch of code, pressing Ctrl-C to overwrite it all with a Unicode character, and then pressing Ctrl-Z to just get another Unicode character, realizing that all your code is permanently gone.)

There’s a few other minor gripes I have with it: The upload feature doesn’t work at all (even though you’ll get a “Uploaded!” confirmation). On the “Your Preferences” page, the link to set up an account just takes you to the http://hackety.com/ home page, instead of specifically to the http://hackety.com/users/sign_up page (though there isn’t much at all to the online content anyway). It doesn’t remember the accounts that get signed in, making switching between multiple accounts (like in a classroom setting) a pain. After uploading, the menu doesn’t give you the URL where I can find your uploaded program online. (But again, the upload functionality doesn’t work.)

In the file editor, if you don’t save your program before running it, clicking Run simply does nothing (there’s no, “You need to save first.” message). Your program won’t run until you remember to first click Save.

Hackety Hack seems like it hasn’t had a lot of time spent polishing it or paying attention to the details. (For example, there’s a couple grammar and spelling mistakes in the text.) And again, there really isn’t all that much to Hackety Hack. It is short. Very short. There are only four lessons:

• Lesson 1: A Tour of Hackety Hack. This goes over the basics of the buttons and menus in Hackety Hack itself. Sure, fine. Every piece of software needs this, and it’s adequate. But it could have easily been built into the first lesson (like “tutorial levels” in games).
• Lesson 2: Basic Programming. This covers some turtle-related coding. There’s a “Programming is like making a to-do list.” comparison. The user sets the background color. The user draws with a turtle, changing the pen color. The user then draws a box using a simple loop. It’s okay that this is boring; it’s the beginning stuff. But there’s nothing BUT the boring stuff. The lesson ends after the loop-box-drawing part. There’s nothing more.
• Lesson 3: Basic Ruby. There’s the traditional “Print hello world” example, using “alert” (which, oddly, is actually more a JavaScript style thing). It covers basic math operations, though the word “operator” is never mentioned. There are brief explanations of string replication, objects & data types, variables & assignment. It has an “ask” function for user input (again, this is not part of standard Ruby). It explains if/else statements. But nothing is placed in context of making programs, until the very end which has a meh Guess The Number game (even more meh than usual: you only get one guess and the number is not random but instead pre-programmed).
• Lesson 4: Basic Shoes. Summary: Basic layout management for the window, adding ui buttons that run code when pressed, displaying images, placing a text field. That’s it. And I don’t recommend using a new and unsupported module like Shoes instead of just learning JavaScript & HTML, because it means that as a programmer you will hit a brick wall very soon with Shoes’ limitations.

If you are a beginner who wants to learn programming you will be much better off using MIT’s Scratch, Codecademy, or Try Ruby (originally created by _why but has since been much improved). Kids Ruby is a project based off of Hackety Hack that is polished, though I found problems with it as well. (I could see it expanding and improving in the future though.)

The github page for Hackety Hack hasn’t been updated in about a year (and has dozens of untouched open issues), which I take to mean that the project is dead. I don’t see it getting better anytime soon, but I also don’t know why Hackety Hack had such a wide reputation to begin with, except for the (arguably well-deserved) good reputation of _why behind it.

More importantly, this program does provide the raw map data the entire world map (something I haven’t been able to find on the web.) Getting this from the Zelda ROM is actually a pain due to the tricks used to store the map info. The game doesn’t store individual tiles and their XY location, but rather have one of three color schemes for the border and a color scheme for the center tiles. Even then, the game only stores columns of tiles, and then each room references which columns it uses. (You can notice the same columns being used in different rooms, even though their color scheme may change.)

These tricks aren’t really needed with today’s computers for a game as simple as Zelda, so I’ve compiled the tile map data for each individual location on the map. Here’s the world map data file (it is also included in the main download below.)

Download the Zelda Walking Tour program.

View raw tile map data.

(Just unzip all the files and run the nesZeldaWalkingTour.py file with Python. Runs with both Python 2 and Python 3. Requires the Pygame module to be installed.)

You can also download the code from the GitHub project.

Blocking is not implemented, which means you can freely walk through walls:

The tiles are stored in overworldtiles.png:

To find which tiles correspond to the hex numbers in the world map data file, use this key (the numbers start at 0 and simply increasing going to the right):

And just for grins, I have a pixel-perfect single image of the entire world map, without enemies or anything else polluting it. The colors may be a bit off from the actual game, but they are consistent:

If you’d like to work on a similar project to this, here’s a good page I’ve found that I wish I had seen before I started: More GPU Tile map demos (Zelda)

Some general stats about the NES Zelda map data:

• The entire overworld is 4096 x 1344 pixels, 16 x 8 rooms, and 256 x 88 tiles in size.
• Each room (a single screen) is 16 x 11 tiles in size (the bottom row only shows the top half of the tile). It is 256 x 176 pixels in size (if you count the bottom half of the bottom row).
• Each tile, including Link himself, is 16 x 16 pixels in size.
• There are seven colors used on the overworld map (though the RGB values may not be perfect):
  • (32, 56, 236)  blue
  • (252, 252, 252)  white
  • (200, 76, 12)  brown
  • (0, 168, 0)  green
  • (116, 116, 116)  gray
  • (252, 216, 168)  tan
  • (0, 0, 0)  black

Computer game simulations make for great science fair experiments, and since the rules to Zombie Dice are so simple it’s fairly easy to program a simulation for it.

The Rules of Zombie Dice

Zombie Dice is a dice rolling game that is fun for groups, quick to play, and can be learned in a couple minutes. It has a “push your luck” game mechanic.

Each of the players is a zombie. Each of the dice represents a human victim. You want to eat brains and avoid shotgun blasts. If the footsteps come up, the human has eluded you. The rules are summarized below: (Or view the official rules PDF or view the Flash tutorial.)

1. On your turn grab 3 dice from the cup and roll them. Dice are colored red, yellow, and green and have footsteps, brains, or shotgun icons.
2. Set aside any brain and shotgun dice.
3. If you have 3 shotguns, your turn ends with a score of 0.
4. You can decide to either stop rolling or roll again.
5. If you stop, your score for this turn is the number of brains you have.
6. If you re-roll, keep the footsteps dice you rolled, set aside the brain and shotgun dice rolled, and randomly grab dice to replace the brain and shotgun dice. Roll the 3 dice.
7. Go back to step 4. You basically can keep re-rolling for as long as you want to push your luck.

To win:

The colors note your odds of winning. The entire dice set has 6 green, 4 yellow, and 3 red dice.

Here’s a video of gameplay:

Running the Tournament Program

Download the Zombie Dice simulation code. This should run with Python 2 and Python 3. You can also find it on GitHub. The two main files are:

• zombiedice.py is the basic simulator and outputs text results when the tournament is finished.
• zombiedice_web.py runs a web server and launches your browser to provide a GUI and real-time updates while the tournament is in progress.

When you click the “Begin Tournament” button, the simulation will begin with the loaded bots:

When the simulation has finished, you can reload the page to start a new tournament.

To edit which bots are being run in the simulation, modify the BOTS list at the top of zombiedice_web.py.

The AI Bots

Each zombie AI bot will be a class that has:

• A name member which is set in the constructor function. The name uniquely identifies the bot in a tournament (this way you can have multiple bots from the same class compete against each other.)
• A turn() method that has a gameState tuple passed to it.
• The turn() method calls a global roll() function (zombiedice.roll() if your bot is in another file that imports zombiedice.py) as many times as it likes. The turn is over when the turn() method returns. (Calls to roll() after getting three shotgun blasts have no effect, and roll() simply returns an empty list.)
• Optionally you can have a newGame() and/or endGame() methods that are called so that the bot can know when a game has started and ended (in case the bot should change its strategy if it is winning or losing a multi-game tournament.)

# A "skeleton" zombie class. Get it? Skeleton? Heh heh heh... eh... nevermind.
class MyZombie(object):
    def __init__(self, name):
        self.name = name
    def newGame(self):
        pass # do nothing
    def endGame(self, gameState):
        pass # do nothing
    def turn(gameState):
        results = roll()

The gameState parameter is a dictionary with the following keys:

• Key 'order' has a value of a list of player order like ['player1name', 'player2name', ...].
• Key 'scores' has a value of a dictionary with scores like {'player1name': player1score, 'player2name': player2score, ...}.
• Key 'round' has a value of an integer telling which round it is in the current game. (The first round is 1.)

The return value of roll() is a list of three tuples that have the color and icon of the rolls. For example:
[('green', 'shotgun'), ('red', 'footsteps'), ('yellow', 'brains')]

There are uppercase constant variables that you can use instead of string values, just to avoid typos:
[(GREEN, SHOTGUN), (RED, FOOTSTEPS), (YELLOW, BRAINS)]

For example, here’s the code for a Zombie Dice bot that keeps rolling until they have at least 3 brains:

class ThreeBrainsThenStops(object):
    def __init__(self, name):
        self.name = name
    def newGame(self):
        pass # do nothing
    def endGame(self, gameState):
        pass # do nothing
    def turn(self, gameState):
        brains = 0
        while brains < 3:
            results = roll()
            if results = []:
                return
            for i in results:
                if i[1] == BRAINS:
                    brains += 1

Loading Bots into the Tournament Program

Once you have the code for your bot, you can run it in a tournament by adding an instance of the bot to a list which is passed to runTournament(). For example, in zombiedice.py (the text-based tournament program):

bots = [ZombieBot_MonteCarlo('MonteCarlo', 40, 100),
        ZombieBot_MinNumShotgunsThenStops('Min2ShotgunsBot', 2),
        ZombieBot_RandomCoinFlip('RandomBot'),
        ]
runTournament(bots, 1000)

Each object made from a bot class needs to be given a unique name in the constructor. Some classes may have other parameters for the constructor. In zombiedice_web.py, this code is here:

BOTS = [zombiedice.ZombieBot_MonteCarlo('MonteCarloBot', 40, 100),
        zombiedice.ZombieBot_MonteCarlo('FastMonteCarloBot', 40, 20), # executes faster because it runs fewer experimental rolls
        zombiedice.ZombieBot_MinNumShotgunsThenStops('Min2ShotgunsBot', 2),
        zombiedice.ZombieBot_MinNumShotgunsThenStops('Min1ShotgunBot', 1),
        #zombiedice.ZombieBot_HumanPlayer('Human'), # uncomment if you want to play (learn the rules to Zombie Dice first though)
        zombiedice.ZombieBot_RollsUntilInTheLead('RollsUntilInTheLeadBot'),
        zombiedice.ZombieBot_RandomCoinFlip('RandomBot'),
        ]

The code further down in zombiedice_web.py will handle launching the web server.

The Included Bots

The zombiedice.py program has some basic bots:

• The ZombieBot_RandomCoinFlip bot simply has a 50/50 chance of continuing to call the roll() function or stopping. It'll most likely lose most games.
• The ZombieBot_MinNumShotgunsThenStops bot will continue to call the roll() function until it has a minimum number of shotgun rolls. This minimum can be set by passing an integer for the minShotguns parameter.
• The ZombieBot_HumanPlayer bot actually uses print() and input() calls so that a human player can play against the bots.
• The ZombieBot_RollsUntilInTheLead bot will keep rolling until it gets into the lead compared to the other bots. This bot takes higher risks once it starts trailing.
• The ZombieBot_MonteCarlo bot is the most sophisticated of all the bots. It basically runs several random experiments to see if the next roll would result in 3 or more shotguns. You can pass different values to the constructors to tell it how many experiments to run on each turn and what percentage of them must not result in death to roll again.

Write your own bots and then see how they do against these simple bots. You can post your code to https://gist.github.com and post a link to it in the comments section below.

This tutorial assumes you know the basics of Pygame and Python programming. If you don’t, it’s probably easy enough to follow anyway.

A button is a common user interface (UI) control that is used in many software applications. It seems simple enough: there’s a button on the window and you click on it and something happens. But there’s a lot of details we should plan out ahead of time. Remember, we want to make a generic button class so that other programmers can use this in their games and programs. Once you’ve read through the process here, you’ll be familiar with how to make your own modules for UI elements.

Designing a UI button class is good a good programming practice exercise.

Download the PygButton module here. You can also look at just the pygbutton.py file itself.

The Feature List (and the Non-Feature List)

First, let’s create a list of design details for the buttons:

1. Can have any width or height.
2. The buttons can have text on them. The font and size can be customized.
3. The background color of the button can be changed to any RGB value, as can the foreground (text) color.
4. The button’s properties (bgcolor, bgcolor, text, font, size, etc.) can be dynamically changed.
5. The button has three states: normal, down (when the mouse cursor has pressed down on the button), and highlight (when the mouse cursor is over the button but not pressing down).
6. Pygame’s mouse events are passed to the button’s handleEvent() method, which update’s the button’s state and calls any event-handling code.
7. The button recognizes 6 different types of events: mouse enter, mouse exit, mouse down, mouse up, mouse click, and mouse move. (These are explained later.)
8. Instead of text, the user will be able to specify images for the three different states. We’ll call these image-based buttons.
9. The button’s visibility can be toggled on and off.

And it’s always a good idea to come up with a list of things we specifically won’t implement (to avoid feature creep each time we think, “Hey, it’d be cool if we could…”). These features could always be implemented later.

1. Must be rectangular (i.e. can’t be oval).
2. No transparency.
3. No more than the three states.
4. No hotkeys attached to them, or keyboard focus.
5. No special “double click” event (it’ll just be two click events).
6. For now, the highlight state looks identical to the normal state for text-based buttons.
7. A button is either text-based or image-based, there’s no hybrid.
8. No “disabled” state.
9. Only one font & color at a time for text-based buttons.
10. The text caption will always be centered, not left- or right-aligned.

(But you can add these features to your own code if you want.)

Design Details

Whenever you’re designing something, always do a prior art search first. Looking at how buttons on a web page work is a good case to examine, for example.

The buttons have three states and can have a different appearance for each state.

• The “normal” state is what the button looks like when it has not been clicked and the mouse is not over it.
• The “highlight” state is what the button looks like when the mouse is hovering over it, but not clicking it. We can use this to add some kind of highlighting behavior when the mouse glides over the button. For normal text-based buttons, this state will look identical to the normal state.
• The “down” state is what the button looks like when it is being clicked down.

There are also six different “button events” that the buttons can produce based on the Pygame mouse events that are passed to them:

• Enter – When a MOUSEMOTION event has told the button that the mouse is over the button when previously it wasn’t.
• Exit – When a MOUSEMOTION event has told the button that the mouse is no longer over the button when previously it was.
• Move – When the button has received a MOUSEMOTION event.
• Down – When the mouse is pressed down on the button.
• Up – When the mouse is released on the button.
• Click – When the mouse was pressed down on the button and released over the button. (Releasing the mouse off of the button does not trigger the click event.)

(Note: The buttons won’t produce Pygame USEREVENTS. I didn’t see a significant need for them.)

As to how the mouse button looks, I’ll be using the Windows look-and-feel of buttons. Here’s what they look like zoomed in:

Notice that the 3D appearance is caused by drawing these black, gray, and white outlines. These lines don’t change if the background color of the button changes.

What the API will Look Like

Before diving into coding, we need a concrete plan for how other programmers will use this module. It doesn’t matter how sophisticated your library is, if it is opaque, difficult to learn, and inconsistent no one will want to learn it and it will not be used. It’s important to get these details right the first time, because making changes (like changing a function name or getting rid of a class) later on could break other people’s code that uses your library. This means they won’t adopt newer versions and new features (since the newer version breaks their code), which further limits the popularity of your module.

The button’s API will have three main parts: the constructor function that creates it, the function that draws the button to a pygame.Surface object (to display it on the screen), and a handleEvent() method that we can pass pygame.Event objects to so it knows what is happening in the program. The code will roughly look like this:

myButton = pygbutton.PygButton(rectObj, 'Caption text')
...
for event in pygame.event.get(): # event handling loop
    myButton.handleEvent(event)
...
myButton.draw(displaySurface)

Before we start coding, we should write out the method names and parameters for the PygButton class first. This will help cement what we want to code before we start coding:

• def __init__(self, rect=None, caption='', bgcolor=LIGHTGRAY, fgcolor=BLACK, font=None, normal=None, down=None, highlight=None) – The constructor. Note that pretty much everything has a default argument. If the user just wants asimple button, we shouldn’t have to make her write out tons of boilerplate code. Let’s just supply default values.
• def handleEvent(self, eventObj) – Changes the button’s state if the Pygame event passed is relevant.
• def draw(self, surfaceObj) – Draws the button (in its current state) to the surfaceObj surface.
• def mouseClick(self, event) – Called when the button has a click event. (These methods don’t do anything in the PygButton class, but you can override this class to implement code in these methods.)
• def mouseEnter(self, event) – Called when the button has a “mouse enter” event.
• def mouseExit(self, event) – Called when the button has a “mouse exit” event.
• def mouseMove(self, event) – Called when the button has a “mouse move” event.
• def mouseDown(self, event) – Called when the button has a mouse button down event.
• def mouseUp(self, event) – Called when the button has a mouse button up event.
• def setSurfaces(self, normalSurface, downSurface=None, highlightSurface=None) – Let’s the user specify either image filenames or pygame.Surface objects to use for each of the states. (This sets the button to be an image-based button.)

And here are some properties that we’d like to set for the PygButton class. Whenever you think you’ll need a get and set method for something (i.e. getCaption() and setCaption() instead of just a caption property), this is a strong indication that a property would be better instead.

• caption – The string for the text caption in the center of the button.
• rect – A pygame.Rect object which gives the position and size of the button.
• visible – A boolean that sets the button to visible (True) or invisible (False).
• fgcolor – An RGB tuple or pygame.Color object for the text (foreground) color.
• bgcolor – An RGB tuple or pygame.Color object for the background color.
• font – A pygame.font.Font object for the font (and size) to use for the text caption.

Setting any of these properties (other than rect) will result in the button becoming a text-based button if it was previously an image-based button. Setting the rect property of an image-based button simply resizes the images.

Note that we don’t have properties for setting the normal, down, and highlight Surfaces. This is because when we switch from a normal text-based button (which uses the caption, fgcolor, bgcolor, and font properties) to an image-based button, we want to set the images for all three Surfaces at the same time (even though we have defaults for the down and highlight surfaces.)

The Preamble Code

Here’s the code that goes at the top of the pygbutton.py file. It imports Pygame and calls the init() function for the fonts and creates a few constants that we’ll use in the module.

import pygame
from pygame.locals import *
pygame.font.init()
PYGBUTTON_FONT = pygame.font.Font('freesansbold.ttf', 14)
BLACK     = (  0,   0,   0)
WHITE     = (255, 255, 255)
DARKGRAY  = ( 64,  64,  64)
GRAY      = (128, 128, 128)
LIGHTGRAY = (212, 208, 200)

The Constructor Function

The constructor function is fairly straight forward. There are many different attributes that we can customize for a button, but we can always just create a standard default button.

class PygButton(object):
    def __init__(self, rect=None, caption='', bgcolor=LIGHTGRAY, fgcolor=BLACK, font=None, normal=None, down=None, highlight=None):
        if rect is None:
            self._rect = pygame.Rect(0, 0, 30, 60)
        else:
            self._rect = pygame.Rect(rect)
        self._caption = caption
        self._bgcolor = bgcolor
        self._fgcolor = fgcolor
        if font is None:
            self._font = PYGBUTTON_FONT
        else:
            self._font = font
        # tracks the state of the button
        self.buttonDown = False # is the button currently pushed down?
        self.mouseOverButton = False # is the mouse currently hovering over the button?
        self.lastMouseDownOverButton = False # was the last mouse down event over the mouse button? (Used to track clicks.)
        self._visible = True # is the button visible
        self.customSurfaces = False # button starts as a text button instead of having custom images for each surface
        if normal is None:
            # create the surfaces for a text button
            self.surfaceNormal = pygame.Surface(self._rect.size)
            self.surfaceDown = pygame.Surface(self._rect.size)
            self.surfaceHighlight = pygame.Surface(self._rect.size)
            self._update() # draw the initial button images
        else:
            # create the surfaces for a custom image button
            self.setSurfaces(normal, down, highlight)

For image-based buttons, the setSurfaces() method is called, which handles the default images for the Down and Highlight state if they are unspecified. It also checks that the images are the same size. Note that the user can specify either pygame.Surface objects or string filename values.

    def setSurfaces(self, normalSurface, downSurface=None, highlightSurface=None):
        """Switch the button to a custom image type of button (rather than a
        text button). You can specify either a pygame.Surface object or a
        string of a filename to load for each of the three button appearance
        states."""
        if downSurface is None:
            downSurface = normalSurface
        if highlightSurface is None:
            highlightSurface = normalSurface
        if type(normalSurface) == str:
            self.origSurfaceNormal = pygame.image.load(normalSurface)
        if type(downSurface) == str:
            self.origSurfaceDown = pygame.image.load(downSurface)
        if type(highlightSurface) == str:
            self.origSurfaceHighlight = pygame.image.load(highlightSurface)
        if self.origSurfaceNormal.get_size() != self.origSurfaceDown.get_size() != self.origSurfaceHighlight.get_size():
            raise Exception('foo')
        self.surfaceNormal = self.origSurfaceNormal
        self.surfaceDown = self.origSurfaceDown
        self.surfaceHighlight = self.origSurfaceHighlight
        self.customSurfaces = True
        self._rect = pygame.Rect((self._rect.left, self._rect.top, self.surfaceNormal.get_width(), self.surfaceNormal.get_height()))

Note that the PygButton class also stores the original images in the origSurfaceNormal, origSurfaceDown, and origSurfaceHighlight member variables. This is so that when the code does a resize, we are resizing the original images. The button could be resized multiple times, and this would result in poor quality if we tried to resize and previously resized image. (The same way a photocopy of a photocopy of a photocopy reduces the image quality.)

The draw() Method

The draw() method is straightforward since it only copies the surfaceNormal, surfaceDown, and surfaceHighlight properties to the passed pygame.Surface object. The draw() method is called whenever the button's current state needs to be drawn to a Surface object. Drawing the buttons themselves will be handled by the _update() method.

def draw(self, surfaceObj):
    """Blit the current button's appearance to the surface object."""
    if self._visible:
        if self.buttonDown:
            surfaceObj.blit(self.surfaceDown, self._rect)
        elif self.mouseOverButton:
            surfaceObj.blit(self.surfaceHighlight, self._rect)
        else:
            surfaceObj.blit(self.surfaceNormal, self._rect)

The _update() method will be called whenever the appearance of the buttons has been modified. This happens when the text, background color, size, etc. of the button has changed. This is why the name of _update() begins with an underscore; it's only called by the class's code itself. It shouldn't be called by the user.

The _update() method is mostly drawing code for text-based buttons (or resizing the images for image-based buttons).

    def _update(self):
        """Redraw the button's Surface object. Call this method when the button has changed appearance."""
        if self.customSurfaces:
            self.surfaceNormal    = pygame.transform.smoothscale(self.origSurfaceNormal, self._rect.size)
            self.surfaceDown      = pygame.transform.smoothscale(self.origSurfaceDown, self._rect.size)
            self.surfaceHighlight = pygame.transform.smoothscale(self.origSurfaceHighlight, self._rect.size)
            return
        w = self._rect.width # syntactic sugar
        h = self._rect.height # syntactic sugar
        # fill background color for all buttons
        self.surfaceNormal.fill(self.bgcolor)
        self.surfaceDown.fill(self.bgcolor)
        self.surfaceHighlight.fill(self.bgcolor)
        # draw caption text for all buttons
        captionSurf = self._font.render(self._caption, True, self.fgcolor, self.bgcolor)
        captionRect = captionSurf.get_rect()
        captionRect.center = int(w / 2), int(h / 2)
        self.surfaceNormal.blit(captionSurf, captionRect)
        self.surfaceDown.blit(captionSurf, captionRect)
        # draw border for normal button
        pygame.draw.rect(self.surfaceNormal, BLACK, pygame.Rect((0, 0, w, h)), 1) # black border around everything
        pygame.draw.line(self.surfaceNormal, WHITE, (1, 1), (w - 2, 1))
        pygame.draw.line(self.surfaceNormal, WHITE, (1, 1), (1, h - 2))
        pygame.draw.line(self.surfaceNormal, DARKGRAY, (1, h - 1), (w - 1, h - 1))
        pygame.draw.line(self.surfaceNormal, DARKGRAY, (w - 1, 1), (w - 1, h - 1))
        pygame.draw.line(self.surfaceNormal, GRAY, (2, h - 2), (w - 2, h - 2))
        pygame.draw.line(self.surfaceNormal, GRAY, (w - 2, 2), (w - 2, h - 2))
        # draw border for down button
        pygame.draw.rect(self.surfaceDown, BLACK, pygame.Rect((0, 0, w, h)), 1) # black border around everything
        pygame.draw.line(self.surfaceDown, WHITE, (1, 1), (w - 2, 1))
        pygame.draw.line(self.surfaceDown, WHITE, (1, 1), (1, h - 2))
        pygame.draw.line(self.surfaceDown, DARKGRAY, (1, h - 2), (1, 1))
        pygame.draw.line(self.surfaceDown, DARKGRAY, (1, 1), (w - 2, 1))
        pygame.draw.line(self.surfaceDown, GRAY, (2, h - 3), (2, 2))
        pygame.draw.line(self.surfaceDown, GRAY, (2, 2), (w - 3, 2))
        # draw border for highlight button
        self.surfaceHighlight = self.surfaceNormal

The Event Callback Methods

There are two ways that we can execute code in response to button-related events. The first is to have a method in the PygButton class (and its subclasses) get called that contains the code we want to run.

We'll just put stub functions for these methods. Any subclasses that inherit from PygButton can override these methods and use any code they want. But for now, they do nothing:

    def mouseClick(self, event):
        pass # This class is meant to be overridden.
    def mouseEnter(self, event):
        pass # This class is meant to be overridden.
    def mouseMove(self, event):
        pass # This class is meant to be overridden.
    def mouseExit(self, event):
        pass # This class is meant to be overridden.
    def mouseDown(self, event):
        pass # This class is meant to be overridden.
    def mouseUp(self, event):
        pass # This class is meant to be overridden.

The handleEvent() Method

Whenever our program calls pygame.event.get_events() to retrieve all the events generated (for keyboard, mouse, etc. events) we should pass them to handleEvent() so the buttons can update their state. The second way to execute code in response to button events is with the return value of handleEvent().

The handleEvent() method has been set up so that it returns a list of all button events that have happened due to the normal Pygame events passed to handleEvent(). So if a mouse move Pygame event has happened over the button (when previously the mouse cursor wasn't over the button), the handleEvent() method will return the list ['enter', 'move'].

The caller of handleEvent() can perform any actions in response to these events.

Here's the code for handleEvent():

def handleEvent(self, eventObj):
    if eventObj.type not in (MOUSEMOTION, MOUSEBUTTONUP, MOUSEBUTTONDOWN) or not self._visible:
        # The button only cares bout mouse-related events (or no events, if it is invisible)
        return []
    retVal = []
    hasExited = False
    if not self.mouseOverButton and self._rect.collidepoint(eventObj.pos):
        # if mouse has entered the button:
        self.mouseOverButton = True
        self.mouseEnter(eventObj)
        retVal.append('enter')
    elif self.mouseOverButton and not self._rect.collidepoint(eventObj.pos):
        # if mouse has exited the button:
        self.mouseOverButton = False
        hasExited = True # call mouseExit() later, since we want mouseMove() to be handled before mouseExit()
    if self._rect.collidepoint(eventObj.pos):
        # if mouse event happened over the button:
        if eventObj.type == MOUSEMOTION:
            self.mouseMove(eventObj)
            retVal.append('move')
        elif eventObj.type == MOUSEBUTTONDOWN:
            self.buttonDown = True
            self.lastMouseDownOverButton = True
            self.mouseDown(eventObj)
            retVal.append('down')
    else:
        if eventObj.type in (MOUSEBUTTONUP, MOUSEBUTTONDOWN):
            # if an up/down happens off the button, then the next up won't cause mouseClick()
            self.lastMouseDownOverButton = False
    # mouse up is handled whether or not it was over the button
    doMouseClick = False
    if eventObj.type == MOUSEBUTTONUP:
        if self.lastMouseDownOverButton:
            doMouseClick = True
        self.lastMouseDownOverButton = False
        if self.buttonDown:
            self.buttonDown = False
            self.mouseUp(eventObj)
            retVal.append('up')
        if doMouseClick:
            self.buttonDown = False
            self.mouseClick(eventObj)
            retVal.append('click')
    if hasExited:
        self.mouseExit(eventObj)
        retVal.append('exit')
    return retVal

PygButton Properties

Instead of having simple member variables for the caption, rect, visible, fgcolor, bgcolor, and font, we can use Python properties instead. This is better, because each time these values get updated we need to run some code that updates the Surface objects that hold the button's look. In other languages, this would require the use of bulky get and set methods. Python's property() function lets us assign methods to be called whenever the member variables need to be get or set.

    def _propGetCaption(self):
        return self._caption
    def _propSetCaption(self, captionText):
        self.customSurfaces = False
        self._caption = captionText
        self._update()
    def _propGetRect(self):
        return self._rect
    def _propSetRect(self, newRect):
        # Note that changing the attributes of the Rect won't update the button. You have to re-assign the rect member.
        self._update()
        self._rect = newRect
    def _propGetVisible(self):
        return self._visible
    def _propSetVisible(self, setting):
        self._visible = setting
    def _propGetFgColor(self):
        return self._fgcolor
    def _propSetFgColor(self, setting):
        self.customSurfaces = False
        self._fgcolor = setting
        self._update()
    def _propGetBgColor(self):
        return self._bgcolor
    def _propSetBgColor(self, setting):
        self.customSurfaces = False
        self._bgcolor = setting
        self._update()
    def _propGetFont(self):
        return self._font
    def _propSetFont(self, setting):
        self.customSurfaces = False
        self._font = setting
        self._update()
    caption = property(_propGetCaption, _propSetCaption)
    rect = property(_propGetRect, _propSetRect)
    visible = property(_propGetVisible, _propSetVisible)
    fgcolor = property(_propGetFgColor, _propSetFgColor)
    bgcolor = property(_propGetBgColor, _propSetBgColor)
    font = property(_propGetFont, _propSetFont)

Example Programs

This is a very important step. We need to accompany the module with some example programs that show how simple it is to actually use the module in a working program. I would even say that including example programs is more important than having documentation (for smaller libraries, at least.)

Download the PygButton module and example programs here.

…

Wow, this was an easy blog post to write.

I suppose a longer answer would be more satisfying.

I have no idea how old you, the reader, are but that’s irrelevant. No, you are not too old to learn programming. If you wonder if you are too old to become a professional software developer and are under the age of 50, the answer is still no. (And even above that age, the answer is merely “probably”.)

But you might feel too old, or at least feel forever crippled because you didn’t start coding the instant you developed fine motor skills. But I still assure you: You are not too old to learn programming.

“Software development, like professional sports, has a way of making thirty-year old men feel decrepit.

-Neal Stephenson, “Snow Crash”

I have a two stories to tell. The first involves me in high school. I was a nerdy teenager who wanted to become a “leet” computer hacker. I had rudimentary knowledge of Qbasic. I had started to make some GUI programs with my pirated copy of Visual Basic 4. I heard of 2600 magazine (“The Hacker Quarterly”) and started going to the meetings on the first Friday of the month at the mall.

The first time I went, I felt like everyone was smarter and more knowledgeable than I was (and they were). I resolved to hit the books and study continuously so that for the next month’s meeting, I wouldn’t feel like such a noob.

This feeling did not go away by the next month’s 2600 meeting.

This feeling did not go away for the next several dozen 2600 meetings.

Half the days I wake up, I still feel shockingly unprepared and ignorant about the skills that I am paid a salary for. That feeling is perfectly normal. Everyone in the universe has that.

Computing is a field that is effectively infinite. It is easy to despair that you will never reach the horizon no matter how long you travel but realize that this feeling like you’re a clueless idiot, to a certain extent, is O-K. And don’t forget about the many miles you can accomplish.

The second story is about how I first learned programming. I was one of those people who started learning programming in the third grade. My friend had found Fred D’Ignazio’s book, “Invent Your Own Computer Games” at the school library, and this was the book that taught me programming in BASIC by making small games. I was already addicted to Nintendo, and immediately took a liking to programming and began to make a few of my own games.

Here’s the thing though. Most of the games I made were just slight variations of games that I had already seen in D’Ignazio’s book. And I never was able to wrap my head around the Tic Tac Toe AI he presented in that book. My programming aptitude for the next several years didn’t really improve all that much. It was a fun hobby and maybe it did give me a slight edge, but looking back on it now I can’t help but think, “You’ve been programming since you were 9? So what? All your programs back then probably sucked.”

Mine sure did. The reason I wrote “Invent Your Own Computer Games with Python” was because there were so many different advanced concepts I would have been fully capable of learning, but I just didn’t have access to approachable resources. I didn’t even know what to look for. At this point though, the amount of programming knowledge I gained between the ages of 9 and 18 could be obtained by anyone with an internet connection who committed to study a couple hours a day for three or four months. Or even shorter if you find programming to be fun, because it’s easy to kill a dozen hours coding on a weekend.

Those years of “programming since I was 9″ didn’t really matter that much in the long run. What difference it did have was it showed me that programming wasn’t an impossible skill to acquire.

The reasons I market “Invent with Python” as a book for kids is because 1) kids, in fact, can learn programming and 2) so adults will think its possible for them to learn. There’s a large mystique around software development that repels a lot of people who don’t think they’re qualified since they aren’t silicon valley geniuses or because they say “oh, I’m not really good at math”. The largest hurdle to programming that I’ve encountered in people isn’t intellectual so much as psychological.

Learning to code is much like learning to play a musical instrument. Yes, it does take hours and hours of concerted practice. But even if you don’t do it professionally, it’s still fun and enriching. It helps to be Mozart and start at the age of five with a pushy composer father, but it is far from necessary. By the time you reach my level of experience and knowledge, you will realize how silly the “am I too old?” question is.

No, you are not too old to learn programming.