Tag Archives: status

Sparkle, the first Change Log

For those of you I’ve spoken with personally, I’ve made no secret of the fact that what I’d really, really like to build is a side-scrolling version of Michael Feir’s 2002 board game Sparkle.

“Oh God! Another side-scroller?”

Shut up, random peanut gallery quotation! Yes—another side-scroller—but one the likes of which has never been seen in the blind gaming community.

For those who have never read the Sparkle rules before, here is the introductory passage:

In this game, one to four players must compete against goblins to recover as many trophies as possible from a magical complex comprised of six stacked levels. In addition to goblins, they must contend with ghosts, monsters, and special foes. If players let their opposition accomplish too much, the judgment scale will tip over and things will become even harder for the players. However, players may also cause the judgment scale to tip in their favor which will give them a shared advantage. The game ends when all six levels have been cleared of trophies and special foes, or when all adventurers have been killed.

You see that part that says “one to four?” That means multi-player—a multi-player side-scroller. Where are you now, random peanut gallery quotation? (For those of you who are interested in reading the full, 83-page document in its entirety , you can download the sparkle rules here.)

In my spare time, amongst the work I’ve been doing on the new boxing game, I’ve finally started work on Sparkle, and I’ve been having tons of fun putting it together. Michael and I are working together to make this the kind of game that both of us have wanted for years. We’ll have to change a few rules to move from turn-based play to continuous play, but overall the framework is already well established. And the best part? Michael asked in the original design document that any attempt to code Sparkle be released to the general public for free. Because my main reason for programming this game is because I want to play it, I am happy to honor that request.

In order to keep everyone updated on the progress on Sparkle and other titles, I’m switching up my methodology a little bit. Instead of sending out updates in the form of my customary, beautifully written prose—ha!—I’m going to post copies of the change logs I’m already writing for Michael and the other testers. This means that it will be quicker for me to post updates, and you all will get to see regular progress reports instead of having to wait two months between blog posts.

So without further ado, here’s the first change log:

  • 1:42 PM 6/23/2012 If you are rising or falling, and you encounter a vertical surface such as a ladder, wall, or pit wall, you won’t hear the climbing sound
  • 1:36 PM 6/23/2012 If you crash into a wall while jumping, you fall down. Awww.
  • 12:57 PM 6/23/2012 Made it so that you can climb the ladders and climb them quickly. need a better ladder climbing sound, though.
  • 12:14 PM 6/23/2012 drew in the ladders on the sides of the stories, will need to tweek this some when the top and bottom floors are ready
  • 12:06 AM 6/22/2012 added in the ability to jump by holding left control to charge, releasing to jump
  • narrowed pits from 7 to 3 so that a fully charged walking jump can cross them but a standing jump can’t
  • increased the depth of pits so that players can’t walk jump out of them, may increase it further so that players can’t run jump out of them either
  • 11:15 PM 6/21/2012 Added in a solid_surfaces array and a check_solid_surfaces method to make it easier to tell when a player/monster is standing on something it can jump off of
  • 8:46 PM 6/17/2012 Changed the top of pits and the bottom of walls to be a different surface type so people can’t jump off the sides of pits and walls
  • 8:34 PM 6/17/2012 Made it so that players couldn’t walk and climb at the same time
  • 2:58 PM 6/17/2012 Built in falling distances. Any fall from greater than 8 feet will hurt. May need to be balanced.
  • 1:14 PM 6/17/2012 The player can officially fall. I updated the falling speed to 50, though this may need to change depending on how it feels.
  • 12:39 PM 6/17/2012 Put a debug check in to insure that people can’t make pits too deep.
  • 12:32 PM 6/17/2012 Changed the literal values for the floor into an actual floor_level variable. This makes it so that people can create complexes of different heights.
  • 10:06 PM 6/13/2012 made it so that the game won’t crash if the player climbs down to the bottom of a standard pit
  • 9:59 PM 6/13/2012 Widened the pits and walls. This may need to be fixed when jumping and running come in.
  • 9:55 PM 6/13/2012 climbing is partially implemented. It is possible to climb up and down walls and pits, though the game still breaks if you climb off the bottom of the board. The player also can’t fall yet, so climbing is kind of a formality at present.
  • 10:36 PM 6/11/2012 made everything below the floor into impassible terrain. this should help with climbing and falling
  • 10:23 PM 6/11/2012 implemented the add_pit method in the story class, placed one of each type of pit in the test floor
  • 9:30 PM 6/11/2012 implemented standard, bottomless, and fire pit classes, placed the appropriate sounds in the folder
  • 8:40 PM 6/11/2012 changed the panning of buildings so that walls you were standing far above weren’t extremely quiet

