TIGSource Forums

Hi there. I'm not sure if this question has been asked before (I've searched the forums before asking) so here goes: has anyone researched the possibility to script the ActionScript 3 games? I'm aware it may sound funny (scripting a scripting language) but as you surely know AS3 is compiled before running so there is no straight-way possibility to change or expand the game's functionality on the fly. You have to recompile the SWF.

I've found some simple expression (mainly mathematical) evaluators or rather nifty (Tamarin related) techniques like taking a string with a piece of code, generating AS3 bytecode for it, compiling the bytecode on the fly to an in-memory SWF file and than loading this file but I've had problems with using my own classes in such runtime generated SWF's.

What are your experiences in this field?

You could very easily write a simple scripting language for AS3 since you can call functions by string names. You could also call javascript in the page and return data back through ExternalInterface.

I don't really understand why exactly you'd need to do that.

I realize this was an esoteric question that I'm not really answering, but a simpler way to get the same functionality would be to automate the compiling step (for instance a tool that runs the compiler on any file in the script folder when it detects a change; if you wanted users to be able to write scripts without downloading the Flex2SDK, something more complex a-la wonderfl http://wonderfl.kayac.com/ (http://wonderfl.kayac.com/) would be necessary)

Then you can just load the external .swfs containing the scripts into a main .swf (at least, in theory -- I haven't actually tried this yet!).

The auto-compiling tool could even signal the main swf to get it to automatically load/reload the newly generated swfs; I'm not sure what the best mechanism for this could be, one slightly convoluted option is that the tool could write the new filenames to a textfile, then launch a separate "notifier" swf which would read the textfile and use a LocalConnection to signal to the main swf which file(s) needed to be reloaded.

At some point a script needs to be compiled from plaintext to bytecode in order to run; I guess Lua/etc just compile on-the-fly at load-time rather than beforehand. So until Adobe provide LoadScript(script:String), I would advise the more pragmatic approach of just automating/hiding the compiling step rather than trying to avoid it altogether ;)

There are plenty of ways to interact on the fly with a game that tries to support this. Are you trying to write games which are scriptable or to write scripts to control games not written with that in mind? For the former, I'd use something like Ivan's approach. The latter is more-or-less impossible.

I've written a "scripting" "language" in AS2. I used XML rather than freeform text to avoid having to worry about parsing it, and it was domain specific, but it still counts.

Writing an interpreter is actually rather easy. Some dude busted one out for Lisp, you can google for it. Speed is probably poor though.

I've not heard of anyone actually compiling AS3 and re-downloading it for a game - it's too much effort, though I'm sure it's technically feasable.

But the real question is if you need a scripting language. AS3 is very flexible, so until you want code that modifies itself, or a DSL, I cannot really see the advantage of such a thing.

AS2 had eval(), which could run AS code from a string. AS3 sadly doesn't have that (though the advantages of the reason why that's impossible are immense: AS3 compiles to highly optimized bytecode)

Thank you all for your answers. The functionality I have in mind is closest to the AS2 eval() function mentioned by Ivan. BorisTheBrave's scripting from parsed XML is one of the options I've also been looking into.

As for the reasons of trying to achieve that - the first example would be to be able to change a NPC's behaviour without the necessity to recompile anything (whether it's the game's core or some external SWF containing behaviour functions). Of course the term "no necessity to recompile anything" is very contractual because as raigan pointed out - the script has to be compiled at some point or another.

But what are you going to change the behaviour to? You must mean from an external input, or else it could all be programmed in advance. But you wouldn't have said NPC if you'd meant user input, and input coming from the server can be compiled anyway without roundtrip worries.

So I'm left to assume you mean cutting down on recompilation during development to save time. This is a somewhat different question, though not one I feel qualified to answer.

That's exactly the whole point of my question. ;D Sorry I was not precise enough right from the start.

As it turns out, posting the problem on the forum can be quite motivating even if the thread doesn't get much attention. :) Anyway, I've decided to give another shot to the technique I was fiddling around couple of months ago and this is what came out this time:

http://vigeo.pl/adrian/labs/as3-scripted-enemy/ScriptedEnemyTest.html (http://vigeo.pl/adrian/labs/as3-scripted-enemy/ScriptedEnemyTest.html)

It is a simple prototype, a proof of concept, that let's you modify the logic of the enemy NPC at runtime. It comes with an example function (inactive by default, click compile button to see it run). It uses the Metal Hurlant's AS3 Eval library that can be found here: http://eval.hurlant.com/ (http://eval.hurlant.com/). The library is quite powerful as it provides the EcmaScript functionality in AS3 (ActionScript 3 is a subset of EcmaScript) although it has its quirks.

I haven't done any performance tests but I'd say that overhead is minimal as the script gets compiled to AS3 bytecode just once. But I may be wrong. :giggle:

As I said, it's just a proof of concept. The motivation is to be able to pull behaviours out of the compiled SWF, to come a little closer to data-driven development where you can just modify a text file containing your script, refresh the browser and there you have it - just working without the need to recompile yor game. ;D

Sharp, that's an awesome find. I'm somewhat amazed to see that exists without more attention being drawn to it. It's also a testament to how cruddy the compilers are that this is a valid technique - logically you should have to recompile very little each time.

Also, why waste time refreshing the page. For one project, I reloaded the level when you press space (on debug builds).

Phil Hassey managed to compile his python interpreter (tinypy) using alchemy. Is this the sort of thing you're looking for?
Read the comments! (http://www.philhassey.com/blog/2009/03/12/i-can-has-flash/)

Well actually the prototype above shows exactly what I was trying to achieve but thank you for the link. I've seen Alchemy before and I get your point though I didn't give much attention to this project. Also, isn't Alchemy the way they got QuakeLive up and running?

Also, theoretically, you can use flex-py (http://code.google.com/p/flex-pypy/) to produce a Flash version of the PyPy python interpreter. I don't think flex-py is fully working yet, though.