In this week’s DevLog, I take a look at my 2009 game Dark, from which I’ll be stealing the platformer-on-a-physics-engine mechanics, and eventually the level editor, for Stick Ninjas.

In celebration of… uhmn… this DevLog, I guess… I’m making Dark available for free for PC. Not that it wasn’t practically free before. But now it’s properly free – just download it and go 🙂

There’s also an Xbox 360 version, which is basically the same as the PC version, but might play a bit better because it’s specifically tuned for the hardware. It costs 80 “Microsoft Points”.

If you’re looking for the blog post I mention in the video, it’s over here: Perfectionism.


Petr Abdulin

12:37 am, Friday 24 August 2012

Unfortunatelly, interview link ( )is broken..

Petr Abdulin

2:54 am, Friday 24 August 2012

Tim Jones

1:21 am, Saturday 25 May 2013

That’s a nice level editor you have there – how did you handle resetting the game state after “stopping” the game? I’m also curious if this – – means that the Dark level editor supports dynamic recompilation of scripts?

Andrew Russell

2:04 am, Saturday 25 May 2013

Hi Tim, Thanks 🙂

To put it simply, there is an “Editor” object type for each kind of “Engine” object in the game (eg: Pawn, Polygon, Light, Path, Joint, etc). This is used to provide the specific editing functionality for each kind of object.

When the editor loads a level, it dynamically creates these editor-side objects. The editor-side objects retain enough data to then reset or recreate the engine-side object.

One of the nice upshots of this is the ability to modify the editor-side objects while the simulation is running, so changes survive a reset. For example: setting object start positions by manipulating the physics simulation.

Of course, a saner person might simply serialize and deserialize the entire level. It’s not that much data, and writing it to memory is quite fast.

As far as scripting goes – Dark uses pawns to define its level behaviour, similar to the original Unreal. There’s a “TriggerByRadius” pawn and a “ShakeCamera” pawn and a “DelayTrigger” pawn and a “LightFadeAlpha” pawn and so on. This was a mistake.

Setting up complex level behaviour (like the Dragon scene) with these was a nightmare. I’d definitely go for per-level scripts (in beautiful C#, of course) in the future.

(Actually there are “DragonPuzzle” and “DragonButton” pawns – which are like mini scripts. But the behaviour that happens when you complete the puzzle is managed by a huge sequence of “DelayTrigger” pawns – horrific.)

I’d probably want to implement dynamic recompilation, like that SO question you linked. But I’d probably actually end up just doing my amazingly fast Edit-and-Continue trick, because it’s “good enough” and requires basically no implementation.

Tim Jones

3:06 am, Saturday 25 May 2013

That’s a neat trick – I like the idea of editor-side / engine-side objects, and the ability to persist changes made while running the simulation. I’ve been having a look at Unity – I think they simply serialize the entire scene state before running the game, and load it back again afterwards. Which, as you say, is easier but less powerful.

I’m interested in 3D editors because I’ve been tinkering with an XNA-based scene editor, on and mostly off, for a few years. Here it is, in all its nowhere-near-finished glory: . I’d really like to add a Game View to the editor, but I’ll probably keep it simple and go with whole scene serialization.

Tim Jones

3:13 am, Saturday 25 May 2013

Oops, when I said “3D editors”, I meant “game editors”. Didn’t mean to discriminate against other dimensions 🙂

Tim Jones

8:18 pm, Monday 27 May 2013

I was curious if Roslyn would help out regarding compiling / recompiling scripts, and it turns out it does: I just added an answer to your old SO question:

Roslyn + collectible assemblies would make for a pretty cool in-editor script editing experience – I’m surprised nobody (that I know of) has done it yet.

Andrew Russell

6:08 pm, Tuesday 28 May 2013

That looks pretty awesome. Things have come quite a long way since 2009. I wish I had more time at the moment to look at it in more detail, and to keep up with advances like Roslyn.

The last time I looked into putting something like this into real-world use, I was looking at the possibility of tightly sandboxing a C# script or .NET assembly in such a way that it’s safe for automatic distribution between “untrusted” players. I wonder, do you have any insights in this area?