Tag Archives: doughnuts

Building Tools

One of the things that makes coding particularly awesome—especially in the case of Python—is the ability to reuse code. If the programmer writes things in such a way as to make them generic enough, he can then take those generic sections of code and apply them to different situations. As one might expect, reusing code that has already been written speeds up development time considerably by allowing the programmer to automate different chunks of the program. To illustrate, let’s put this in the context of one of my apparently recurring themes, doughnuts.

Say you decide one morning that you’re going to start your own bakery. You get the space, buy the equipment and groceries, and refine your recipes. The problem with your bakery setup, however, is that you’re the only employee, which means you’re responsible for everything from purchasing groceries to preparing pastries to dealing with the customers to cleaning up afterward. If you continue in this fashion for a while, you will get things done. In fact, you might even turn a profit if you’re lucky. Unfortunately, though, your business won’t grow very much until you can get some help, and, quite frankly, you’re getting tired.

To take some of the pressure off of you, you decide to hire and train someone to help out around the place. You hire a new kid, train him to do basic jobs like cleaning the seating area and washing dishes, and as a result, free up more of your time to invent, cook, and socialize with customers. Things are going just fine for a while, but you eventually come to realize that your business could be even more productive if you hired a third person to help you with the morning doughnut frying and filling. Side note: jelly doughnuts, you guys. Seriously. Jelly doughnuts.

Reusing code is a lot like the metaphorical bakery. You find a task you have to accomplish pretty regularly, and you farm the work of that task out to a separate process. Either that, or you take a complicated, time-consuming activity and wrap that up in a function somewhere. Here’s an example in non-bakery terms.

I am currently using Pygame for its ability to process keys. When I want to figure out what keys are being pressed, it can look a little something like this:

  1. for event in pygame.event.get():
  2. if event.type == pygame.KEYDOWN:
  3. if event.key == pygame.K_LEFT:
  4. player.walk(x=-1, y=0)
  5. if event.type == pygame.KEYDOWN:
  6. if event.key == pygame.K_RIGHT:
  7. player.walk(x=1, y=0)
  8. if event.type == pygame.KEYDOWN:
  9. if event.key == pygame.K_UP:
  10. player.walk(x=-0, y=1)
  11. if event.type == pygame.KEYDOWN:
  12. if event.key == pygame.K_DOWN:
  13. player.walk(x=0, y=-1)

If you didn’t bother reading all of that, I don’t blame you. I certainly don’t want to have to write it every time I want to create a game. To solve the problem, I created a code module whose job it is to carry out those basic functions, and all I have to do is give it two pieces of information: which key should call which function, and when the module should check to see what keys have been pressed down. The code for the first part looks like this:

  1. keyboard_handler.register_keydown(‘left’, player.move, x=-1, y=0)
  2. keyboard_handler.register_keydown(‘right’, player.move, x=1, y=0)
  3. keyboard_handler.register_keydown(‘up’, player.move, x=0, y=1)
  4. keyboard_handler.register_keydown(‘down’, player.move, x=0, y=-1)

And when I want to have the program check which keys are down, I just do this:

  1. for event in pygame.event.get():
  2. keyboard_handler.process_key_events(event)

With a single call to process_key_events, I tell the program to go look at my shiny, new keyboard handler and run all that bloated code you saw above. Instead of having to type 13 lines of code, I now only need to type 6, thus slashing my required code by more than half. This makes my programs easier to write because there is less writing to do. At the same time the code is easier to debug because there is less of it to read. Productivity 1, frustration 0.

I’m excited to be finished with the tool-making process—at least for now. I’m equally excited, however, to have designed something that can really speed up coding and simplify development, not just for myself, but for anyone who wants to code in Pygame. Che Martin of Blind Adrenaline Simulations once told me about two weeks he spent building a module to make jaws speak in his games. At the time I couldn’t fathom spending two weeks coding something that wasn’t directly connected to a game. Now that I’ve spent 8 days creating my own tool to build into all of my future projects, though, I understand what he meant, and I appreciate the experience.

Punching Through

                I love bashing my head against a problem until I break through the barrier. The actual bashing part doesn’t always make for an exciting evening, but I would be lying if I said the intellectual challenge wasn’t enjoyable from time to time., The best part is when everything clicks into place, and you realize you’re learning something!

                Amidst all of the little challenges life in general has to offer, I’ve been working in my free time on how to make punches work better. As I wrote in an earlier post, I want to build in actual punches and boxing mechanics to make the game both more realistic and challenging. In order to do that I decided to go back to the drawing board and create one set of punches that would apply equally to both the player and the opponent. The hard part was: how could I write the code elegantly and simply enough that it won’t be a mess when I go back later to refactor it. How could I make, for example, code apply to either the player or the opponent without specifically checking whose throwing the punch, defending the punch, remembering the punch, and so on? As it turns out, the basis for the solution is incredibly simple, and I owe Aaron Cannon a huge debt of gratitude for bringing it to my attention.

                Basically, it goes like this: when you pass a complex object around in Python, you don’t actually pass around copies of the object; instead, you pass along a reference to that object. It’s like telling your co-workers, “Hey, I brought doughnuts for everyone. If you want them, they’re in the break room.” In this way, anyone who wants to modify your object—or steal all of the jelly or cream-filled doughnuts like that jerk Bob from accounting—can do so easily. This turns out to be an awesome thing, because it means I don’t have to keep track of lots of copies of my opponent and player. Instead, I create one player and one opponent, and then I just let all of the punches, stats, and everything else know where to find them.

Also I want doughnuts now.

                Figuring out how to make all of this work has been a thorn in my side for the past few days, and I’ve been pondering it in spare moments. When the solution finally came to me tonight while I was running on the treadmill, I couldn’t wait to write it down and make it work. And wouldn’t you know, it works like a charm!

                I’ve missed this kind of zeal—this excitement—in programming for a long time, and I’m glad it finally came home to roost. It’s like turning the corner and seeing a whole new vista spread out in front of you, and the view is breathtaking. I almost wish I could call in sick to work tomorrow so I could keep working. Almost.

                Oh hey! Did you guys know Christmas is coming up? You might have heard something or other about it. Well in addition to all of the awesome family and togetherness and good cheer and celebration that the Christmas season brings, it also gives me two weeks off of work while the students travel home to see their own families. And you know what that means …

                Two straight weeks of Swamp!


                No wait. That’s not it. Is it?