Category Archives: Programming

Action scheduling with Lua

One of the downsides to moving between programming languages is that you inevitably lose all the base code you’ve gotten used to using. When I was using Actionscript 3 regularly, I wrote Slang to meet the lack of a scripting language that ran inside of Flash and ended up using it for a number of purposes in my subsequent game projects. The most useful application I found for it was for setting up cutscenes and scripted sequences, and I’ve missed using it now that I’m spending more of my time using C#.

Rather than porting Slang to C# (which would have been quite an ordeal), I’ve been playing around with Lua in an attempt to recreate a similar system. Here’s the first draft of how a scene might be set up.

Continue reading

Exploiting Actionscript 3’s “this” keyword for fun and profit

I originally posted this as a reply to a topic over at the Flashpunk developer forums and thought it would make a good post all on its own.

Something I really like about as3 is that you can define functions anywhere, even within other functions. Such a function is called a closure, as it “closes over” its surrounding environment and has access to all variables that exist in the current scope. For example, you can do this:

When the alarm triggers (after one second, for those unfamiliar with Flashpunk), the closure is called and the message “Hello, world!” is displayed. The function will keep a reference to the message variable as long as it’s being used, long after the function it was created in goes out of scope.

The trouble begins when you use the this keyword inside a function you’re going to pass as a callback.

You’d expect that this would refer to the object that was in scope at the time the function was created; for example, running this code from your player class should trace “[class Player]”. Unfortunately that’s not the case; this always refers to the object that calls the function. In this case, the callback is being called by the Alarm, so it will trace “[class Alarm]”.

This can actually be helpful at times, such as if you pass a function to a GUI control, like so:

In most cases, however, this behavior is just a pain and causes crashes that can’t be caught at compile-time. There’s a solution to that as well, though:

Since self is captured by the function, it will always refer to the this object at the time of the function’s creation; in this case, the Player class instance. This code will trace out “[class Player]”, just as expected.

The Actionscript family of languages is ultimately based on ECMAScript, so a lot of the quirks present in Javascript carry over. Some of them can be annoying to get used to, but as long as you’re aware of them they can serve you well.

 

Glide released

I and a few of the game developers I follow have been transitioning from Flashpunk/as3 to SFML/C# recently. I still like using Flash to knock out quick prototypes, and I’ll still turn to C++ for serious projects, but C# is a reasonably nice middle-ground option. Something that kept coming up was the lack of a good tweening library along the lines of Actuate or TweenLite, which is an important part of making a game feel good in its early stages. I couldn’t find a good solution after looking around for a while, so I wrote one. It’s called Glide, and you can download it here.

Glide has gone through some huge changes since its first iteration, and after a lot of testing I’m confident that it’s ready for the world. If you’ve been looking for a tweening engine for C#, give Glide a try! I’d love to hear if it helps you out.

RichText in SFML

I’m using SFML for pretty much everything in my game engine. I started using it to help me learn C++ and never left. It’s pretty amazing; cross-platform, hardware accelerated 2d and one of the best APIs I’ve ever used. It’s a genuine pleasure to work with when it comes to expressiveness and simplicity.

I’ve recently been working on adding rich-text support to my engine, and while SFML does come with text rendering built in, it’s very simplistic. A text instance can only have one color and combination of styles in total, so if want to italicize a single word in a sentence you’re out of luck; you’ll have to split the text up into multiple chunks and position them independently. I’ve written a class that handles this all automatically, along with a simple markup parser to manage formatting. You can get the source here, and discuss it over at the SFML forums on the topic I made for it.

riches

Here’s a screenshot of the class in action, with the text source above.

I’ve done some parser work before (notably for Slang), so the markup interpreter was fairly straightforward. All formatting is done with single-character delimiters (*bold*, ~italic~, and _underlined_), and the color tags can contain a hex value or color name. I’m sure it can use some optimizing, but so far it’s quite fast and works exactly as well as the vanilla Text class.

If you haven’t used SFML before, I highly recommend checking it out! The fact that I was able to put all of this together in just one day is a testament to the power and ease of use that it provides.

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.

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.

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.

OgmoEntity

If you’re doing any kind of game development, you owe it to yourself to look into Ogmo editor. It’s a great generic map editor similar to Tiled and Mappy. In addition to tilemap support it also lets you define entities and place them in the levels. These entities can have properties which show up in the editor as text fields, sliders and checkboxes, depending on their type. The levels are saved as XML, so they can be used just about anywhere.

I used Ogmo in one of my recent games and came up with a ton of entity types that sent my productivity through the roof. Unfortunately, there isn’t any kind of export feature built in, so for the next project I would have to recreate all of those entities again — not great for productivity. Today I wrote a small tool to fix this, and I wanted to share. It’s called OgmoEntity.

Copied from the readme:

How to use:

  • Put OgmoEntity.exe in the same folder as your Ogmo project (ie. Project.oep) and run it.
  • Entities defined in the project will be exported as .oen files; OgmoEntity_[Entity name].oen.
  • All .oen files in the project folder will be imported into the Ogmo project file. You’ll have to re-open it in Ogmo Editor in order to use the new entities.

That’s all there is to it!

You can get the binary from the downloads section, or the source by downloading the repo.

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:

output: Hello, world!

 

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

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:

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:

 


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.