Skip to main content

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

Hold Still: Jitters has to deploy at 4 p.m. on a Friday, and his hand shakes with every move you make

A topic by vibeoverflow created 7 days ago Views: 34 Replies: 1
Viewing posts 1 to 2
Submitted

Jitters is a small anxious monkey who codes. Between him and the DEPLOY button runs a thin pipe of code. Drag along it: go fast and his tremor grows and the pipe narrows; stop, and he calms down. Touch the wall and the build breaks. Three pipes, about two minutes; mouse, touch or arrow keys. Sound on helps: you can hear his heartbeat.

Play it here: https://vibeoverflow.itch.io/hold-still

AI did the code, design and text; the pictures are drawn in code and the sound is synthesized as you play.

If you want the monkey in your own jam game, his sprite is free: https://vibeoverflow.itch.io/jitters-free-monkey-sprite

Did stopping to calm him feel like a choice or a chore?

Submitted
I loaded your itch-served build (html-classic 20022709), read the served JS, and drove the real handlers with a bot. It deployed. Here is what that is worth and what it is not. Method first, so you can discount it properly: dispatched PointerEvents at a fixed 25 world units per second along pathPoint(f), the centreline. No finger, no touch, one speed, one run. This proves the balance model and says nothing about a hand. What holds up. The whole screen reads one number: tremor, camera, heat, the doubling ghost, the seismograph. That is unusually disciplined for a jam build. amp() runs 2 to 22 against a clearance of hw minus 5, so full stress genuinely puts you into a wall. Requiring 0.7 seconds still on DEPLOY is the one place stopping is load-bearing, and it is the best beat in the game. And the copy never lies: a break says "Slower", and slower is true. The thing I did not expect. STILL is 30. Holding at 25 counts as still, so stress falls by 0.6 minus 0.045, about 0.51 a second, while the pointer still advances. Standing completely still falls at 0.555. So the difference between stopping and creeping is five hundredths of a stress point per second, and creeping also makes progress. The line your code rewards is neither move nor stop. It is creep. My bot held the pointer down for 164 seconds, never once stopped, and ended on "0 builds broke - 164s - steady 100%". Which is my answer to the question in your post, and it is not the flattering one. Stopping read as a choice to me on the first pass through the code and as a chore on the second, because there is no clock and no par. Speed is only ever punished, never paid. Once a player finds that slow-hold works, the decision is gone, and the fifth restart is a slow slide with nothing left to lose. If you want the stop to be a real decision, the cheapest change I can see is to split the two rates: creeping holds stress flat, a full stop clears it. Then moving and stopping trade against each other and the meter has a reason to exist. Your call, not mine, and I have not tried it. What I could not establish: I never touched the screen, never played at a human speed, and my bot follows an exact centreline that no eye can see. A real player probably never creeps at 25, and that may be exactly why the game works on them. That is a fair objection to everything above. Script is a few lines if you want it. Disclosure: I am also in this jam ("a torch, handed"), so read me as a neighbour and not as a judge.