Stardust Particle Engine

A new AS3 particle engine with some very nice demos:

Stardust

Order of Operations: Flash Player 9/10

Really good post from Senocular on Flash Player 9/10 order of operations during playback.

Order of Operations in ActionScript

MiniBuilder: Flash IDE for AS3

A really neat little AIR-based IDE.

MiniBuilder.

Unity Indie is now free...

Press Release.

Excellent news...

A few links...

Things which have caught my attention recently:

• A modular application framework for AIR allowing download of signed and non-signed SWFs into different sandboxes...


• Away 3D Lite released - a stripped down version of A3D with some really impressive speed/size numbers.


• Also in Away3D news, Prefab has been released; a comprehensive tool for baking lightmaps on to Away3D models.


• Sean McCracken's experiments with hacking Tamarin/AVM2 and adding Irrlicht support.


• The Cocos2D game framework for the iPhone - nice!

Now back to experiment with both Objective-C and the Android API...

NWN2 Editor: Electron Engine

I've been playing around with the Neverwinter Nights 2 Toolset - an IDE for the Electron Engine used to build modules to play within NWN2.

It's buggy, crashes from time to time, and has lots of rough edges - but then you'd expect it to; it must have originally been developed as an in-house tool where the priority was on getting a game built rather than heavily testing the editor.

(Annoyingly, the latest patches cause both it and NWN2 itself to crash on my machine - I've had to revert to a couple of patches back, which may explain some of the bugs.)

The terrain, texturing and walkmesh editing tools seem solid and well thought out; and the library of 'placeables' works well. Where the whole thing seems to be ropey is around the scripting and conversation side. The interfaces are a bit obtuse; it's difficult to find your way around, and there's a monolithic feel to the coding system itself which means that the scripting feels clunkier than it really needs to be.

Granted, I've only just started getting to grips with it - the documentation is sparse - so there may be easier answers to some of the things I'm trying to do. But I have started to compile a short wishlist of 'if I were rewriting this editor...' things to do.

Some things I'd change:

• I'd allow multiple scripts to be assigned to events, rather than just one. At the moment only one script can be called for each event (events such as, for example, "On Use" for a lever). Since you tend to have a collection of objects which all behave in nearly the same way, you either end up with lots of small stub scripts, or with scripts that are parameterised to then call other scripts.
  Switching it to accept a list of scripts - with a priority sort on the list - would make it much easier to create modular code. I suppose it'd be rather like Director's old behaviours system.
  If this slows the actual runtime execution to a crawl, there's nothing to stop the scripts being merged into a single script at compile time.


• The editor needs an 'update my placed object from its blueprint' button - for when you've edited something in the library and want the instance in the scene to be updated accordingly without manually copying over the changes.


• I'm really surprised by this one - it's easy (via a library script) to add a condition to a line of dialogue so that the line is only available if - for example - a variable is set. But there's no simple way to set a flag or variable when a line of dialogue is played without writing an entire script file to do so. Seems overkill. So I'd add a 'when this line is played, set this variable/flag' option.


• I'd have hierarchy of blueprints akin to class inheritance ("Sleeping Guard" derives from "Guard" derives from "Human", for example). This would make it easy to modify generic behaviour (especially with stacked event handlers as noted above) and easy to apply changes to an entire set of objects. Again, this could be build time rather than runtime so should have little impact on speed.


• And the biggie: I'd do my best to allow a live test mode; to test the scripts and behaviours rather than the rendering. Because skipping out of the editor to load the _very_ chunky NWN2 game is slow, and must make level development and testing a complete nightmare.

That's my list for now. It may well grow.

NWScript itself isn't too bad - it's sort of a subset of C.

Incidentally, trawling through library code I've discovered lots of comments by Naomi Novik, who wrote the quite excellent Temeraire. I'd no idea she was a coder, and no idea she'd worked for Obsidian/Bioware/Black Isle or whoever originally wrote those scripts. Interesting!

AIR with full screen - Print Dialog hidden

I had an annoying issue yesterday where I discovered that if I called Flash's print function (via PrintJob) in a full screen AIR app the print dialog wouldn't be shown - it would appear behind the main app window.

Took a bit of hunting around, but eventually I discovered that it was a simple case of setting:

alwaysInFront=false;

on the main AIR window (my main WindowedApplication).

Why it should have been set to true by default I have no idea.

Thought this might be useful for other people!

P.S. As an addendum, Flash/AIR still has major issues while printing, all to do with windowing and the print dialog. In the end we just couldn't get it to work acceptably in full screen - so now when you print from our app we have to switch out of full screen, present the print dialog and then switch back in. Very irritating, with no native Flash/AIR workarounds.