Tag Archives: actionscript

Hypothermia is now on itch.io!

 

A while back I made a little game called Hypothermia for Experimental Gameplay‘s “Temperature” challenge, a game jam of sorts that ran for a week during November/December 2013. It got reviewed by Indie Impressions and Indie Statik, and some guy from China did a Let’s Play of it.

Based solely on download count, it’s my most successful game thus far, but I never managed to find a hosting site for it that was a good fit, so despite it being a flash game anyone who wanted to play it had to download an archive containing the SWF and a web page. Thanks to itch.io, I now have a place to upload it without having to worry about it being blammed by people who don’t understand game jams. ;)

Play it here!

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.

 

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!

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.

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.

First Ludum Dare — post mortem

humphrey

(This was originally posted on the Ludum Dare compo blog, for competition #23 “Tiny World”)

I’ve known about Ludum Dare for a few years now, but every time it came around I would end up having too much to do in real life to participate. This time I was finally able to get involved, and it was one of the best things I’ve done in a long time, resulting in Humphrey’s Tiny Adventure, a point-and-click adventure game. Here are a few lessons I learned along the way.

Do as little brainstorming as possible

I knew from the beginning that I wanted to make an adventure game. At 9:00 PM the first day, the theme was revealed and we were able to get started. I spent 15 minutes sketching out some basic ideas and then got right to work. Not everything I wrote down made it into the final game, but it allowed me to get started quickly and add details as I went along, instead of trying to develop a complete design doc or storyline.

 

Get all your tools and libraries ready to go beforehand

This is a bit of a no-brainer, but I thought it was worth mentioning For this project I used FlashDevelop for my IDE, Inkscape for graphics and Chronolapse for screencasting. Since all three of those are necessary to get started, it wouldn’t do to have some programs downloading after the compo officially started.

 

Pick an art style that you can produce quickly

I’m mainly a programmer, and while I am capable of creating some reasonably impressive vector art, I certainly can’t pump out high-quality assets fast enough to make it a viable option for a game jam. I decided on an art style that consisted only of colored rectangles, which allowed me to keep my art simple, uncomplicated, and abstract enough that realism wasn’t a concern.

 

Use release-quality art early on

Chances are if I started out using placeholder art I would just continue using it until I ran out of time. Creating final art assets in the beginning helped me have a feel for how much work it would be to bring the project to completion.

 

Use version control

If you aren’t using version control already, start now. The first thing I do when I start a new project is create a new local Mercurial repository, and it’s saved me many times in the past. Using version control can save you if you mess up your project too badly, or retrieve old versions of your files if you decide that the first iteration of your player class is the better one.

 

Record a screencast

Keeping a video running of my work helped to keep me from getting distracted. If I wanted to update my progress on twitter, I had to open up Chronolapse and pause the capture, and even that small amount of required action was enough to keep me from constantly tabbing over to check my email.

 

Take breaks and get enough sleep

Whenever I came across a tough problem or design decision, I got in the habit of getting up from the computer and making myself a hot cup of tea. As much as it might seem like it’s necessary to spend the entire 48 hours in your computer, the best thing you can do for yourself is to take it easy. If you overwork your brain you won’t be able to think clearly and therefore won’t be as productive as you could be.

 

I think that’s about it! I had a blast participating, and I’m definitely planning on doing it again. :)

Actionscript — likes and dislikes

 

I’ve been using Actionscript 3 as part of my game programming class for almost a month now. Coming from a C++ background, there were a lot of things I didn’t like about it the first day. Some of those things I’ve grown to like; others…not so much.

 

Things I like about Actionscript:

The import system

In AS3, libraries are built on the “one class, one file” paradigm. Each class must reside by itself in a file with the same name as the class. At first I thought that this was just a needless imposition; coming from C++ where every class can be in one file, it seemed silly to me that a language would restrict the freedom of the programmer in that way. As it turns out, this is possibly the thing I like best about the language.

AS3 classes are organized in “packages”, in a similar way that C++ uses namespaces. A package is a folder that contains class files, and is usually named according to Java naming conventions; for example since my website is www.jacobalbano.com, my classes are in the folder hierachy com/jacobalbano/, resulting in the package com.jacobalbano.