The Great Soul-Searching Odyssey, Part III–Rebirth

It’s been quite a while since I went on my sojourn of soul-searching, and I’m happy to say I have finally come to a few conclusions. I’m also happy to say that while I’ve been soul searching, I haven’t been idle. I’ll put that information out in a forthcoming blog post, but for now, let’s finish this odyssey.

First thing’s first. How’s that boxing game coming along?

It is, and it isn’t.

I’m going to finish the boxing game; in fact, I’m still working on it, but it’s going to have very little to do with Mike Tyson’s Punch-Out. Instead, it will make use of a new, revolutionary style of interaction that’s going to make the game actually worth playing. Instead of standing in one place, dodging back and forth, and throwing random punches, you’ll actually be able to circle the opponent, run around the ring, knock the opponent against the ropes, etc. What’s more, the framework for the boxing game won’t be just for boxing, but instead will have myriad possibilities including fighters and adventure games. And–oh yeah–I’m building it from the start to be multi-player.

Also, when I say “I’m building,” I mean that I’m actually working on the project right now–well not at this exact moment in time, but you get the picture. Currently, it’s possible to navigate the arena in true, 3D-style, approach the enemy, and pick up loose items (that last part isn’t for boxing). The project is making progress, and it has been fun to watch it grow. The boxing game/whatever it becomes isn’t the only thing I’m working on, however, and thus we come to my second conclusion.

I have wanted to design games for as long as I can remember, and once I realized I had the power to do so through coding, I turned game design into a part-time hobby. Just as I was picking up the hobby, however, my wife and I fell on hard times financially as a result of the cost of moving from Texas to Minnesota. As a way of helping to make ends meet, I attempted to approach Grey Matter Productions as a money-making venture. There were two problems with this approach, though. First, I knew squat about programming when I first started, thus making the likelihood of turning out a playable game right away infinitesimally small. Second, I was already working a more-than-full-time job, and the prospect of coming home and putting in another few hours of work at the end of the day was extremely daunting. You can imagine how much I got accomplished.

Thankfully, our finances have stabilized, and I have been able to treat Grey Matter Productions and game development in general as the hobbies they were intended to be. Interestingly enough, this has actually sped up development quite a bit, as I’m able to enjoy coding for the sheer sake of coding rather than working on it out of obligation.

Since what I’m doing is a hobby first and foremost, I’ve decided to treat it as such. This means that, from time to time, I may work on other projects as the interest strikes me or to avoid burn-out on a particular game. In fact, this has already come in handy when trying to break through a particularly tough road block in boxing; by taking my mind off of the current difficulty, I was able to stumble on a solution in a round-about way. I’m happier about coding than I have been in a long time, and I’ve made more progress in the past month than at any other time since I began this venture.

For those of you wanting a boxing game, you’ll get it, and when you do, it will be better-designed, more intense, and more feature-rich than its original incarnation. There’s also the upshot that I’ll like it more and thus will be more inclined to work on it. At the same time, however, you may have to wait a bit longer for it. That doesn’t mean I won’t be working, but it does mean that I’ll likely be working on more than one project at once.

It will all be worth it, though. Just you wait and see …

Downs and Ups

I looked at the website today as Randi and I were searching for the renewal email, and it occurred to me that I haven’t posted an update in over a month. In fact, it has been closer to two months since I posted anything, and as of my last writing, I was still hard at work on boxing. I think the biggest reason for my absence has been that while a lot has happened, not much has been accomplished. Let me try to explain.

My last post was full of optimism about the coming break and the progress I would make on the boxing game. As soon as school finished for the year, however, I managed to contract a really nasty piece of malware, and I found myself having to reformat my computer. As I was upgrading from Windows XP to Windows 7, however, I neglected the fact that the new install didn’t wipe out the old one, but rather installed alongside and throughout it. Thus, I wound up with a tangled amalgamation of two operating systems with a virus lying dormant somewhere in the ruins of the Windows XP side.

No problem, I thought. I’ll just reformat again.

