Devlog #3 - A Video Game Is All Out Judging You by Looking at It

The last part was less about “building walls” and more about “bring the physics into play.” Three legitimate quantum concepts converted into game mechanics together with front gates and sound.

Observer Effect (the unique one)

Press O during charging and the game discloses the real probability of passing the tunnel.

The only problem is that if you look at the wall, it means that it has already turned into a wall, so you cannot succeed anyway. Even the slightest observer activity while charging means you cannot reach your goal.

The moment you look at a wall, it acquires a flat gray color, which allows you to see the process happening.

Decoherence (yes, it is once again my research)

If you keep the wall under full charge for too long, decoherence happens. It turns dark purple, a time counter appears, and at about 1.2 seconds later it collapses, meaning your attempt is wasted, the screen shaking and your counter being reset.

Front Door

The game currently has a door in the front.

It is now fitted with a proper title screen that is complete with first controls, allowing one who hadn’t ever played the game to start without the presenter’s assistance.

No operation can take place until a button is pressed, and the stopwatch doesn’t start until a button is pressed.

Audio

All audio signals are produced using code and NumPy.

The sounds emitted are:

• A rising tone for success
• A falling tone for failure
• A flat tone for looking at the failure
• A long falling tone for decoherence

It was done intentionally to make all failure sounds sound different because they have different meanings.

Colors

Now all the on-screen text is written in proper colors, not dark blue-grey but bright cyan, yellow, violet, and green instead.

All pieces of information appeared to be readable at a glance, and each type of information has its unique appearance.

Here Are My Fails This Time

The guard has been in the wrong place.

I put in the check on the barrier charging, but instead of putting the check when the key gets released, I put it when the key gets pressed, leading to the failure of the barrier charging and changing color.

An else statement that followed a wrong if.

The program crashed with a NameError because the variable existed only on the path that had not been executed.

A timer that got stuck.

It stopped counting as soon as I added the title screen to the game.

The parenthesis in the purple shade blend that could have made the game crash with the very first barrier being charged.

The streak that became 1.0, then 2.0, and so on.

The mistake here is that I made it zero instead of dropping the decimal point.

The same trend: the happy path always works, the errors occur on the borderline.

What Follows

Playing the game, tuning up the decoherence timer, and getting the game out.

##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.

Devlog #1 — quantum tunneling but make it a platformer
ok so new Stardance project is cooking 🫡instaed of mario vibes,it would be tunneling, and it’s actually based on real quantum physics not just vibes
wanted to build in Godot but again the same probelm so pivoted to Python + Pygame in VS Code. mildly annoying but also meant I built literally everything from scratch, and this time no indenatation mistake dropped significantly.
The mechanic
Hold SPACE near a wall to charge up, let go to attempt the tunnel. It’s an actual dice roll based on a simplified quantum tunneling formula — more charge = better odds, thicker wall = worse odds, and it’s capped 2%–98% so nothing’s ever a guaranteed W or L. Respect the uncertainty principle 🙏
T = exp(-2 × width × sqrt(barrier_height - energy))

What’s live rn

Charge/attempt state machine per barrier
Barrier glows peaceful blue to mild red as you charge (very “i am becoming unstable” energy)
Green flash = you made it, red flash = physics said no
Two barriers, different thickness, so you can feel the difference
Debug numbers on screen so I could actually verify the math wasn’t lying to me

Bugs i faced and fixed

A font size that needed to be a whole number, not a decimal
A method that got trapped inside init and ceased to exist
An elif chain checking the same condition twice, so half my code was unreachable
A variable I used one frame before it was born

Certified skill issue moments, but each one taught me something real.
Next up
Portal swirl effects (going full Doraemon time-machine-drawer aesthetic), then an actual level instead of two test walls in a void.