Glide update: Tween overwriting

I’ve just added support for property overwriting to Glide, my Tweening engine for C#. This functionality exists in Actuate (a great Haxe library from which I’ve taken a lot of inspiration) and I’ve wanted it in Glide for a while now because it’s just so darn handy.

Imagine you start a tween off on its way:

// move image to (100, 200) over five seconds
Tweener.Tween(image, new { X = 100, Y = 200 }, 5);

…but then something changes, and now you want your image to travel instead to (X = 500) instead, and it should only take two seconds:

Tweener.Tween(image, new {X = 500}, 2);

At first this will work fine, but when the second tween finishes, suddenly the first one takes precedence again and your image will keep moving towards (X = 100). You could cancel the first tween, but that would also cancel the movement towards (Y = 200).

Now, creating a new Tween on an object that’s already being tweened will cancel the movement of any properties that are currently being tracked. In the example above, the new X tween would overwrite the old one, the original Y tween would keep on working, and there’s no need to manually cancel anything.

The old behavior is still available; just pass false to the overwrite parameter. I’m pretty sure that won’t be necessary in the majority of cases, but it does exist if you want it.

Iridescence development visualized

Three name changes, three frameworks, and 33,697 lines of code and data — this video represents 11 months of nearly solo development at the rate of two days per second.

Each dot is a file, and each cluster represents a folder. Green lines represent new files being created, yellow for modifications, and red for deletions. Source code settles out at the bottom left, with level files top right. Audio is up on top near the levels, with an equal number of .oggs and .mp3s to support multiple platforms.

Towards the end it’s obvious that a lot of work is being done on level design, with scattered changes to source code as I fixed last-minute bugs, and a lot of new image files being added as I rounded up screenshots and promotional art.

Created with Gource. Music is “Hongdae” by Lukhash.

Get the game:

What are we up to?

It’s been a while since I last posted on here, so I wanted to give a short update on what’s been going on since we released Baseborn.

Chris and I are both participating in OneGameAMonth, and have each released a few games this year already; Scattered Song, Humphrey’s Tiny Adventure: Remastered, and Must’ve been Rats, a game jam project with our friend Paul Ouellette. I also participated in December’s Experimental Gameplay challenge, and my entry was reviewed by Indie Impressions. and IndieStatik. Having one of my games reviewed was quite a milestone for me, and I’m quite pleased with the reception it recieved.

We’re deep in preproduction for our next game, and I’m hard at work on our new engine, which is coming along really well so far. I’ve found that working on small side projects every now and then is a great way to keep motivated on a larger one, so my monthly game jams have actually increased my productivity while working on the engine. We’ll be officially announcing our next game as soon as we have something to show off.

 

Humphrey’s Tiny Adventure: Remastered

Last year I participated in my first game jam with Ludum Dare #23. The result of those 48 hours was Humphrey’s Tiny Adventure, which I’ve written about previously. I was really proud of what I was able to accomplish, but there was a lot that I wanted to do with the project that I didn’t have time for. I didn’t include any sound or music, and I didn’t have anyone test it before release, so I never had the chance to get feedback. I recently decided to give Humphrey a long-overdue makeover for one of my entries in OneGameAMonth.

Over the past three weeks I’ve rewritten every piece of code in the game. Looking back at the original code, I’m literally terrified at the prospect of dealing with it. For the most part the gameplay is nothing complex, so I was able to build on the engine I wrote for Hypothermia. I created a data-driven cutscene scripting system using Slang, which I wrote about here. This was immensely helpful both in terms of writing reusable code and iterating quickly on the way each scene played out.

I’ve also redone almost all of the artwork. The art in the original version of Humphrey was composed entirely of large colored squares. This was mainly due to time constraints; the abstract style allowed me to spend very little time on each asset while still conveying the desired meaning. For the remake I did away with this restriction, and I’m very happy with the results. As usual, I used Inkscape for all the art.

Finally, this release includes a fantastic soundtrack by Chris Logsdon. It was composed specifically for the game, and you can download it here in high quality for the price of your choice.