This time, the reformat and reinstall went off without a hitch, and I figured I was Scott free. Side note: I bet there is totally some dude out there named Scott Freeh, and he probably gets a lot of grief from people. Poor guy. Anyhow, I set up Carbonite to start restoring my files, but a mislabeled checkbox caused the program to start dumping the entire backed-up contents of my old format into my pristine new one. This meant that I had directories for Windows 7 that were bare and desolate, and I had jam-packed directories that followed the Windows XP folder structure, all of which were hopelessly entangled once again. Because several gigs had been dumped into my pristine format before I realized the error—that’s what I get for restoring overnight—there was no way to quickly fix the problem.

You can probably guess what I ended up having to do yet again.

Amongst my 3 reformats were all the things that ordinarily occur throughout the holiday season: traveling, dinners, spending time with family, etc. As a result, New Year’s came and went, and I hadn’t written a single line of code. I ended up going back to work on January 2 having accomplished absolutely nothing during the Christmas break.

And then came the coding craziness. I finally realized, after banging my head against the problem for some time, that there was no immediately plausible way to carry out key commands that utilized multiple key presses. For example, holding up arrow and pressing a could not throw a left hook to the head using my current library. So I needed to find a new library—one that would allow me to press multiple keys simultaneously.

First, I tried looking for python-based solutions to the problem. The only solution I could find, however, was the Pygame library. In talking to other audio game developers, I found very little support for Pygame, with criticisms ranging from speed of execution to a lackluster sound library. When I brought up Sound RTS as an example of a great game that just happened to be written in Pygame, it was pointed out to me—accurately, I might add—that even it suffers from very slight execution lag on things like key presses.

So, scared off by the boogie monster of latency, I started looking at BGT, the audio game development toolkit written by Philip Bennefall of Blastbay Studios. Because the core components of BGT are written in C++, execution of almost anything is incredibly speedy. Another feather in its cap is the fact that Philip is an INCREDIBLY NICE GUY! I cannot stress that last point enough.

However, I soon discovered two problems with using BGT, neither of which had anything to do with the language itself. The first of these was the fact that I had already spent a year learning to program in Python, and I was loathe to throw away all of that practice and knowledge in favor of a different language. The second was that I had incredible difficulty switching from a Python mindset to a BGT one, and as almost everyone who has ever rerolled their character and become a newbie again will tell you, starting over sucks.

In order to reconcile the conflict in my head—Python versus anything else, speed of execution versus speed of development—I did what I should have done a long time ago. I signed up for the Pygame mailing list and started asking questions. I received a number of intriguing answers, but probably the best of them went something like this:

You’re so busy spending all of this time worrying about speed and lag and all of these other things that haven’t come up yet that you haven’t even written a single line of code. Many, many people have written great games in Pygame, and they haven’t run up against a speed barrier. So program something—anything—and if you start having problems with speed, there are work-arounds for that.

When I decided to adopt this mindset, it opened up a whole new world of possibility to me. Instead of seeing potential difficulties as obstacles, I started seeing them as barriers to be broken down. Instead of looking at things through a lens of negativity, I started finding more positives. So what if Sound RTS has a tenth-of-a-second lag on key presses. It’s not like that style of game requires lightning reflexes anyhow. And I didn’t even notice the lag until someone pointed out to me, so what did I care? It’s still a great game.

But I didn’t want that lag, because the kind of games I’d like to develop will require lightning reflexes. So I started looking into why it existed in the first place, and almost immediately, I found the answer. It turns out the chief Python critic on the Audyssey list was right, though it chaps my hide to admit it. The sound support for Pygame isn’t the greatest, and when used in a certain way, it can create all sorts of slowdown in programs to the point that, if you make the sound buffer size too large, it can take over a second to modify any currently playing sounds. Huge problem, right?

Well no. If the Pygame sound module slows things down too much, don’t use it. Problem solved! Seriously, it’s that simple!

And just like that, I’m back in business. I’m using the Pygame keyboard module to handle all of my key presses, and I’m stoked about the things it can do:

  • It keeps track of each key press that the user generates, and it gives the program the opportunity to act on these. If, when looking through the key presses, the program finds an “up” in the list, it can run through its analyses and decide to make the player jump.
  • It has a key_pressed function which allows the program to check what keys are held down. If, while walking across a level, the player holds down the control key, the get_pressed function will see this and make the player run.
  • It tracks when players release keys, and it can use this information to call additional events. If, for example, I wanted to program a laser gun that charged itself up as long as the player held down the control key, then fired when the control key was released, I could do that!

