On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Limeox

11
Posts
4
Followers
A member registered Aug 31, 2018 · View creator page →

Creator of

Recent community posts

Wow. Thanks so much for the kind words! ❤

Yep, that's completely valid criticism. Some of the first few levels would be improved by teaching things faster, either combining them or introducing the main mechanic sooner.

Oh god the faces lmao

Moving and rotating pieces at the same time is a pain, because they both rely on mouse movements. Rotating in 90° increments via keys or mouse wheel would be helpful, as there doesn't seem to be possible to rotate any other amount anyway.

Other than that, the game is just awesome. Impressive idea, fun and challenging to play.

I think this needs some enemy variety, a changing/interactive level or some other incentive for the player to move to different areas of the level. Right now it's effective to just do laps around the level.

Was still kind of fun for a bit. With some variety and more juice/feedback this could be a decent time killer!

Not sure what I'm doing, I've been exploring but nothing other than collecting rocks seems to happen. Fell through the world once, got stuck in a pit another time, got shunted back to the main menu a few times without any indication why. Probably starved, as I only noticed a hunger indicator after a few tries. The UI is tiny.

The game has larger dimensions than the space it gets on the site, so it needs to be in fullscreen to see everything (and interact with the menu at all), but then it's both pillar- and letterboxed such that black bars take up 60% or so of the screen.

Barely playable, so I can't tell how well the idea behind it plays out eventually.

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