Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics


A member registered Aug 31, 2018 · View creator page →

Creator of

Recent community posts

You've stepped into the trap that EricTboneJackson pointed out. By using sum inside a closure, write access to it is much slower. Because only one sum variable is shared across all your tests, this impacts all of them, despite not all of them requiring sum to be captured at all.

For comparison, I get these results on Node 12.2.0: 

standard for x 2.99 ops/sec ±0.42% (12 runs sampled)
for-of x 2.00 ops/sec ±0.50% (9 runs sampled)
forEach x 1.11 ops/sec ±0.77% (7 runs sampled)
reduce x 1.22 ops/sec ±0.28% (8 runs sampled)
Fastest is standard for

Then after performing these modifications:

  • capture sum only if necessary: remove the initial let sum declaration, then declare it inside the test itself (replace sum = 0 with let sum = 0)
  • move the closure declarations inside the test where they're needed (only strictly necessary for adder, since sum isn't declared yet)

The results are much more drastic.

standard for x 32.70 ops/sec ±0.25% (56 runs sampled)
for-of x 8.21 ops/sec ±0.33% (25 runs sampled)
forEach x 1.00 ops/sec ±0.73% (7 runs sampled)
reduce x 1.22 ops/sec ±0.11% (8 runs sampled)
Fastest is standard for

So, the main take-away should be: Where performance is important, avoid unnecessary closures.

Quite fun to fiddle around with.

I don't really like the gameplay it creates though - I found that I'm usually just grinding resources until I can comfortably roll the enemy, anything else tends to be a loss. It's difficult to separate workers from offensive units (well, by design), so I either waste a lot of time or have to send the workers in as well. It's just not worth the hassle.

I'm sure there's some good solution to this, so that more strategies end up being viable. Maybe workers and offensive units are so different that they absolutely need to have different controls. Such as offense on arrow keys and workers on WASD, so you'd end up managing two groups of units. But that's quite a departure from the current concept.

Was still enjoyable while it lasted. Just needs some design tweaking to retain engagement beyond that.

Great source of inspiration :P

I think this is a perfect example of what Mark meant with "don't take mechanic too literally".

The concept is intriguing and its implications are presented well throughout the levels. It makes for engaging puzzles even with only 3 buttons; I can only imagine how far you can take this with more levels and additional classic platformer mechanics or abilities on different buttons. The idea is simple but extensible and has the potential to become very deep, I think.

Certainly one of the best designs!

It's 2D Snake Pass!

The controls are a bit fiddly, but the concept works and is well presented and explored. Didn't make it all the way through, but what I saw made for interesting gameplay.

Thanks, glad you enjoyed it!

Agreed that the controls don't feel great. The low-ish FPS add noticeable input lag, and some actions take a set amount of time to complete, but that isn't conveyed to the player at all.

I've uploaded an updated version here!

Changes include:

  • controls work in IE and Edge
  • 2 more levels and small adjustments to some levels
  • higher frame rate (attempts to use screen refresh rate) rather than fixed 20 FPS, should make it feel more responsive
  • fixed a bug where an incorrect level could be loaded after winning or losing a level