Tag Archives: development

Sparkle, Change log for July 29, 2012

It hasn’t been the most productive week, unfortunately. Monday and Tuesday were a real pain in the neck, and then Wednesday through today were a literal pain in the head, the gut, and just about everywhere else. Let me tell you: when you have a bad case of the flu–or whatever this was–coding is the last thing you feel like doing. Nevertheless, I made some progress today, so you’ll see what came about from two weeks’ worth of coding.

On an unrelated note, the sounds in this current concept are crap right now. Either that, or they’re borrowed from various other games I have lying around my hard drive. At some point, I’ll post a demo so you all can hear for yourselves, but in the meantime, I’d love for anyone interested in sound design to drop me a line. I’ll also eventually be looking for monster voices, so feel free to practice your goblin giggles in your spare time.

And now, the changelog:

  • 9:39 PM 7/29/2012 Cleaned up the collectible code to make it easier to add in new collectibles and items.
  • 8:50 PM 7/29/2012 Added in food. Need to make it transfer to the player’s inventory.
  • 10:21 PM 7/22/2012 Added skeleton keys to the list of available items.
  • 12:46 PM 7/22/2012 Made it so that the player’s carry weight is increased when he picks something up.
  • 12:31 PM 7/22/2012 Built in a trophy class, put one on the board.
  • 12:24 PM 7/22/2012 Made it so that the screen reader speaks the name of the item you’re trying to pick up.
  • 12:10 AM 7/22/2012 Created item sounds so that they have slightly different pitches. This way individual items are easier to hear and don’t blend together.
  • 10:58 PM 7/21/2012 Implemented collectible items on the ground. There is a gold pile in the level which you can pick up with z. (Z is my debug key.) Let me know if you have to stand too close to the gold to pick it up.

Sparkle, Change log for July 15, 2012

More behind the scenes work this week. I made a second character and had him walk around a bit, and I added in a few methods that will be useful in creating and modifying levels, but most of my time this week has been spent elsewhere, as the time stamps sadly show. Nevertheless, here’s some progress

  • 6:18 PM 7/15/2012 Pits are now erasable as well.
  • 6:10 PM 7/15/2012 You can now erase walls off the map. Useful for when they’re broken down.
  • 1:33 PM 7/15/2012 Also made it so that on the top floor, the ceiling is really high.
  • 1:31 PM 7/15/2012 Made it so that on a top floor, there is no ladder going up
  • 10:48 PM 7/9/2012 Created the other class that will represent every entity that isn’t a player, added in sound positioning methods for it
  • 9:25 PM 7/9/2012 Polished up the attacks, made a test attack and a test goblin. Nothing but gross sound FX right now, though

Sparkle, Change log for June 29

A lot of behind-the-scenes work has gone on this week, and my progress hasn’t been as quick as I had hoped. This is due in extremely large part to getting ready for the NFB national convention at work as well as the fact that I’m leaving for said convention tomorrow. I’ll be back in a week to pick up my work once more, but for now, here’s this week’s early change log.

  • 10:35 PM 6/29/2012Added in the basis for an attacks system, but it’s not in the game yet, as I just don’t have time.
  • 2:59 PM 6/29/2012 Changed the jump key from control to x to open up control for attacking
  • 1:41 PM 6/29/2012 Adjusted the depths of default pits so you can’t run jump out of them. If you fall into a pit, that’s your bad, and you’re climbing out.
  • Added in a system of momentum so that players can’t just run against a wall to get the benefit of a walking/running jump.
  • 8:26 AM 6/29/2012 Fixed it so that releasing the left shift key stops the player from sprinting
  • 11:13 PM 6/28/2012 Took out the instant stop for colliding with a wall. Need to figure out an effective way to let people know they’re above a wall and able to move forward. As it stands now, the best method is to run to the base of a wall and jump straight up. That’s not what I had in mind.
  • 10:36 PM 6/24/2012 Widened the pits back out to 5 steps. It’s impossible to stand jump over them, barely possible to walk jump across them, and an absolute breeze to run jump across them.
  • 10:28 PM 6/24/2012 Fixed a bug that was pulling the player out of a jump way too early, but now his jumps soar as on the wings of eagles. Please help balance this.
  • 9:27 PM 6/24/2012 And we have running. Hold down left shift to accomplish it. Like so much else, this needs to be balanced.
  • 10:06 AM 6/24/2012 Put a guard into the vertical collision method so that you can’t jump out of the top of the level
  • 9:18 AM 6/24/2012 Brought the level of the ceiling way down so that it doesn’t take a full minute to climb from one chamber to the next
  • 11:28 PM 6/23/2012 Fixed a bug in jumping that allowed the player to jump while in the air

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 …

The Great Soul-Searching Odyssey, Part II

When I was much younger, I received Mike Tyson’s Punch-Out as a birthday present. (It was the same year I got a brand new bike, and I’m sad to say I spent more time with the former than the latter.) My dad read me the manual, and I ran into the other room, glued my nose to the TV screen, and pummeled my way through a whole list of crazy characters as the scrappy—and thoroughly under-sized—Little Mac.