Download the game here! I’d love to hear what you think of it!

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

Flashpunk

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
        done
}

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

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

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!

 

Hypothermia — Experimental Gameplay challenge

Update: Hypothermia is now available on itch.io!

For the last few days I’ve been participating in the Experimental Gameplay challenge, a monthly game-making competition. The only rule is that you can only spend a week on your entry, so on December 1st I sat down and started crunching on a game for the chosen theme, “Temperature“. The result is Hypothermia, a first-person point-and-adventure in the style of Templar Studios’ Mata Nui online game. You can download it here.

This is the first game I’ve made that used Slang for scripting. Nearly all gameplay code is written in Slang, and it was incredibly helpful. Instead of making changes in AS3, recompiling the game and testing, I was able to hot-reload script files with FLAKit and see the changes instantly.

In addition, I used Ogmo Editor to set up entities in the scenes. I’ve never used it myself before, and I wish I had started sooner. With the help of the OgmoWorld and XMLEntity classes I wrote, I was able to load entities from Ogmo levels automatically with barely any prep work involved. And, once again, FLAKit’s hot-reloading allowed me to modify the levels and see my changes instantly.

Using Slang and Ogmo together allowed me to use a much more data-oriented approach to development than I’ve been able to in the past. This greatly decreased iteration times and allowed me to get scenes finished faster. In many cases I was able to work on the game for upwards of ten minutes without closing it once.

As usual, I used Flashpunk as a flash framework and Inkscape for graphics. The source code (as well as the original SVGs for all the art assets) can be found on the project repository in Bitbucket.

Slang: Stack-oriented scripting for Actionscript 3

I’ve been working on and off on a project to create an in-game console for my flash projects. Initially it had a simple command system, called “Slang”, where a function could be associated with a string and called from the console, and that was all it could do. Eventually I added limited support for parameters, but value passing was extremely brittle and only one function could be called at a time.

I’ve recently released a major rewrite that constitutes Slang v0.5, which adds support for nested function calls, return values and rudimentary conditionals.

Syntax

Slang is a stack-oriented language inspired by Forth and Stackr. Unlike these languages, however, Slang function calls are ordered left to right. Statements, or lines, may be ended with a semicolon, but this is not required unless multiple separate statements are required to exist separately.

Here’s a simple function call, demonstrating the obligatory Hello World program:

print "Hello, world!"

output: Hello, world!

 

Here’s a slightly more complex example, to demonstrate the order in which functions and parameters are evaluated:

print equals 1 1

output: true

Functions are called as values are added to the stack immediately after them. In the example above, equals consumes two values and returns one, at which point print consumes one (the value returned by equals) and outputs the value.

Conditionals

The built-in “if” function allows conditional execution. If it receives a false value, the currently executing statement (all code up until the next semicolon) is terminated. Boolean values can be inverted with the “not” function.

Here’s an example:

if equals 1 5 print “1 and 5 are never equal”;
if not equals 1 5 print “1 and 5 are, in fact, not equal”

output: 1 and 5 are, in fact, not equal

 

Custom functions

Adding custom functions to the Slang interpreter is extremely simple. Pass in a name, a function or method closure, an array of parameter types and the object to invoke the method on, and you’re all set. Here’s how the print function was added:

var slang:SlangInterpreter = new SlangInterpreter();
slang.addFunction("print", print, [String], null, "Print a string to the console");

 


If you want to try it out or poke around in the source, you can do that here. Slang is currently integrated into my AS3 helper library FLAKit, but the interpreter class is dependency-free and should work fine on its own.

Slang is still a long way from finished, and there are a number of bugs that still need to be addressed; for example, using a semicolon inside a string will cause the compiler to think you’ve started a new statement. I think it’s really coming along, though, and I’m really happy with the progress I’ve made on it so far. I’ve been using it in my most recent project, and being able to edit a script file, hot-reload it with FLAKit, and see the changes instantly without restarting the game is really awesome for productivity.