The beauty of this system is that the source is always exactly where you expect it to be, as opposed to in C+, where hunting down a class definition in a source tree can be a pain. Additionally, there is no concept of definition and implementation, since each class is contained in its own file.

Getters and Setters

In C++ classes, modifying or accessing private member variables requires two functions, usually defined as SetVariable() and GetVariable(). Actionscript streamlines this pattern with getter and setter functions, which take this form:

This allows access to the private variable _ID like this:

The beauty of this system is that it allows the convenience of a public variable without the problem that setting a variable is often not enough. For example, to start an animation with a class in C++, you’d have to use the following style:

The PlayAnimation() function in the above case might stop the current animation and start the one specified in the function’s parameters. In Actionscript, the procedure would be the same, but the interface is different:

In this case, the setter function would perform the same actions as PlayAnimation(), but in a cleaner way, in my opinion.
In addition, member variables can be made read-only or write-only by eliminating one of the functions.

Super() and function overrides

When extending a class, functions of the base class can be overridden with a function implemented in the derived class. In addition, the base functions can be accessed with the super keyword. For example:

The base function update() is overridden by the derived class, but it is preserved so we can still access it.

Function pointers

I’ve tended to shy away from using function pointers in C++, even going as far as to embed a Lua interpreter to bind actions to a GUI. Actionscript makes it easy to store and use function pointers with the Function type.

 

Things I dislike about Actionscript:

Syntax

This is a big one. Actionscript’s syntax (and that of any other ECMAscript-derived language) is close enough to C that I didn’t have a hard time picking it up, but some of the changes are clumsy. I would say the biggest offender is variable declaration.

This introduces another gripe I have…

Actionscript is a GC language.

I know it isn’t cool to manage memory yourself anymore, but I like the control it gives me over the program. Actionscript is very picky about what may and may not be deleted.

Actionscript doesn’t have Enums

Enums are a fundamental part of my programming workflow. I can’t think why they wouldn’t exist within the language, but they don’t.

Actionscript has limited support for class templates

The only class that has template support is the Vector class, and templates aren’t exposed for implementation into custom classes. I managed to fake it a bit, but it’s far from preferable.

Actionscript is platform-specific

I wouldn’t even consider learning a language if it didn’t run on Linux. Fortunately, Actionscript can be developed, compiled and run on Windows, Mac and Linux natively. In this case I refer to the fact that Actionscript only really runs on the Flash or Air VMs, one of which has been discontinued on Linux, and neither of which has particularly good performance.

Actionscript allows developers to be lazy

The Flex compiler won’t complain if you miss a semicolon. Forgot to define a return type for a function? Don’t worry, the compiler doesn’t care. I compile my C++ with every possible warning enabled, so this is another thing that bothers me a lot.

Actionscript doesn’t support overloading

In Actionscript you can only have one function per function name, even if the parameters are different between declarations. This means that you can only have one type of constructor, which gets awkward. In addition, operator overloading is not allowed, so if you want to trace your custom class you’re out of luck.

 

There’s a lot to like about Actionscript, but it has its fair share of ugly features and anti-features. If not for Flashpunk and FlashDevelop I would have given up on it by now. Ironically, Flashpunk is the best framework I’ve ever used, period, and Flashdevelop is the best IDE I’ve ever used, period. At least they make the language bearable while I have to use it.

Implementing std::pair in Actionscript

This post is pretty out of date, and I wouldn’t use the same solution today. I’m leaving it here for posterity, but don’t consider it some kind of expert advice.

One of the things that bothers me about Actionscript is the lack of templates. The Vector class is their only appearance, and since Adobe hasn’t seen fit to open up the feature for general use it looks like that won’t be changing anytime soon. I’m not very good at using templates in my own C++ classes, but I certainly like to use them as part of the STL.

This week I needed a function to return two values at once. “No problem,” thought I. “I’ll just use a std::pair to store both.” A few seconds later I realized that I was still thinking in C++, so I went around searching for a comparable class in Actionscript, only to find that none existed. This was not to be borne.

Therefore I present a class I wrote to fill the gap. It’s compiler safe and mirrors the design of std::pair as much as possible.

Example usage:

I haven’t done a huge amount of testing, but I’m happy with how it works so far. As usual it’s open-source to do with what you want. The repository is here.