The funny thing about that experience, though, was that no matter how much I squinted and stared, I couldn’t see to play the game to save my life. I could see the shapes of the characters, and I could tell them apart based on their appearances, but I never saw the tells and quirks that have long been a hallmark of the Punch-Out games. I never saw the gem flashes and eye blinks that warned of impending punches, but I learned through careful timing and a whole lot of dodging how to stay on my feet. I once even thoroughly confused mom by hiding under a bean bag chair with the controller while continuing to play the game by sound alone.

Years later, Punch-Out was rereleased for the Nintendo Wii, and I found out that other blind people were able to play the same way. It turns out that on the Wii the game is even more accessible, as many of the opponents’ punch tells are now audible. It’s so playable, in fact, that Karl Belanger once told me he had racked up 136 straight victories. For even more proof, check out videos like this one or this one where Liam Erven drops two opponents in fine style.

Flash forward a few years to the beta release of BGT. I picked up the language, started mucking about with various functions, and thought it might be an interesting test of my newfound skill to try making an audio only version of Punch-Out. When I made the switch to Python, I took the concept and code with me, figuring that it would still be a fine first project. I figured that the game could be a gentle introduction to programming, and it would give me something more substantial to release than Guess the Number or another Space Invaders clone.

And herein lies the irony. Here I am, finally gaining the ability to design the games I’ve always dreamed of, and I’m spending my time porting a game to audio that’s already perfectly playable by both the blind and sighted alike. The folks at Nintendo spent far more time and money on their product than I ever will, and they produced it with richer sound, more features, and an overall better design.

The question I’ve been asking myself as I struggled with the keyboard handler and pyHook is whether this boxing game is even worth it. If a superior product already exists for a mainstream console, and if that product is already completely playable without sight, what is the point of my designing my version? Sometimes, even though I’ve sunk nearly a year of work into the boxing game already, I’ve contemplated just tossing the game in the closet for a while to work on something else—something far more original and interesting to me.

Two things stop me, though: my sense of duty—the fact that I’ve already promised the game—and this post sent to the Audyssey list back when I announced the game:

Not trying to sound negative here, but it seems that every once in a while
we get some announcement on here about some huge audio game project coming
out. it never materializes and we’re left waiting for this non-existent
game. let’s hope we aren’t disappointed yet again. I learned to take these
announcements with a grain of salt, and so should everyone else. usually
when these announcements are posted, the game is still in the planning
stages and nothing ever comes of it. all this does is give most gamers hope.
I really hope I’m wrong this time and that this game does indeed come out.

I want that author to be wrong, too.

The Great Soul-Searching Odyssey, Part I

March has come and gone, and the blog has lain dormant this whole time. Not cool, Ryan. Not cool. So what have I been up to in that time? It turns out quite a lot, though not as much of it was as productive as I would have liked. Here is my tale.

Remember back in February when I happily wrote about creating my first keyboard handler? (If not, just jump down to the next post. Go ahead. I’ll wait.) It turns out that, despite the awesomeness of said handler, JAWS, the eternal programming thorn in my side, didn’t want to play nice with my code. In particular, it wanted to steal the use of the arrow keys for itself, thus keeping them out of my program. As any of you who have had to put JAWS to sleep in order to play a large chunk of audio games can attest, this is pretty annoying.

I was determined to figure this problem out, however, so I started searching high and low for solutions. The title didn’t lie. This really is an odyssey.

First, I traveled to the land of the great and powerful Pygame developers. Well actually, I just wrote an email to their listserv. Be that as it may, many of them recommended a module called pyHook, a powerful artifact which, according to legend, could freeze the dreaded JAWS in its tracks and prevent it from making off with my arrow keys. But oh man. PyHook is something like 10 points beyond my current skill level, and even its documentation was nearly indecipherable to my n00b mind.

Nevertheless, I threw everything I had against pyHook, aided somewhat by a wise old sage named Alec the Brave.* After what seemed like 10 days—because that’s about how long it was—I managed to throw together a workable solution that allowed me to run my demo side scroller and keep JAWS up and running at the same time. Some of you probably saw my exuberant tweet on the subject.

*Alec’s wisdom is beyond reproach, though his age and sage status have yet to be determined.

Alas, though, my struggles were for naught, for as soon as I began to tweak and debug the program, I realized that pyHook—and here I’ll use the technical phrase—“broke the hell out of” my keyboard module. I’ll spare everyone the gritty details, but suffice it to say that holding down keys was a nightmare, and even though the arrow keys kind of worked, they absolutely didn’t work if something like the control key was held down. All of this meant that if I chose to continue to use pyHook, I would invalidate the eight days I had spent designing and implementing my keyboard handler. What’s more, I had once again run out of ideas on how to proceed.

So what did I learn from the first leg of my journey? I learned that sometimes, the problem I need to solve isn’t as immediate as I think. More than that, I learned that it’s way too easy to get bogged down in side projects that leave me no time for working on important things—like punching a clown in the face. When the day comes that JAWS speech is a deal breaker, I’ll figure out the arrow key problem. Either that, or I’ll have it done for me by someone with a lot more expertise and skill.

Until then, I want to code a game, and that’s just what I intend to do.

Therein, however, lies the next step on my soul search, but since it’s almost midnight, I’ll have to save it for another day.

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.

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.

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?