Monthly Archives: May 2011

Much ado about … What?

                Randi mentioned in passing yesterday that it has been a lot of time since I wrote my last blog post. When I look over the progress I’ve made—or haven’t made—in the past 9 days, though, I can see why. Still, it has been an interesting thing to ponder.

                The beauty of Twitter and microblogging is the ability to make insignificant things sound more important. You might not write a whole blog post on what you had for breakfast, but you could fill 140 characters with that information. (Note: doing so, in my opinion, is really silly. People generally don’t care what you had for breakfast unless it was a plate of duck embryos.) Twitter is handy for those smaller thoughts one has; in my case it’s handy for the smaller updates. If I get a particular facet of something working, that’s worthy of a twitter update. If I finish a whole system, though, I’ll write it both places, and the blogged version will be fleshed out and thorough.

                I can see the other side of it too, though. Before Twitter, when places like Miriani and Star Conquest had online change logs, I would read them religiously. I would log on to them day after day in the hope that something new and exciting would be posted. When there wasn’t something new that day I would be disappointed. Now that I’m posting my own version of change logs, though, I understand why new content wasn’t forthcoming on a daily basis. I managed to get the timeline view of the opponent creator working on Sunday. I started writing a few dialog boxes. I don’t know that I could stretch that into 300 or 400 words worthy of a blog post, though.

                All this is to say that even when this blog isn’t updated, I am still working on the game. If you want more frequent thoughts and updates, GMPUpdates on Twitter is the place to check. If you don’t mind waiting between thoughts and developments, you can check this site as often as you like. I promise I won’t go dormant on anyone.

                In the meantime, though, I have an opponent creator to finish.

Update on the Opponent Creator

                I’ve been hard at work on the opponent creator, and while I’ve made progress on it, it’s nothing that really lends itself to a lengthy blog post. So instead, I’ll give you all a run-down of what you can expect from the program to whet your appetite.

Why design an opponent creator?

                An opponent’s punch has a number of factors: time of occurrence, speed, strength, height (head or body), side (left or right), whether it can be interrupted, and whether a player can stun the opponent if he manages to dodge the punch. That’s 7 arguments just for the punch. Then there’s the unblock method which determines how long the opponent drops his arms and whether punching him during this time will yield up an ultra punch. When you think about the fact that between punching, taunting, and unblocking, I have to design over 100 events per round with all their associated parameters, you start to see how big an undertaking this is. In fact, hand-coding the first round of the test opponent took well over an hour.

                Part of the reason I want to build an opponent creator is for my own sanity. If I can design something that will enable me to cut down on production time, so much the better. Beyond that, though, I want members of the community to have a crack at designing their own opponents and contributing them to the project. Everyone loves expansion packs.

How it Works

                I envision the opponent creator as having two distinct phases: a timeline that creators can navigate to place punches and taunts, and an input window where said data can be entered. Players will use the timeline to jump from tenths of seconds to whole minutes either forward or backward, and it is here that they will press different keys to launch the input window. The timeline will also have a playback feature that will allow designers to hear the opponent’s half of the fight in real-time.