As for the sound library, I just switched back to using sound_lib, the library that’s served me well through both Block Party and boxing. It has all of the functionality I need to program with none of the lag, and if I need it to do more, I can tweak the programming myself.

With all of this in place, I have one last hurdle to overcome, and that’s learning to write comfortably in Pygame. I’ve made a car engine that revs up and fades as you press the up and down arrow keys and steers from side to side as you press left and right. I’m in the process of making a character that walks from left to right and back when you press the left and right arrows. These things still don’t feel fluid to me, though, and only time and experience will change that.

What does this mean in terms of game development? Sadly, it means it’s going to take a little while to get things back off the ground and headed in the right direction. More importantly, however, it means that game development is still progressing. Those of you following the twitter feed will note that activity has started to pick back up as I run Pygame through its paces. Things will get moving again, but they may take a bit longer than any of us would like. I’m not out of the race, though. I can promise you that.


                I made a fair bit of progress on the boxing game today and implemented a major change that should make for a better built program. In short: I switched opponent behavior from a threaded timer-based system over too one which uses the WX Timer object. In long:

                When I first started designing the game, I built a system which queued up all of a round’s behaviors at one time. Each of the punches, taunts, and unblocks basically received their own alarm, and when that alarm went off, the event attached to it was triggered. While the program ran smoothly  enough, it always gave me a huge number of trace backs—or errors—every time I prematurely shut it down. Each of the separate alarms was known as a thread, and when the program was closed, any threads that hadn’t yet been executed were cut, resulting in an error message for each one. I’m not certain if this really did anything bad, but it sure looked disconcerting when it happened.

                Partially because of this, I switched the program over to a new system today. Using a module called WX, I built in support for a single recurring timer that will handle all of my event management rather than placing the responsibility on dozens—sometimes hundreds—of separate timers. This single timer runs every tenth of a second, and when it runs it makes various checks to determine whether it should throw a punch, taunt the player, adjust fatigue and health, end the round, and a whole host of other functions.

                The second benefit to this new system is that it allows for on-the-fly changes to be made, including the aforementioned behavior system that people asked for. Because all behaviors aren’t laid out at the beginning of the round, they can be changed as needed.

                In order to really test things, though, I need to go back to the opponent creator and start building in support for the new system. In fact, I think I’ll start that now.


                I guess I always knew somewhere deep down that there were going to be down sides to programming, but of late they’ve been cropping up in some very unexpected places. I expected to have to face some of the legendary heckling and complaining that almost all developers have encountered, but the community has been blessedly understanding and kind about the whole thing.

                Perhaps I’d better back up a bit here. A few weeks ago I received an email on the Audyssey list from a user who told me that Block Party wouldn’t run on his system and that he was getting error X. Having no idea what error X involved, I put out feelers, and I was told to put a specific line of code into the main module that would fix everything. I placed the line of code where I was told and uploaded the new executable to the site.

                I then went back to work on the boxing game, building in support for multiple punch types and perfecting existing sounds, only to discover that my current keyboard code didn’t support things like holding down keys. If I wanted to press up and A at the same time to throw a left hook, I could, but I couldn’t hold up and tap A at some future point and achieve the same result. Some people might argue that it makes no difference, but for some reason, the lack of being able to hold keys feels awkward to me, and I’d like to be able to fix it.

                So I started working on a solution. I went out and started researching Pygame, a Python library specifically designed for game development. (Some of you may recognize Pygame as the library used to code Sound RTS.) I figured if I imported the Pygame keyboard module, I could build in support for a lot of the keyboard-based stuff I really wanted. There’s also the added bonus that Pygame supports mice and joysticks as well. But just as I started my research, life started happening.

                First came the emails from the Audyssey list telling me that the new version of Block Party wouldn’t run on 64-bit Windows 7. I have to pause here to point out that the emails I have received thus far have been extremely cordial, and I cannot stress enough how much I appreciate that. After the emails, though, came a mountain of work at my job, and after that came some previously-made engagements which have taken up a significant chunk of my time.

                Today I finally had time to sit down and research the problem, and I came to the conclusion that I needed to roll back to the previous version and find another solution to the problem, only to receive more kind emails from people telling me that They—the emails’ authors—could now happily run Block Party’s latest version on their computers. Argh! Now I have to trouble-shoot Windows 7 64-bit!

                The most interesting and awesome thing about this whole ordeal is the response I have received from the blind gaming community. As I wrote earlier, I have received no negative emails about Block Party’s refusal to play nice with everyone’s computers. Especially given some of the epic flare-ups which have previously occurred on the Audyssey list, I was expecting to have to dawn my ceramic suit and dive for cover to escape the flaming. Instead, everyone has been very understanding and patient with me as I research and learn in an attempt to solve the problem.

                Which is probably why I feel so bad.

                You all have been waiting for months for the boxing game—almost as long as I have. I have been giving out teasers and snippets from time to time and writing about my progress in various forums, but real, tangible results of this project have not been forthcoming. I know deep down that there will be setbacks; I’ve written about them in a previous post or two, but I hate that they’re occurring at all. More than anything I want to finish this game and release it to the general public, but for some reason things just keep coming up. Maybe this is all a bit melodramatic, and maybe I’m just on edge after the whole Qwitter thing, but I keep feeling like there’s a clock hanging over my head, and when it strikes, there goes my credibility. The funny thing is: it’s not you; it’s me.

                Holy crap. I have to stop writing now before something even more cheesy comes out of my keyboard: “maybe we should just be friends.”

                Anyhow, thanks for letting me get that off my chest, and thanks for being so awesome about the whole thing. I promise I’ll make the end result worth it, and we’ll all have a lot of fun.

