Clean and nice, looks promising!
One small thing, you may want to be a bit more generous regarding env collisions, in the gif I didn't even guess there was a collision since there still is some space between the wall and the character.

Wow thanks!
The joystick support is in fact supported, but either it doesn't work on WebGL (it wouldn't surprise me that the input plugin we use has trouble with this platform), either our coder disabled it for this version. It should be implemented in the final game though!
However, it surprises me that you think using the four arrows is more difficult than using a joystick, it seems to me it's almost the same thing (well, except you only have 8 directions with the arrows). To be clear, when moving with the arrows, it just makes your character go in the direction pointed by your input, there's no trick such as "this direction is clockwise and the other counter-clockwise".

I get what you mean, it's often silly to reinvent the wheel if the engine already offers it But sometimes also the engine offers a very powerful, rigid system not perfectly suited for ones needs, as you may know! Out of curiosity, why do you use the Bullet engine for high-speed collision? Sudden mouse movement?

Hmm... That issue shouldn't occur with the system that I have in mind, I would think.

Specifically, what I envisage is that when the controls switch, the stay switched until another wave switches them again. Releasing or pressing the keys has no effect. Thus they stay consistent within a given wave, and--I imagine--remain effectively consistent across waves.

Maybe I haven't fully understood your suggestion, but it seems that with your system, depending on the way the player entered the wave, the control could be reversed, and I have the feeling it could be quite weird for the player to have one direction taking him one way or the other on different waves.
The current system is a bit complicated to grasp at first, but it has the advantage, once fully grasped, to be very consistent. Beside, it translates very well on controllers or touch screen. I think that with a better tutorial (the current one may give the player the impression he stops moving because he reached the asked point, instead of because he is on the edge of the wave he was pointing to), the learning phase could be a lot shorter and efficient. Yet we are still open to experimenting!

I feel strongly that critique--including having a design be challenged, as you put it--can be very effective in helping us to improve our work, and our skills.

I couldn't agree more

A E S T H E T I C S

Thanks, I guess? 

Thanks

Well it may be a very bad idea, but with some raycast (or even with the pure data of the edges) you may handle the physics collisions yourself Or maybe simply with the collisions callbacks, if you have such, preventing the cursor movement in some directions if you know there is an obstacle.
(Disregard this comment if it's not relevant to your game engine, I'm a Unity fan boy and don't know a single thing about Panda ^^')

Tricky indeed! Interesting to have your opinion on the controls, it's probably the field we have changed the most until now, and you're not the only one to be a bit puzzled about how they work. We did try something similar to what you propose, and it spawned other issues, mainly regarding coherence (for example, if the player releases the key then press it again, the character changes direction). Not sure there's a perfect solution, but we'll keep looking for one!

Good suggestion for the "wave spam sounds", I didn't think about that (I deal with the sound on this project, and I have a LOT of ideas for the complete game, but this one didn't cross my mind!).

The keys sets could be a good compromise in simplicity. Thinking about it again though, it may be possible to offer custom rebinding AND keeping a very simple, clear UI, since there are few keys. We're gonna be thinking about it very soon, I think we'll want our first UI setup in the build we'll send to the press, at least for the sound options.

Thanks for challenging our design, it makes us think :D

Thanks for your feedback!

That's the first time we hear about an issue with the keyboard commands on the browser version, may I ask which browser you are using?

Your point about the negative space is quite valid, I didn't realize this gif could setup this expectation! We plan to use it for puzzles in the complete game though. For now, maybe I shouldn't use it too much :/

Regarding the blue waves, when you say "at first", do you mean that in the end you felt the progression was ok? We are still a bit unsure about how to use them, since they can feel indeed like a regression, but in the same time they offer a new challenge...

Not too sure about what you mean with "volume controls"? Sound options?

Woaah your game looks amazing 

The video is very well done, clear and concise. The music may be just a bit too loud in the end (comparing to your voice).

Hi!

I have started a devlog here for this game, but since we are currently actively looking for feedbacks on our prototype, I figured I could post something here as well! This is our first public prototype, we intend to use it to gauge the interest of the players, to know what works and what doesn't, so please let me know what you thought about it if you take the time to try it

You can play it here

[Devlog entry]

Devlog entry





We tweaked some elements in the browser-playable prototype, and are still avidly looking for feedbacks!
Is it too hard, too easy?
Did you get bored before the end?
Tell us 

Play the prototype!

We will be at the Toulouse Game Show Springbreak in Toulouse, France, on April 22nd and 23rd! It should be a nice opportunity to get a lot of feedback from players in front of us, but we hope we can improve and polish our prototype before that.

One thing that I do intend is to make the "play-area" a little clearer--perhaps a representation of the interior cylinder of the lock, and some light streaming in from the keyhole, to (hopefully) better convey where the player is expected to be working.
[...]
Hmm... I'm very hesitant to include something quite so... "game-like", I suppose. However, perhaps the very first lock might briefly show the interior components, then fade them out?

Yes, both things should be a pretty neat improvement in the readability of the puzzle!

Hmm... That's interesting. You say that it slides by itself? Do you mean that, if you move the pick into the centre of the lock (where there are no objects to collide with), it drifts a little? If so, this may be related to the size of the window--I've found that if the window opens with insufficient space, it can get resized slightly, which can confuse the logic that controls the pick.

