##Devlog ##2 – A transition from “two walls in a void” to genuine gameplay
After just 3 hours of development, the game is transitioning from a tech demo into an actual game. Here is an outline of what has been accomplished.

The Juice Mechanic

• Portal swirl – a circular motion of particles going around the barrier which spins faster, the more strength is used. A minute of debugging time was required as all dots were stacking together – I didn’t use the separate angle of every dot!

• Success/fail flashes – a green glow while going through the wall and red if the wall is impenetrable, offering the feedback after successfully completing an action instead of just allowing it to fail without any acknowledgement of it.

• Screen shake on fail – even after failure the player feels the impact and knows about the failure instead of experiencing a total silence.

• Squash and stretch – the player stretches for a little while while moving through the wall, following a basic animation principle.

Making the physics unpredictable for real

The speed of charge and “height” of barriers are now re-rolled after each attempt instead of using fixed values. The game does not allow you to memorize the correct timing (like “holding for 1.4 seconds = guaranteed tunnel”) — it requires you to track the live readout for P(tunnel) every time. The solution feels appropriate for something connected with quantum mechanics, as certainty is not an aim.

Moving from the sandbox to real levels

• 5-barrier gauntlet as opposed to the fixed 2 test walls with the width that is changing in a bigger range.

• Scrolling camera so there is a chance to make the world bigger than the screen. The camera position is derived from the world one, which makes possible separating “world position” (used for all the logic) from “screen position” (used only for drawing).

• World limits so it is impossible for the player just to walk away into infinite empty space. The camera and the player are clamped at the end now with “the end of the line” message.

Creating a game that you can actually lose

• Timed run — random duration for each session (nothing is left out of the randomness of the concept), race to accumulate tunnels before the time runs out

• Restart — press P (as opposed to R because why should we make it easier) and replay without restarting the script

• Streak system — number of consecutive wins would create the multiplier, any loss resets the count back to zero and also a separate best streak record

• Problems I encountered in this session

Firstly, using two elifs consecutively that reference the same event type caused the second elif to be impossible to execute. Surprisingly, I had done this exact mistake two times in one session.
Another issue was a snippet of code that was expected to run in its own right, but instead remained inside if active_barrier. This unintentionally meant that an entire portion of the game over screen would not work unless the character was next to the wall when time ended. It seemed to be a random invisible text bug for too long.
Moreover, I made an indentation error that unintentionally disabled four lines of code after running only once.
Each of these problems was an easy fix once I found them, but it took me a while to do that because testing included edge case scenarios (standing on empty space, failing deliberately, etc.) instead of just getting through the easy way.
Plans for future improvement
I am currently considering adding a question system (a few trivia questions about physics to answer during the charge process) and developing instructions screen to enable players to learn how to play this game even if they never played.