A Worthy Challenge

                When you start out programming, people tell you it’s a good idea to start with something small. It’s why almost all program tutorials start you out with printing “Hello world!” to the screen. In the case of games they tell you to produce Guess the Number or a Space Invaders clone or something equally unsatisfying from a gamer’s prospective. But in spite of this good advice, the starry-eyed gamers want to produce something exciting, something revolutionary, and they either wind up failing or producing something ugly. I’m a big believer that you only truly fail when you give up, so I don’t believe I have failed to produce a great game. I do think, though, that the current incarnation of boxing is pretty unattractive.

                A big part of the reason behind this ugliness is that I started with an extremely limited skillset. I could only conceptualize how to produce the kinds of things I wanted with some very limited tools, and my code and design reflect this fact. It’s why I’ve been writing on the Twitter feed recently about how I’ve been going back through all of my modules and stripping out/refactoring a lot of the detritus that has collected there.

                But as my knowledge has been evolving, so has my vision for the direction I’d like to take the boxing game in, spurred on in no small part thanks to some bona-fide geniuses on the Python tutor list. When I look at their code examples, their suggestions for different work-arounds, their ideas for alternative—and better implementation—I realize that I’ve only been scratching the surface of what this game is truly capable of. I don’t, for example, have to stop at four basic punches, especially when boxing offers a whole host of new ones. I don’t have to limit the game to blocking and not blocking when I can easily build in slipping, bobbing and weaving, stepping in, and so much more. Did you know that a classic boxing combination is to throw an uppercut with the power hand, then follow it up with a devastating hook with the other hand? Apparently the first punch lifts the jaw into prime position, and the follow-up punch lays the opponent out. I didn’t know that before yesterday, but now that I do, I want to build it in! Now that I have more tools at my disposal, I can do that—and what’s more, I can do it with relative ease.

                This probably comes as a bit of a disappointment to people who were hoping I would release the game yesterday, but I promise that the mechanic change will make the game a lot more fun for all involved. Instead of just mashing a particular button repeatedly and getting away with it, players will have to make strategic decisions and play off of their opponents. They’ll have to learn which punches to lead with and when to throw a proper combination, and the opponent will be learning right back. If they throw the old one-two too many times, the opponent will start to anticipate it.

                While I think future players will really appreciate these changes, I’m also making them for my own sake. Nothing is more frustrating than spending lots of time on a project that is no longer of interest, and I don’t want to become frustrated with the boxing game. I want this to be an exciting journey for all involved, but since I’m steering the ship right now, I need to make sure I don’t fall asleep at the wheel. Thankfully, we’re bound for Tahiti.

                And I’d better stop with the nautical metaphors.

                Oh hey—random thing: Did you know that coffee gives you super powers? No, really. I use it all the time when coding to help me stay strong. In fact, I might go have some right now!

