ASCIIboros submission for Global Game Jam 2012

The “theme” for Global Game Jam this year was the Ouroboros, the mythical snake that eats its own tail in an infinite, recursive cycle of death and rebirth.

Ouroboros, the snake that eats its own tail

What a freakin’ cool theme that is. Seriously.

I ended up working solo on an idea that I had. My first thought was to make a platformer where you loop through a single level infinitely as you are chased by the “snake head” that eats the level behind you. Each time through the level, things you do in the last pass through cause some change so that the level, while still recognizable as itself, has gotten more difficult. Next, I thought that rather than make the level more difficult, it could be a puzzle that you’re stuck in until you do the right thing to escape, much like the later castle levels in the original Super Mario Bros.

I had never made a platformer before, but had enough experience in Game Maker that I felt confident I could pull something off. To facilitate rapid solo development, I embraced lo-fi graphics. They’re cheaper and easier to make, and without a team behind me I wouldn’t have much time to do more. My friend Steve Felix from the Cleveland Game Developers meetup stepped in and helped me by producing the run and jump animations, based on my original stick figure. Everything else in the game is all me.

The lo-fi look is a nice homage to the 8-bit era, and lends itself to thinking about low-level computing. You feel closer to the metal when you have fewer bits to make reality out of. This led me to my idea for the core mechanic of the game.

Binary and Source Download Here

Global Game Jam ASCIIboros project page

The Process

Working solo, I had to rely on myself to know what worked, what didn’t, what was a good idea, what wasn’t, how to do it, actually doing it, and knowing when to throw things out. I think I did pretty well overall with this. I got a project done, and everyone at the Cleveland GGJ site who saw it said it was a cool concept.


I first started development in Game Maker HTML5 beta. Hoping I could make the game available to the Web as an HTML5 app, I’d be able to reach more people faster than if the game were a downloadable executable that runs only on Windows.

Unfortunately, Game Maker HTML5 beta proved to be not ready for development work. The project quit building partway into development, and I could not tell why. I didn’t have time to do extensive troubleshooting on this, but it seemed that whatever caused the problem corrupted the project in some way. My sprites had visible corruption artifacts in them, and I had to re-import them from my original source files (thankfully, I had external source files, although had I lost them entirely, they were simple enough that it wouldn’t have been too costly to have to recreate them.)

After failing to resolve the problem after about an hour of figeting, I abandoned GMHTML5 and dropped back to GM8.1… which, it turned out, had the same problem. I was 6 hours in before I got stuck in HTML5, and another 6 to rebuild back to the point where the corruption happened again in GM8.1, so in total I lost about 12 hours of progress, basically wasting all of Friday and the wee hours of Saturday. I almost gave up in despair, but after recovering from the emotional blow, I started over in Game Maker 8.0 and rebuilt everything I’d had by about noon Saturday. There’s no way to directly import entire projects built in Game Maker 8.1 into 8.0, so I had to do a meticulous resource by resource migration, which was time consuming.

Unfortunately, it was also exhausting. After re-doing the same work for the third time, I was dead tired. I didn’t feel tired, but it was only determination and a LOT of caffeine that was keeping me going by this point. I’d worked for about 18 hours straight, and since I’d repeated myself thrice, I’d gotten to a point where it was hard to remember what I’d done and what I still needed to do. Worse, I was so brain-fried that it was very challenging for me to do very simple things, like remember where a button or command was in the developer environment. Because of that, the rest of the time I spent on Saturday was frustrating because things were harder than they should have been, and when something didn’t work right, I’d stare at the problem for far longer than I ordinarily would, trying to see what was right in front of me.

I’d say, throwing out the lost time, I spent about 90% of my development time on the Player — and, unfortunately, this left little time for me to work on the rest of the game. Implemented as a State Machine, the Player required extensive trial/error and debugging to get it working as I wanted it. I am still not entirely satisfied with the jumping behavior, and need to re-work that so that jumps don’t abruptly stop gaining altitude despite holding the jump button down. I had built game objects using the State Machine pattern before, but nothing this complicated. In Game Maker, you can create a Finite State Machine by setting up a different Object to represent each State, defining the behaviors within each state, including what triggers changing from one state to another state. 2-State Machines are common and simple to implement, but my Player consisted of 9 states, and in my sleep deprived state it approached the limit for the amount of complexity I could handle.

I finally finished the Player by 2 or 3AM Sunday morning. By that time, I still hadn’t done any work on the logic switches. Fortunately, these are extremely simple objects, 2-State Machines, and it only took me about 2.5 hours to implement all 10 of them from start to finish, and they required only very minimal debugging when I tested them.

