Tag Archives: boxing game

Tangling with Inertia

                I didn’t know it could happen, but it appears it has: I am at a point in my code where I cannot independently think of any way to fix what is wrong with the creator. No matter how often I look through the code, no matter how much tweaking and debugging I do, I am absolutely stuck. I am waiting to hear back from people with much greater experience in Python than I, but in the meantime, I cannot go forward.

                Strictly from a personal standpoint, this doesn’t bother me. I understand that this is just one more hurdle to overcome in the grand scheme of learning to program. But from a development angle, it means I’m not working while I wait for feedback, and since I’m not working, it comes as no surprise that no progress is being made.

                I have pondered the idea of working on secondary projects as many developers do, but I’m not sure if this is a wise idea in my situation. Many of the developers I know design and code for several hours a week, whereas I do this in my spare time after a full day of work. That’s not to prop either practice, but it does mean that if I split the two hours a day I have to code amongst many different projects, the little time I do have will be spread rather thin. Perhaps that’s a good thing, as it will keep me from getting bored or frustrated with a single undertaking. On the other hand, though, it waters down my focus in a time when I have too little focus to give in the first place.

                What would you all do? Would you work on more than one project at once or would you bang your efforts against a particular obstacle until you manage to break through? All opinions welcome!

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.

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.

The Status of the Game

The following is a copy of a message I sent to the Audyssey list earlier today detailing my progress on the game. Reduce, reuse, recycle.

Dark and Willem,

I appreciate the kind words. As I wrote in my previous post, skepticism is warranted. As you both said, though, there is enough here that it’s not just an “I’m planning to do this” type announcement. In fact, here’s exactly what exists at this point:

  • There is an opponent object, and he is able to throw a full range of upper and lower punches from achingly slow to too-fast-to-dodge.
  • There is a player object, and he can throw his four basic punches and an ultra punch. He can dodge and block.
  • Both the player and opponent can be knocked down and can stand up. In the case of the player, this requires some serious button mashing. This also includes a referee who will count the player or opponent out if he is down too long. It also includes the TKO rule: if a fighter is knocked down 3 times in one round, the fight is over.
  • There are methods in place that allow the player to do extra damage depending on how he counters his opponents’ punches.
  • All this being said, it is possible to have a complete fight with the test opponent, provided the fight doesn’t last into the second round.

What I still need to do:

  • Build the framework for stat tracking: I want to display the stats of a given round after it has ended. Right now, though, the code I have in place to do that is ugly as sin and needs to be refactored. I need to pass each round to the fight and eventually pass each fight to the career stats. That’s my mission for today.
  • Build in a record system to keep track of player and opponent wins and losses: If an opponent beats you, and you challenge him to a rematch, his win/loss record will need to reflect that he beat you. Ditto for yours.
  • Finish the code to win/lose a fight: When you win or lose a fight right now, the only thing that happens is that the bell rings. That needs to be changed.
  • Build code so that the player can win/lose by decision
  • Wrap the game in a menu system so that the fight doesn’t start as soon as you launch the game
  • Finish programming the opponents: In most cases this will be a matter of laying out punches. For a few specific opponents, however—the pirate, the cowboy, the creation (more on that soon)—it will require a few extra methods. That will come once I’ve completed the alpha.
  • Finish with sound design: That’s probably my biggest hurdle, and it’s going to take some time. I picked up a Yeti microphone, and I love it, but I’m having trouble getting Sound Forge to recognize it. I suppose I could use Garage Band to record the voices, but I’m not good enough with GB at this point to just bust out the Mac and record those files on the fly. I don’t even know if you can monitor GB for clipping. That, too, will come after the alpha.
  • Design the achievement system: There are stats in place to check for achievements, but nothing is being done with them. I need to come up with specific achievements and start implementing them. That’s another beta-level undertaking.
  • And, of course, there’s the complete lack of documentation that currently exists. As a matter of fact, this is the most I’ve ever written about the game.

As you can see from the above, the blog, and my previous posts, this is all incredibly new. It is progressing, though. I never would have dreamed 4 months ago that I would have a working proto-type of a game. While there is a lot yet to accomplish, especially since I’ll be developing in the evenings opposite my full-time job, completion isn’t that far off.

As always, I’ll keep you posted.