Rewriting the Future

                One of the biggest stumbling blocks I tripped over when the boxing game came to a screeching halt was the opponent creator. I know people are really excited about that feature; I am too. When I tried to conceptualize a system, though, I found that it kept getting progressively bigger and uglier, and after a while I didn’t even want to deal with it.

                The problem, I think, lay in the design of the program. When I conceptualized the opponent creator, I had a continuous timeline in mind. Users would jump into the timeline, place their events, tweak everything so that it was just the way they wanted, save the character, and share it with whomever they chose. I quickly found, though, that people didn’t like this approach. They wanted to be able to create their own combos, build in AI, and perform lots of other functions that I had never even considered. Many of these ideas were good ones, and I thought it would be fun to implement them. In trying to do so atop my existing code, however, I created a Frankenstein mess that quickly became untenable. I had built the system for single events, not combos or AI or anything of the sort, so the system couldn’t easily handle the new suggestions.

                So I’ve decided to do a bit of a rewrite, and it’s going to require messing with some of the existing engine. Here’s what I’m changing and what you can expect.

                The current setup provides for two opponent conditions: blocking and not blocking. (Eloquent, I know.) When the opponent is blocking, you can’t hit him; when he’s not, you can. Sounds complicated, right? Well … kind of, yeah. One of the things people asked for was the ability to create different opponent behaviors depending on how well or poorly the opponent is doing. If the opponent is winning, perhaps he’d like to go in for the knockout. If he’s losing, he might put up his guard, and therein lies the problem. If the opponent blocking means he can’t be hit, then when the opponent goes on the defense, he is nearly invincible. Using the current system, the only way to avoid this problem would be to have the opponent come out from behind his guard to throw punches from time to time, a behavior that would be at odds with his defensive nature.

                In the current system there are three ways to land a punch on an opponent:

  1. Hit him while he’s swinging at you.
  2. Hit him after you dodge one of his punches.
  3. Wait for him to drop his block, then sneak in a few punches. (more on this later)

All of the above factors conspire to create a game where the player is completely dependent on the opponent for his or her openings, which ostensibly makes this game a rich, detailed Bop It. Not cool!

                The other issue that currently exists is one of stamina. Like the original Punch-Out! from which this game draws much of its inspiration, I had programmed the player so that he would lose fatigue for punching at a blocking opponent, but he would not lose any fatigue for landing a successful hit. Why? When I look back on this setup, it doesn’t really make sense. You can get just as tired hammering nails as you can from swinging a hammer at nothing, so why do you not lose stamina for successfully landing a punch? If I wanted to fix blocking, I realized, I needed to fix this too.

                After banging my head against these issues for a while, I finally decided that the root of the problem lay in the opponents’ ability to become instantly invincible. If the opponent couldn’t block every single punch thrown at him, I reasoned, he could start adapting to different emotional situations without the unfair advantage of becoming a walking tank. With this in mind, and drawing inspiration from many of the mainstream games of today, I’ve started working on high and low blocks as an alternative. If an opponent is blocking high, he can still be hit low. The reverse is true if the opponent is blocking low. This will enable players and opponents alike to adjust play styles depending on how aggressive or defensive they are at any given moment.

                But then comes the issue of stamina. Since it’s now possible to land many more punches, there needs to be a check in place that will keep the player from simply unleashing a torrent of key presses and battering the opponent into the ground. Thus, the new system will subtract stamina for both successful and unsuccessful hits, meaning that it won’t be advantageous to just slug away …

                Or will it?

                That’s all going to depend on the third major facet currently in the planning stages, statistics. Perhaps you’d like to be a bruiser with a take no prisoners attitude. Or maybe you’d rather be a calculating, careful fighter, using your mind and your reflexes to solve the sweet science. Perhaps you’re just a glutton for punishment and can’t avoid getting punched in the face to save your life—or at least your career. With customizable stats in place, all of these should be possible.

                My current plan is to have four trainable stats: strength, speed, stamina, and vitality. The player will have the ability to train a few stats at the start of the game, and will gain additional points for participating in fights. This means that if you find yourself getting too tired during fights, you can use your training to improve your stamina in order to stay on your feet longer. If you know the next opponent is going to dish out some serious damage, you might consider dropping a few points into your vitality as a precautionary measure.

                Finally, there’s the opponent creator I mentioned at the top of the post. People want combos, and they want the ability to create situation-based events. I want to give them these things, so here’s what I have in mind.

                Instead of having a timeline to cover the entirety of the match, complete with too much scripting, opponents’ behavior will be based solely on combos. The game will choose from a set list of combos depending on the current situation—offensive, defensive, normal, etc.—and one will be chosen and executed. The nice part of this system is that it can create as much or as little complexity as the creator chooses. If you want to create a completely predictable opponent, only design a few combos for each situation. If you want someone harder to predict, you can design dozens—even hundreds—of combos, and the game will just choose from a larger set. Combine this with the already-existing ability to create punches of random height and side, and you have an extremely flexible system.

                Many of these features are still in the design phase, but I firmly believe that, once implemented, they will combine to create a much richer, more satisfying game with greater replay value. By giving people a more detailed fighting system and a thorough opponent creation utility, I hope I can create something that many of you will be excited to play.

                Before I can make any of this happen, though, I need to look through the old code, find out what needs to be kept and what needs to be scrapped, and make the necessary changes to the underlying infrastructure. It’s going to take a lot of refactoring, a lot of proofreading, and a lot of coding. I know. I’m excited too!