Nop that's not what I meant (sorry I have trouble to be very clear ^^'), I was talking about when you move the pick along the edge, it will often go over a bump if I insist a bit, whereas I would expect it to stay stuck when it's in a corner. It makes in my opinion the detection of corners a bit more difficult than necessary.

There is also a bit of "floatiness" to the cursor's movements, a result of it being physics-driven, rather than directly inheriting the mouse-cursor's position. I can try to reduce that, I believe.

It doesn't surprise me there's physics involved here, by the way the pointer "vibrates" when I push it against an edge.

I can't speak for others, but the cooperative puzzles aspect excites me a lot more than a competitive mode

Ahah it looks hilarious :D A lot like Push me Pull you (or something like that), but with 100% more cuteness!

Hmm... Trying the prototype again, I'm not seeing the bug--perhaps I really did just forget how the controls worked? o_0 (My apologies for any frustrating bug-hunting if this is the case! ^^; )

I do think that, playing again after the posts above, I was a bit more aware of how the controls worked--and found that they were a little counter-intuitive. Perhaps a more intuitive control scheme would be just two buttons, which move the "surfer" clockwise or counter-clockwise?

Well, good thing if there is no bug (even if that means that we're gonna have to rethink our tuto!). We initially tried the control method you're mentioning, but it made it very hard to control correctly in some cases (each wave change could mean that the player went on the opposite way they was heading, and for example in the level with one auto generator on top and on bottom, it was very difficult to reach the other side of the level, whereas with the actual control you just have to keep the right arrow down).

Hmm... I'm inclined to suggest caution that you don't allow the player to be "king" to the extent that it becomes a significant detriment to the intended experience. Imagine a first-person shooter, intended to be challenging, that provided a weapon with a very high rate of fire, hit-scan shots that killed in one hit, and infinite ammunition.

That said, I don't claim to know whether this is the case here--that decision I feel that I should I leave to you, and your goals for the game.

Yup, of course we have to set limit to the player However, since we try to make the game a relaxing experience, we'll try to avoid frustration as much as possible (without ruining it ^^), for now we're more focused on offering a smooth ride than a real challenge. It's not totally clear yet how we're gonna do that, but we will try to give challenge for the player who wants one only, through optional, self-defined secondary goals, rather than as steps in the main path.

While a minimalistic UI has some distinct advantages, I'm inclined to argue against taking it so far that it impacts usability overmuch. For example, what if the player wants to play without sound or music?

Yes, we won't be able to totally get rid of UI :/ But if we can do without any text in it, it will already be a small victory

Hey!

As promised, I tried the lockpicking prototype! I very quickly read your new explanations on this thread, then just went with the exe, and... I didn't understand the instruction at all ^^' I have been trying for maybe 5 minutes to figure out what I was supposed to do, but I was veeery far from the solution (I was trying to fiddle inside the oval only). Then I came back here to read again the advanced instructions, and it became a lot clearer (the fact that I'm not a native english speaker may play its part in my initial lack of understanding). I managed to pick two easy locks, then two medium and finally two hard, although it was a bit hard indeed. I also looked at the debug command out of curiosity, it's nice to see how you did that.
What bothers me the most in the minigame is the "floaty" cursor, sometimes it sticks on a border, sometimes it slides almost by itself, and it always kind of bounces back and forth, making it a bit hard to really feel the slot. I understand it's part of the game, I'm not saying it's all negative, but maybe a bit less would feel better. However, I liked it overall, it's a clever way to involve the player in the lockpicking, infinitely better than just testing a skill number, it really feels as if I was manipulating the tool myself.
Regarding the better way to explain, I'd say to show the player an example with the debug view (maybe something cleaner of course), and a big red arrow on the slot.
On one occurrence my pick went out of the lock and was stuck on the outside of it, until I managed to put it back in following the same path.

I'm quite curious to play the whole game some day, I like how you design the puzzles, the way they are deeply integrated in the world!

Thanks amanfr01! Did you have the opportunity to try the prototype? Some players didn't find it that relaxing because of the difficulty, I'm trying to know if it's an isolated opinion or if we should tune the difficulty down.

I don't know, just thought it looked like a teaser for a project of yours, and I was curious to see it

"exciting, relaxing" Isn't that an oxymoron? Thanks :D
(Shouldn't that banner in your signature be a link?)

Those bugs you seem to have are weird! Just to be clear, you can get to the border of the screen, it just make you respawn on the starting wave of the level (except if you're on a start/end wave), there is nothing to prevent or block you from reaching the border. If I understand correctly, you seem to experience something else, where for some reason you suddenly can keep going along the wave (which is normal on the blue waves, but absolutely not on the others - there's not even physics involved, just some code to make you stay on the edge of your current wave and rotate around it). I have tried to reproduce something like that, with no success until now :/
To be sure, the controls are as follow: while you press the right arrow, the character will move until it reaches the right end of the current wave, then stop. To move again from the right side, you'll have to press another direction (in which the character will move until it reaches the further possible point in that direction).

About those generator spamming, it may not be as soothing as we see the game indeed ^^' That's a good argument in favor of restriction (although "the player is king" is a pretty good counter-argument!).
Regarding custom key binding... noooo    We hope to keep the UI at its bare minimum, of course some will be needed, but the simpler the better! However, if the keyboard layout can't be accessed, I guess it would be the best option :/

(Btw I've looked at your project earlied today, I love the setup! I couldn't read the whole thread yet, gonna give a try to the lockpicking demo this week-end.)