Must’ve been rats!

This past weekend I participated in the Global Game Jam with Chris Logsdon and Paul Ouellette. The theme was “heartbeat”, so we made a stealth game called “Must’ve been rats!” in which you have to search for a briefcase containing a beating heart so you can escape in a heart-powered elevator.

Download here!

Overall I’m pretty satisfied with the way this jam turned out. We had a lot of fun designing the gameplay and systems, and the game is feature complete despite having only one level at the moment. Even after testing and debugging for 48 hours straight I still enjoy playing the game, which feels like an accomplishment of its own. Still, it’s not a game jam if you don’t make some stupid mistakes and learn a few things, so here are my Things That Went Right and Wrong.

What went right


At this point I can’t imagine using anything but Flashpunk for my game jam needs. Paul was able to pick it up fairly quickly, despite the fact that he hadn’t used it at all until a few days before the jam. Chris and I have used it a number of times, and even so we both found new features that we’d never known about. The API feels complete and intuitive, and it seems like there’s a function or class for everything we could ever need.

Systemic design with message passing

We designed our base engine as a set of systems that communicated with each other indirectly through message broadcasting, instead of directly through function calls. This allowed us to focus on programming the rules of the game world instead of specific interactions between different entity types. Even though getting each system working correctly was a challenge, adding new rules and rule responses is quite simple.

Data-driven workflow

We did all of our level design using Ogmo Editor, and as usual it served us well. Since we used a tileset for our levels’ art and a grid for collision and pathfinding, I modified my OgmoWorld utility classes to automatically import each of these types automatically and take advantage of FLAKit‘s live reloading capabilities. These changes will be included when I get around to officially releasing OgmoWorld.

What went wrong

Systemic design with message passing

Yeah, I know this one is in both groups. That’s deliberate.

Despite the fact that message passing is really cool and allows for some interesting emergent interactions, it’s not a good fit for everything. One example of a poor application is updating each enemy with the player’s position. My solution was to broadcast a message that told the player to report back with his position. This was slower and less elegant than searching the world for the player instance, and I wish I had realized that sticking rigidly to message passing was a bad approach.

Preconceived ideas

Chris and I had decided we wanted to make a stealth game before the jam started. Even though we didn’t do any kind of brainstorming beforehand, that decision still limited our ability to be creative with our interpretation of the theme. Fortunately we still managed to stay in scope and get the game to feature-complete, but I still wish we had come into the jam without any plans.


Overall, I’d call this Game jam another success. Make sure you play the game!

Data-driven action scheduling in Flash

One of recent experiments in game development has been to orient my workflow away from code and towards data. When I use Flash, I’ve started using Ogmo Editor to design my levels, XML to handle settings, and Slang to handle game logic whenever possible. As a result, a lot of the code I’ve written recently can be easily reused across projects, and my classes are systemic and steer clear of situation-specific behavior. It’s been quite fulfilling and has done wonders for my iteration time; the focus on data instead of code means that I can take advantage of live-reloading for nearly every aspect of development. It’s not uncommon for me to work for an hour without ever closing my game, as I can simply reload all assets and data with the press of a button.

Today I’ve been working on Humphrey’s Tiny Adventure: Remastered, a post-compo version of my first 48 hour game. There are a number of places in the game where I need to set up events on a timeline, which I’ve done a few times already (see here and here), and each time I used some variation of traversal over a queue of function closures. While this approach worked well enough, it was tedious to set up and a pain to debug, not to mention the fact that it was anything but systemic. The most criticized aspect of the Ludum Dare version of Humphrey was that the intro cutscene was too long, and I agree. I think I knew that even before I released the game, but there was no way I was diving into that code to change it.

For Humphrey: Remastered, I was determined to achieve the same type of event scheduling in a data-driven way. Thanks to Slang, I was able to do just that. Here are the scripts for a scene I’ve been testing that involve two actors; Humphrey and Abe. This won’t be in the finished game, but it’s a good demonstration of the system’s capabilities.