The Art of Improv

                This is just a quick note to let everyone know that the official Grey Matter Productions website is still coming, albeit in a few days instead of … yesterday. Both Randi and I are working a lot at the moment, and since Randi is my head web developer—okay only web developer—we haven’t been able to make the progress we would like. On the other hand, though, we are making money and paying off bills, and that’s never a bad thing.

                In the meantime, thanks to everyone who has downloaded Block Party so far. Your support and kind words mean a lot to both of us. I appreciate the outpouring of kind emails and positive feedback the game has garnered so far, and I’m already hard at work finishing the boxing title as a nice, juicy follow-up.

Thanks for putting up with our duct tape and string. We’ll be putting in a more elegant solution shortly.

An Overdue Update

                I had planned to write a long, whiny-yet-justified post about how life has been so busy these past few weeks, but my being busy has kept me from that. I had thought to write about the Minnesota state government shut-down and the work we at BLIND Inc. have had to do to prepare for it, about the work involved in getting ready for convention, about recording an audio version of a textbook, and about my general lack of programming time, but I decided not to. In fact this post will not contain references to any of those things.

                Woops …

                Instead, let’s talk about something happy; let’s talk about Jawbreaker.

For those of you who own or have owned a Pac-Mate, you may be familiar with Jawbreaker. It’s a grid-based puzzle game that can be made “accessible” by labeling the graphics which make up the playing squares. The problem, though, is that for some reason the Pac-Mate liked to introduce random numbers and elements that you the labeler never implemented, and it liked to introduce random spacing that you the player had trouble understanding. In a game with pieces labeled “1” to “5,” it was rather jarring and off-putting to encounter a “6” or a “0” among the squares. Likewise it was confusing to scroll up and down through the lines and find that column 8 was on the right side of the Braille display on one line and in the middle on the next. More often than not I would simply tap the pieces randomly just to pop a few bubbles and see how high a score I could get, and I used the game mainly to keep myself awake.

Last Sunday, after finishing the bulk of my work, I sat down to the boxing game again, only to discover that the problem I was having trouble with when I had to put the game on hold was far too difficult to solve after over two weeks away from coding. As a result, I decided to tackle a quick, simple project to reactivate my brain cells. That project was programming an interactive Spy vs. Spy comic strip. No. Wait. It wasn’t.

                I had two other reasons for wanting to code Jawbreaker: First, I wanted to play a version that wasn’t all screwed up and barely accessible. Second, and more importantly, I wanted to pick up a project that I had envisioned, conceptualize it through from start to finish, and hammer it out as quickly as possible just because I could. I started working on Jawbreaker last Sunday morning, and as of midnight today, the game is nearly complete. All I have left to do is create a few sounds, implement a starting menu, and build in a high score system. After that I’ll be done.

                Before I can complete those things, however, I’ll be attending the NFB convention from July 2 through 9. As might be expected, the time I’ll be able to spend programming my games will be nearly non-existent, and I own no laptop besides. I had pondered releasing the game, warts and all, before I left, but the thought of throwing an untested project to the wolves and not being there to answer questions or make bug fixes stayed my hand. You will be happy to note, though, that the game will be completed likely within a week of my return. I have two days off when I get home, and I intend to make full use of them.

                And—oh yeah—since the concept, idea, and even the title of the game aren’t mine, I can’t very well charge for Jawbreaker, so after I get back, everyone will have a fun, addictive, and—above all—free game to play.

                See you in a week!