The game was basically finished by 5:30AM on Sunday. Then I went home and slept for 5 hours, woke up around 10AM, and showered. It’s interesting how when I’m really engaged in my work, that I never really stop working on it. I work obsessively past the point of exhaustion. Not only do I not sleep, but even when I do sleep, I’m still working. I woke up at 10AM with a bunch of new ideas that I’ll implement later as I continue to develop the game, as well as a couple of things I had subconsciously noticed needed fixing, and realized while asleep. After I finished with my shower, I headed back to the Game Jam site and fixed everything in about two hours and I’m calling it final at this point (this time for real, for GGJ purposes) although I do plan to continue developing the game further to realize a bit of what I had to throw out in order to get it done in time.

The things I threw out

Originally I wanted to have jumping obstacles, with platforms and doorways connected to the logic switches, such that as you got closer to the correct bit sequence, you would open up parts of the level that you couldn’t get to previously, or closed off parts. As it turned out, there’s no jumping obstacles in the level I built, only jumping to hit switches.

I also had intended to build a succession of levels, starting from easy/simple and moving toward more difficult/complex. In the end, I only had time to do a single level, and in order to get all the game elements into it, I ended up making a fiendishly difficult level. This might even be too difficult as a bonus challenge level for extreme masochists, people who love binary math, and have ASCII codes memorized. I should offer a reward to someone who can beat this level, but I’m not sure there’s a reward high enough to make it worthwhile. Still, I expect somewhere there’s a geek out there who’s hard core enough to take it on.

My analysis of this issue is that the randomization of the switch after reset makes it too unlikely that you’ll be able to perform the necessary operations to get the value of the Byte to match the Clue value. The difficulty issue isn’t inherent to the game, but to the design of the level, and can and will be addressed when I work on the project more. I’ll also have some introductory levels that ramp up in difficulty and introduce gameplay elements in a way that makes the game easier to discover and invites play and experimentation.

I also have a few ideas for variations on my basic logic switches which I had to throw out for lack of time. They’re easy enough to build, but I didn’t have time to design levels with more switches.

I also threw out refactoring along the way, instead choosing to press forward and implement as many features as I could. This ends up being counter-productive in the long term when you have to maintain software, but to crank out a small project against a tight deadline is something that had to be done. Fortunately, I didn’t slow myself down by repeating myself and having to fix bugs in too many places. Still, I definitely could have done the project faster with a little more forethought applied and some timely refactoring. I think it’s difficult to know if your forethought is correct when you’re tackling a new project that is unlike things that you’ve successfully done before, and when that is the situation perhaps it’s best to not plan out your code so much as it is to write something so you can test it early and find out faster if/where/how you’re failing.

Thoughts about the Jam


It was a lot of fun and very rewarding to participate in the Jam. As a co-organizer of the Cleveland event, it was also very rewarding that we were able to pull off a successful event in our first year. We really had no idea if we were going to sell out our 30 tickets or not, but in the end we had a full event. I’m looking forward to seeing everyone’s game.

I believe the correct spirit to bring to Game Jam is “It’s OK to fail.” You don’t have to finish a game to “win” at Game Jam. Don’t get me wrong: Finishing a game is very rewarding, and finishing a GOOD game is immensely rewarding. But that’s not the point of an event like this. Making a game in 48 hours is less about making the best game you can possibly make, and more about compressing all of the experiences that can help you learn how to make your next game better, so you can get better rapidly. You learn more from your failures and mistakes than from your successes. Take risks and experiment and see how far you can take it in 48 hours. You don’t have to come out of it with a great game. Enjoying the experience is the most critical thing, since we tend to repeat things that we enjoy. Learning and enjoying it so that you want to do it again and again and never stop is the best outcome.


Game Jam puts a lot of stress on you. It’s definitely possible to build a game in 48 hours — something most people can’t believe until you show them proof. But even when you’re enjoying yourself, and love doing it, it’s still a grueling experience, akin to running a marathon.

I now believe it’s definitely possible to build a game in 48 hours and not sacrifice sleep. I had to sacrifice sleep in my case only because of the 12 hours I lost due to the project corruption problems that I encountered which forced me to press on and work all night to catch up. I got 3 hours of sleep Saturday morning, after having stayed up over 24 hours straight, and 5 hours Sunday morning.

That takes a toll on a body. I plan to sleep heavily in the afternoon, and detox from caffeine over the next day or two.

A lot of people who participate in Game Jam don’t sleep all weekend, or sleep very little, and that’s hard on you, and is not a good work habit for the long term. While it’s fun to do it once in a while for a special challenge, its not the way we should encourage ourselves to work.

The game industry already presses developers to work a huge amount of hours in order to hit deadlines. Better management is needed to make real-life, everday workloads reasonable and sustainable. Perhaps we shouldn’t encourage bad management by willingly doing this to ourselves and claiming to enjoy it. I’m looking forward to the next time I participate in an event like this (which will be in April at Notacon!) but I’m planning on staying sane and keeping to my sleep requirements.

Leave a Reply