action {
        print "start"
        delay 3

action {
        print "after delay"
        give-cue "humphrey done"
action {
	print "start abe"

action {
	await-cue "humphrey done" {
		print "got cue"

Actions are called sequentially by the actor that the script is attached to. Each action block defines a set of statements that will be run as the events are executed. Calling done moves to the next action, and delay causes the actor to stop executing actions for the given number of seconds.

The give-cue and await-cue functions allow actors to pass messages between each other. In the above example, Humphrey give a cue to tell that he’s finished a set of actions, and Abe, who has been waiting for that cue, executes his final action in response.

There are only a few control functions involved, but so far the system has proven to be very powerful, and more than capable enough for the needs of this project. With the addition of message passing and response, specialized actor classes will be able to define custom behaviors while allowing the system to remain pure.

I’m quite happy with the way this has turned out. It’s fun to experiment with what can be done with Slang even in its current, quite minimal state.



Slang 2.0

I’ve recently been working on Slang, my scripting language for Flash, and yesterday I accidentally rewrote the entire thing. I started out refactoring of the parser, and ended up completely redesigning the way the language is executed.

The biggest internal change is that source must now be compiled before execution. This allows for a performance boost when running scripts multiple times, as the bytecode can be cached. Compiling is still quite fast, though, so it’s just as easy to use Slang in a dynamic way, such as an in-game console.

Another feature in this version is the introduction of Scopes. A Scope is a simple data structure which contains statements and can be executed by the application. Currently, they are used for conditional statements.

if condition {
    print "true!"

ifelse condition {
    print "true!"
} {
    print "false!"

In the future, they will also allow closures and script functions.

With the addition of Scopes, the use of semicolons as artificial separators is no longer necessary, and they have therefore been removed from the language keyword set.

With this release I’ve moved Slang out of FLAKit and into its own repository. You can follow it here.

Experimental Gameplay roundup: Temperature

The list of games made for Experimental Gameplay November/December ’12 is up, and I thought I would give a bit of a mini review for each of them, since I participated this time around.

Hypothermia was my game, so I can’t really review it fairly. Nonetheless, I’m quite happy with the way it turned out, and I would consider it feature-complete, which is always a good goal. The postmortem is here.

Firesweeper has an interesting idea behind it, but I never quite figured it out. You’re supposed to control the spread of a fire by dropping water on a grid of squares, Minesweeper style. I might just be terrible at it, but I couldn’t find a consistent logic behind the fire’s spread or the way that it was counteracted by the water.

5 summers left reminded me a lot of Braid — what I was able to play of it, that is. It’s a puzzle platformer where you interact with the level in different ways depending on the season; for example, the ground is slippery during winter, but enemies are frozen in place. I didn’t get very far in the time I played it; it’s quite hard, and there’s no checkpoint or life counter system, which means starting the entire level over each time you die. I think it has promise, although I would like to see the limit on season changes removed.

Too hot too cold is another puzzle platformer that plays with switching back and forth between temperatures, but you change the state of the character instead of changing the world. Lighting yourself on fire allows you to burn through crates, and freezing yourself lets you break ice blocks. Remaining in either state for too long will kill you, but getting close enough to death gives you special powers for a short time. Later levels of the game rely on the use of these powers to complete, so getting a feel for how long you have to live is essential. This was one of my favorites.

Global warming was another one I really liked, probably due to my penchant for games where speed is the objective. You play a penguin running along an ice floe as it melts beneath his feet, trying to stay alive as long as possible. You earn money as you run, which allows you to purchase upgrades to increase your speed and acceleration. It’s good mindless fun, especially late in the game when all stats have been maxed out.

Temperature gods is an interesting RPG fighting game where you have to manage not only your health and mana, but also the temperature of the planet which you rule. Driving the temperature of the planet towards your goal increases your mana and gives you an edge on your opponent, but a lower temperature will give him the advantage. The soundtrack is quite excellent, and the mechanics of the game are sound — with a little polish it could be really great.

Heating and Cooling is another game I don’t quite understand. The goal is to keep the temperature of your house at a certain level by catching snowballs and fireballs. This works well, but I’m not sure that there’s a win state. A timer keeps track of how long you last, but there’s no scoring or leaderboard, so I don’t know that that’s for either. It’s obvious that there’s still work to be done, though, so maybe a future update will fix those problems.

Defenders of the Core is a top-down turn based strategy game in which you control a squad of firefighters trying to contain a blaze. You build a team up of several different classes that are designed to work together: for example, the Hydromancer can create hydrants, but a level 2 Firefighter is required in order to attach hoses to them. It’s very much a work in progress, according to the developer, but it looks like it has promise.

Last, but certainly not least, is Hot Plates. This one is my favorite of all the games that were submitted, and it barely squeaked in before the deadline. It’s a puzzle game based on Richard Feynman‘s work on theoretical physics. You control an ant which must find its way to all the food in the level within a certain number of steps. Temperature zones on the map affect the distance the ant can travel with each step; the warmer the zone, the further he can move. I started playing it and couldn’t walk away until I had beaten every level. It’s the only game I can think of which I’ve replayed over and over again in order to get gold ratings on all the levels (although getting higher than silver on 11, 15 and 18 still evades me). Hands down the best game of them all.

I really enjoyed participating, and it’s awesome to see so many other great games come out of the challenge as well. I’m going to be participating in OneGameAMonth this year, so I’m sure I’ll be able to incorporate Experimental Gameplay in with that.

Until next time!