Emanuele Feronato

Talking about Actionscript 3, Flash and Users contributions.

Do you know what is a script engine?

Basically it’s an engine working with the main game engine allowing to create pre-defined series of events that occurs when triggered by player location or actions.

One of the first games using this technique to increase realism was Half Life, in 1998

Scripted events and a robust AI system made it a blockbuster. Now, Michael Lüftenegger made governor, a script engine written in AS3 which provides multithreading functionality for parallel execution of code. That is, scripted events.

This is an extremely interesting project because can add to Flash games the features you can find on desktop blockbusters.

Michael shares his thoughts with us:

« The idea behind governor is very simple. In 2006 I made a tile based jump’n run engine and my aim was to make it as flexible as possible. I had the idea to allow the execution of some ingame action when the player enters a tile, or a tile enters the screen, or a moving tile reaches a certain way point, … there are a lot of such hooks.

The next problem was while developing the engine I didn’t know what action the game creator wants to be executed later. If he wants a flash light in the background, or the floor under the player to break away, or to create a new enemy somewhere in the level.

So I wanted a system that:

– doesn’t narrow the creators fantasy.
– covers everything with one solution.

Additionally flash games are facing one problem: because distribution of one file is easier than distribution of more files, normally the whole game is compiled into one swf file. That’s not a bad thing by itself. But compared to desktop games where you have one file containing the game engine and an other file containing the whole level definition, this leads to one problem. From software design point of view the code gets messed up. Things that belongs to the level definition are put into game logic. This is done for two reasons:

1. There is no solution to separate it.
2. At the end everything is compiled into one file, so no one cares about it.

For small games this is OK. But if your game is getting bigger your source code is more difficult to maintain, the performance is getting worse and the game logic gets messed up with level logic.

So I wanted a system that:

– doesn’t narrow the creators fantasy.
– covers everything with one software solution.
– doesn’t mess up game logic.

At this point I understood why desktop game engines are scriptable and I saw the advantage of this technology. Than I started to write a script engine :-)

Well, how does it work:

One of the main goals of governor is to make the usage as easy as possible. The user just needs to instantiates one class (the scheduler)

Governor already provides a basic functionality, the core API (all operators from flash, memory access, multi threading functionality).

On top of this the user has to extend the core API to make it fitting his project. To do this he has to write functions (opFunctions) that do very small actions. For example just to look if a door in the game world is open or closed.

To each of these functions he has to define a command he calls in the programming language (governor script). for example isDoorOpen(name);

The governor script gets compiled. (The compiler creates a static AS3 class holding the compiled governor script, the byte code).

In byte code the commands are not identified by it’s name “isDoorOpen”. They are identified by a number, the opCode(operation code).

So after creating the opFunction the user has to register it with the opcode to the script engine. So the script engine knows what function to call when it finds the opcode.

And finally the compiler need to know what command to compile to what byte code. So the user has to give the compiler a list of his commands and opcodes. for example: isDoorOpen:1024

I know this all sounds complicated at first, but believe me actually it’s quite simple.

Now you might have two questions in mind:

1. Why should i use it? I am just making this small game.

I think if you are making just a small game, you don’t need to use governor. Governor is a solution to a certain problem in software design like a pattern. It depends of the context and situation if you need it or not.

2. Does it mean I should write my game in governor script and not in actionscript anymore?

No! You write your game in Actionscript. Governor script just gives you the flexibility to connect things in your game as you want it to do. Imagine you have three switches in your level and each one should do something different.

The first one is opening a door. The second one lets the floor under the player break away.The third one creates a monster in the next room.

With governor you just write three small scripts doing those things and in the level definition you link the scripts to the switches. »

Try governor!