The input window will be a simple form with boxes for speed, strength, height, side, and so on. When the designer clicks the “OK” button, the behavior will be inserted directly into the timeline.

 When the opponent is complete, its creator will save the timelines for the 3 rounds as a file which they can distribute to friends, integrate into their own game, or send to me for possible inclusion into expansion packs. My hope is to make the design and distribution process simple enough that anyone will be able to use it.


                When I was 14 my school loaned me a brand new, state-of-the-art laptop that possessed the ability to dial into the internet. It was a monster of a machine with all of 4 gigabytes of hard drive space, a detachable 3.5 inch floppy drive, and JAWS 3.2, and I loved it. For those of you who remember those early versions of JAWS, you’ll remember that the internet was a trying place to navigate full of inaccessible links and hard to read content. Still, the text games worked perfectly, and I suddenly had a new hobby.

                It started out with Telearena, a simple text-based BBS game with little to offer players beyond stock fights and repeated descriptions. Take any standard Merc mud, divide the fun quotient by 10, stomp on the result, set it on fire, then put the fire out with bleach, and you might come close to the enjoyment one could gain from playing it. Of course, it was the first game of its kind I ever played, and I was hopelessly entranced.

                From there it became Majormud, and then there was The Rose, Council of Guardians, by far my favorite of the BBS titles. But there were dozens more games out there, and I played them all.

                It wasn’t long, though, before I discovered the true potential for text-based gaming that actual Multi-user Domains (muds) could bring to the table—muds like Dreams, Discworld, and The Inquisition. There were others: Aardwolf, God Wars 2, BatMud, Achaea, 3 kingdoms, MUME—Multi Users in Middle Earth, and at least a score more. I even started spending money to play muds, shelling out both monthly fees and promotional charges to muds like Modus Operandi, Dragon Realms, and Lusternia. And because I know some of you mud enthusiasts out there are wondering, I did have a run at all of the Squidsoft games: Star Conquest, Galaxy Web, and Fortharlin. I even spent far too much time on Miriani—and no, I won’t link to that horrible twink of a game.

                But beyond the hundreds—possibly thousands—of dollars I spent mudding, the more detrimental cost came in the form of the literally thousands of hours I spent glued to my computer desperately trying to reach that next level, finish that elusive quest, or farm excessive amounts of gold and loot. I pretended to be sick from school and work so I could put in extra time on gaming. I stayed up playing until 3 or 4 in the morning, then honestly wondered why I could not stay awake in classes the next day. Instead of socializing with my peers—the people I worked and went to school with—I made virtual friends online. On New Year’s Eve, 2000, I rang in the new year with a handful of friends on a custom-built mud they had designed for just that purpose. Nobody invited me to post-high-school graduation parties; after the ceremony I went straight home and sat sadly in my basement, wishing I had made some real friends. But by that point I was well and truly hooked, and my addiction—for that’s what it was—persisted all the way through college. It followed me into my post-college work; it followed me to Hawaii, to Texas, and—finally—to Minnesota.

                I can only guess why mudding had such a profound draw on me, but any reason I give sounds more like a hollow excuse in retrospect. I suppose what it really comes down to is that I wanted to escape into a place where I could be powerful beyond what I could ever hope to accomplish in real life. In the real world I was a pudgy, socially awkward blind teen-ager who struggled with image and self-confidence, but online I was a swashbuckling warrior, a daring rogue, or a powerful mage, and no one ever needed to know that I was blind or a little heavy around the gut. Instead of facing my fears about blindness and getting involved in school and the community, I patrolled the streets of Lithmore as a reeve and defended the realm from murderers and thieves. People do this all the time with video games, and I can understand why. After a long, difficult day it’s sometimes fun to get lost in mindless entertainment. For some people it’s an episode of Jersey Shore; for others it’s a few games of Major League Baseball 2K11 on Xbox. But with muds, the game never ends. There is always that next goal waiting just around the corner for a dedicated player to come and attain it.

                I played my last text-based multi-user game on December 20, 2010, and I have no idea why. I had tried to quit before; I made it as far as a month during the Summer of 2009, and every day was a challenge. I would be reading a book or playing my guitar, and I would suddenly be overcome with an overwhelming desire to play something—anything—so long as it was a mud. In the end I rationalized my return to text-based gaming as a step toward moderation—a rationalization that lasted all of a week. It wasn’t long before I was back at it again, spending 12 to 16 hours in a single weekend in front of the computer. But this past Christmas vacation, a time I eagerly anticipated for the comparatively huge span it would afford me to mud, something weird happened. Before I knew it January 2 was upon me. I hadn’t mudded in 13 days, and I wasn’t bothered by it in the slightest. In fact, I was surprised, looking back on those two weeks, that so much time had passed.

                It hasn’t been as easy over the past few months as it was during those first two weeks. To tell the truth, the whole reason I’m writing this post today is because I’m fighting the persistent urge to log back onto Discworld or check the latest progress on God Wars. Even as I write, I am filled with nostalgia for those worlds of fantasy and imagination I no longer visit. But I know I can’t go back there. Just as in the past, it would start simply enough—an hour here or there—but before long I know I would spiral back down into my old habits.

                When I look at the above paragraph, I can’t help but think it comes across as a bit dramatic. I haven’t ever struggled with chemical addictions—drugs, alcohol, cigarettes—and I haven’t had to face down habits such as gambling that could destroy everything around me. Instead, I traded half my life—14 years—for gold and experience that amounted to nothing more than stats on a server, and I won’t ever get those 14 years back. I never hurt my body, but I did hurt myself, squandering my potential and talent on computer-generated orcs and meaningless collections of numbers rather than using it to better myself and the world around me.

                So why program games now? Why spend my free time creating virtual fantasies? I suppose it’s for that escape, that temporary journey to a place where each of us can forget about the world for a time and just dream. At the same time, though, I do it for the process. I love the thinking, the imagining, and the problem-solving that it takes to create something. I love knowing that I have the power to shape the world with the strength of my mind, and I love being the architect of my own imagination. I love that instead of following, I’m leading—even if I’m only leading myself.

                So I’ll keep struggling against my old habits. I’ll keep fighting the urges to slip back into the placid waters of inactivity. I’ll keep pushing against half a life’s worth of lost opportunities even though I know it won’t be easy. I’ve invested too much time and energy into this change, and I like the person I’ve since become. If spending time with this new me requires me to give up my lazy past, then I will happily pay that price.

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.

Awesome Day!

                Today was a wet and rainy day, which made it perfect for sitting on the couch and working on the computer. Combine that with the fact that I’ve been having a bit of a productivity drought this week, and I was raring to go.

                My focus for all of today has been menus, specifically those found between rounds, at the end of fights, and off some sort of menu I’ll design which lets you see various things about your character. I have designed a system which tracks everything from punches thrown to the number of head shots landed to the number of times your player dodges each direction. A fringe benefit of this tracking system is that it gives a convenient means of holding up the action during rounds. The primary reason I designed it, however, is so that I can use the data to track trophy progress.

In the very near future I will be able to award the player for landing a certain number of body blows (we might call that one “guts and glory:). I could do likewise for any one of a number of different stat-based accomplishments: number of knockouts, overall punch accuracy, number of blocks versus dodges, and many others.

                As I work through all of this, I’m still amazed sometimes at how new I am to the whole process. Today, on more than one occasion, I found myself banging my head against a problem for as much as an hour, only to discover that the problem was caused by something simple like a missing parenthesis or an improperly assigned variable. The nice thing is that these will hopefully be mistakes I won’t make as often in the future, but when they happen, they’re annoying.

                With all the mistakes, though, there have also been some really awesome moments. As part of my newness to Python, I’ve been spending quite a lot of time writing code then going back and refactoring it. I noticed today, though, that elegant code is becoming easier to write and conceive, and I’m finding that better methods come to me more often than the standard, crappy, verbose ones of just a week ago. It is really satisfying to write a large chunk of code, run your program, and have the new code seamlessly integrate with absolutely no errors.

                I would like to flesh out a decision model in the next few days, but I’m so ready for an alpha release at this point that I may just program the rest of the test opponent and save the decision for after I start getting some feedback from my testers. But the decision method is a post for another day. In the meantime, I’m close. I’m really, really close.