That Dummy


This game never got a proper name, so we had always just called it “That Dummy Game”. This was a collaboration work between me and Andrew Sandifer. He had come to me with a prototype that was pretty well off. It was a FlashPunk game, and he had done a lot of art for it already. It was a simple puzzle platformer where the goal was to get to the door.

It had everything from portals to boxes to doors. Switches, levers, lights. It really had a lot of content. It wasn’t finished, but it already had a good feel.

For now it's being referred to as 'That Game'

Adding More

However, Andrew wanted more tech for the game. He was working on pushable boxes, and the math just wasn’t playing nicely. So he told me to add Nape for a physics engine. After a ton of tweaking, the character movement felt right, and boxes were easy to push around. We could now change gravity, and do all sorts of fun stuff. Then I added some lighting effects. Simple radial gradient lights. It game the game a much better atmosphere, and even changed the way the game was played. On some levels, you had to activate lights to see the path. We had a simple circuitry system that allowed buttons and switches to control multiple things from lights to doors.


However, after adding lighting, I ran into some issues. Andrew had set up the project to use OGMO for its level editor, but that made it really hard to position and size lights. I told him that I wanted to add a level editor, and he told me that the game needed to remain simple, and didn’t need an editor. I went ahead and got started on it anyway.


The good thing about having everything running through Nape is that it was really easy to introduce new entities into the system. And once the editor was underway – the game was becoming what I wanted it to be. The problem is – Andrew wanted something else, and we slowly lost contact as development moved on. I kept focusing on the tech. Performance and effects.


I moved from simple light gradients to shadow casting ray traced baked shadows, I added a fog layer, a foreground and background parallax layer, I added (Asynchronous) A* pathfinding, I added blood effects and bullets. I added fake threading. I added a slow motion effect, real time fullscreen post processing. You can adjust saturation, brightness, and hue. I added ripple effects and an underwater mode. I also added a sound system that allowed me to slow down or speed up any sound effect in the game.



Get this! I even added ingame scripting. You could write and compile AS3 IN THE GAME!


This game just needed some dialogue and some enemies.



I decided it was a good time to add turrets as an enemy. I asked Andrew for a turret sprite – but he never got back to me. I opened photoshop and drew a poor quality sprite myself. I asked Andrew for a Rocket sprite, and never got a response. It was obvious to me that after taking over the project – Andrew no longer wanted to work on it. I added a 2nd tilesheet- some more of my own artwork, and was feeling pretty good about releasing this game on my own.



During gameplay – physics driven characters aren’t always bug free. I had gotten my character to what I considered perfect, but there was an occasional bug where if you walked against a wall and jumped, you didn’t jump as high as you should. I made sure the character had no friction. I frantically tried many different hacks, and then I talked to Deltaluca, the author of the Nape physics engine. He told me that it was a bug that couldn’t really be avoided without using Bruteforce collision detection. I tried bruteforce- and it worked! The bug was gone.

The problem with bruteforce collision, is that it is VERY slow. My performance was cut 90%. A perfectly smooth game was now jittery with too many active objects – and there was no simple way to make the objects sleep. Bruteforce kills the sleeping ability of rigidbodies.

Now I asked Deltaluca what I could do, and he told me to switch to NewNape – a full rewrite of his physics engine. I had known about the newer version, but it was so radically different that I didn’t want to make the switch. Everything was different. Collision response, callbacks, masks, the new API was totally different. What could I do?

So I imported NewNape- and saw a few hundred errors. All my old code was going to need to be rewritten for this new physics engine. The game was highly coupled with OldNape.

I tried for a few days to fix things up and get the game working, but with no support, everything broken, I gave up.

64 Days later

Each build I sent to Andrew was dated. I was on day 64. He wanted the game done by Day 20. Here’s what Day 64 was like.

This game wasn’t completed because of some bugs in player movement that couldn’t be fixed without a massive rewrite. Halfway through the rewrite- things felt impossible. If I pick up flash again, this game might get completed, and it’s possible that this game will be revived in Unity. Only time will tell.


  1. Sam Watkins
    Sam Watkins February 3, 2014 at 7:07 am . Reply

    interesting story, I’d like to see your game … you said “there was an occasional bug where if you walked against a wall and jumped, you didn’t jump as high as you should” – my suggestion is, who cares about that extremely minor bug. Rewind to that point and continue. Hopefully you did keep the old code somehow, maybe in a version control system or just a backup…

  2. sswam
    sswam February 3, 2014 at 11:23 pm . Reply

    cool, good luck, and if you need an alpha tester please let me know!

  3. 2morrowman
    2morrowman July 6, 2014 at 7:36 am . Reply

    where I can any version of your game?

  4. Olivier Perrault
    Olivier Perrault May 24, 2015 at 4:28 am . Reply

    Hey man ur game looks amazing:) Im trying to make my own using flashpunk and nape but im a beginner and ive run into this problem. I have no idea how to associate a nape static body to my flashpunk grid for my main map so all of the object can collide with. If you have any sample code demonstrating this I would greatly appreciate. Thank you:)

Leave a Reply