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.

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 traversing 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.