Tag Archives: alpha

Picking up the Slack

                When I wrote my alpha post this past Sunday, I was on cloud 9. (“alpha post” meaning my post about the alpha release, not the best, strongest, and most desirable to a mate post I’ve ever written) While I’m still on at least cloud 8.5, I also recognize the amount of work I have yet to do, and it starts with py2exe.

                Py2exe is a module written for Python that lets one compile code into an executable file for easier distribution. It means that I’ll be able to make a .exe file instead of having all potential testers download python along with all the associated libraries and code. Of course, using py2exe isn’t as simple as typing in a command. Instead, I am required to write a setup file so that the code can be properly compiled with this or that parameter. And that’s where the fun starts.

                Right off the bat, things get a little confusing:

  1. from setuptools import setup, find_packages

I know that we have a module here called setuptools we’re pulling a few things out of, but what’s that comma doing there, and why is it there? What is find_packages? How will I use it, and why am I importing it? The same goes for all of this:

  1. import py2exe, innosetup
  2. from glob import glob
  3. import os
  4. import shutil

And things don’t necessarily get easier from there. Now I have lines that I think I understand, but since I don’t know what the above code accomplishes, I don’t even know if I’m right. Lines like:

shutil.rmtree(‘dist’, ignore_errors=True)

I think that removes a certain directory from the installation, but I’m not entirely sure. I also don’t know why I would have errors I want to ignore.

This one is kind of confusing too:

return [ (”, [‘hope.html’, ‘settings.confspec’]), sound_lib_data()]

When Chris first started teaching me to code in Python, one of the biggest bad habits I had to overcome was cutting and pasting code, especially when I didn’t know what it was. Almost nothing, I have learned, is worse than putting a bunch of code into a program when I don’t know what it does. First, it screws up my ability to troubleshoot problems if something goes wrong with that code. Second, it prevents me from learning valuable lessons about how various Python libraries work.

There are tons of Python libraries out there that can perform metric tons of different functions. While I know that I don’t need to learn each one of them in order to be successful with programming, I understand it will be important for me to learn the most commonly-used ones so that I can work them into my existing code. I won’t say this isn’t frustrating at times. I love learning new things, but right now I just want to get back to programming the game. Still, if I want to be able to churn out product faster and more efficiently in the future, I had better go through all the steps now.

O’ Mega Alpha

                On January 9 I committed my first game files to the repository with the tag, “Initial commit. Let’s hit some stuff!” As of today, May 1, I officially have a working alpha. It’s not a full game; it’s only one fight. You can’t rocket to stardom in the Audio Boxing Association just  yet. You can go three rounds with a washed up clown named Bonko, though, which is enough to test the engine and make sure everything works properly.

                It’s a pretty wild feeling to sit down and play this from start to finish—from the opening menu to the closing stats—and realize that I actually built something with my own ten fingers and—you’ll pardon the expression—my grey matter. On December 1, I had scant knowledge of programming and no idea how to program in Python. On January 1 I had no code in place—nothing but a handful of ideas I thought would make a fun project. After four months of studying, coding, following conversations on the official Python tutor list, and bugging Chris half to death with code questions, though, I have something that I can technically call a game. Even though I still have quite a lot yet to accomplish, I couldn’t be happier.

                I think it says a lot that I was able to program the basics of a boxing game while holding down a full-time job, not for me, but for the simplicity of the process. I have always been daunted by the prospect of programming a game because of all the things I was afraid I didn’t know, but when it really comes down to it, there’s not that much involved.

  • Step 1: Pick a language
  • Step 2: Get involved in that language’s development community
  • Step 3: Pick up a book and start reading about the language
  • Step 4: Start coding something—anything

It turns out that What I took to be an incredibly difficult process ended up being a fun set of logic puzzles. I won’t lie and say that it’s not challenging; I’ve wanted to pull my hair out more than once. But when I run the program and everything works just as I intend, it’s an incredible feeling of accomplishment. I’ve barely scratched the surface of Python. There are hundreds of modules out there that I cannot even begin to fathom. Even so, I’ve learned enough that I can put together a game.

                So what’s next? The game still needs a trophy system; it needs a mechanism for saving and restoring progress; it needs a whole host of sounds and voices; and, most importantly, it needs the rest of the enemies to be programmed. And—yes—it needs a title. (I’ll take any and all suggestions for any of the above.) With all that’s left to do, though, there’s a light at the end of the tunnel. In fact, there are many lights.  There is also smoke, the cheering crowd, and the promise of victory.