Game Journal: Rishav’s Pet

I made a little desktop pet that hovers above all open windows, including Chrome. It is a combination of a human face and a machine, with a stitched seam at the middle, one bright eye, and a blinking antenna.

The programming is done with Python and tkinter. The window has no frame and is always in the foreground, and one color is set to be transparent so only the pet is visible. The program does not use any images; instead, everything is drawn directly in the code.

Both eyes of the pet follow the cursor. When the cursor gets close to it, the one bright eye turns from blue to hot pink. Every couple of seconds, the pet blinks. Everything that moves in the application uses the root.after() method, which allows us to run the program similar to a game loop.

Glitches: The eye turned from bright to a tiny dot because the radius was specified incorrectly. The blinking was already programmed, but I didn’t call it within the application to make it work.

Eventually, I created the Windows executable using PyInstaller for easy access.

#Development-Log #6 - The wall counters attacks

I have resumed working on new features as the execution file and the game were successfully submitted. Three new mechanics were introduced and the last one is a boss.

Resonant tunneling

The maximum charge used to be the ultimate solution to every wall situation but not anymore. Now, there is a secret hidden charge point behind every wall. If you release the charge near it, then the success percentage goes to around 95%, which explains the process of resonance tunneling in real devices with double barriers. The transmission through barriers increases at certain energies but not as it has been until now (increasing).

The problem is that the charge point is not observable. If you press O, you see the wall with the flashing charge indicator. Due to this action, you will lose one chance, which is unfair. Still, you will have the knowledge that can be applied the next time you encounter the wall.## Wave position

Tap Q to shift into the wave position. While in this form, you move at half speed and can pass through thin walls; however, you can’t charge while in this state. Press Q again to revert to being a particle, something you can’t do while inside a wall, creating a real choice between the explorer path or speedier route.

Title screen, rephrased

The previously written title screen had become obsolete due to the new controls, so I had to rewrite it as a loop containing various lines. Now, to introduce a new control, all I have to do is add just one line instead of a physically placing the lines.## Boss wall

The last wall is a boss. It’s wide and has three layers:

• Each successful tunnel peels one layer and the wall physically shrinks, from 180px to 120px to 60px, then it’s gone.

• A failed attempt makes it regenerate, and all three layers come back. You need three tunnels in a row.

• Observing it never heals it, so you can scout the sweet spot safely.

• Beating it gives +10 score and +10 seconds.

• It’s the one wall that doesn’t get entangled with another.
  A wide wall’s normal odds are tiny, so the boss is really a test of whether you learned resonance. Finding the sweet spot is how you beat it. It’s still on its own branch so the shipped version stays untouched while the review runs.## Mistakes I made

• I mistakenly entered a line of code meant for a loop into a class method, thus when the game launched, it crashed because the variable was undefined there.

• I referenced an audio file that had not been defined, which caused the game to crash with the first incorrect trivia question answer.

• The code related to the boss wall contained four errors at once: self_defeated instead of self.defeated, pygame.draw_rect instead of pygame.draw.rect, is defeated instead of .defeated, and boss_msg_timer instead of box_msg_timer. Each of these errors made the game crash only when their line was executed, so I identified them one by one at each launch of the game. Next time I will run pyflakes first because it is able to find and let know about errors and mistakes before I actually run the game.

• I pushed the boss wall code into the main branch instead of an appropriate branch. Although I was lucky, because I made the branch after committing the document, I make sure I run the command git branch before committing it next time.

Devlog #5 - Revision phase, mystery boxes and making the game functional

Devlog #4 described the big update regarding gameplay mechanics. This time, it is now about making the game fair, replayable and download-friendly.

Balancing phase

After analyzing the numbers, I found an issue: the height of the barrier can go as high as 2.0 but the maximum energy level is 1.4. Thus, some barriers are literally invincible because it is impossible to break through them no matter how well the player performs. The charge speed also varied from “almost 7 seconds” to “instant charging”, leading to different results every time.

I have put all the variables related to gameplay in one line, so the process of making the game better became much easier.## Highest score

The top score is stored in a small file, which allows it to persist even after you exit the game. The welcome screen displays the score, and if you lose, it says “NEW HIGH SCORE!” on the game over screen. The record is present in the repository, so my score won’t overwrite anybody else’s.

Sound for everything

The ghost, answers in trivia, and entangled transfers didn’t have any sounds. I have added sounds: a sound of the ghost appearing with a whoosh, a sound of a correct answer rising in pitch, the sound of a wrong answer producing low frequency buzz, and a beep sound of a partner barrier charging. All sounds are produced in code without using audio files.

Schrödinger boxes

A few boxes marked as ? are placed between walls. When you click on one box with the help of the button E, it determines what is inside. When you click on the box, the result of what is inside the box is set randomly, which can be either +5 seconds, -4 seconds, or charge for the next wall. Every time a level appears, each box can exist with the probability of 60%.## My ship has been returned.

The review indicated that my GitHub release did not include an executable file, therefore voters were unable to play the game. That’s true that a .py file is not considered a game by anyone who does not have Python installed.

Now I am addressing this issue by using PyInstaller to convert the game into Windows .exe file and adding it to the release. One thing I had to deal with is that packaged game runs from temporary folder and as a result my high score file gets lost every time I run the game. Now it saves in the same folder as the exe file.

Conclusion: If someone has to install anything in order to play your game, most likely, they won’t. Deliver your application the way it can be launched with a single click.

What is next

Complete the release and resubmit it, then let someone else who has never seen the game play it.

Devlog #4 — the walls are real now, and so is the spooky action

We launched the project and moved forward. This sprint has completely redesigned the game dynamics.

Walls that block

Before this point players have only walked through barriers as there was no penalty for tunneling. Now the player collides with walls. If you want to pass the wall, you must use tunneling which will cost you some time and potentially break your chain.

Entanglement that works

My previous iteration of entangled pairs was useless. It only changed the level of difficulty of the partner. With solid walls the simulation did not vary on every run and many pairs did the same thing. Therefore I had to write it again.

• the barriers of the same shape are paired randomly during every run
• when you free a barrier at any point of charge the partner barrier inherits that charge.
• Mirror pairs have the same charge and their partners receive it as well.-The observer lock does not send anything to the partner as forced collapse does not provide any signal. So the order in which you pair now becomes an important decision to make.

The secret is stored in a non-versioned .env file, which has a .env.example alongside in the repository. Now the splash screen features an animated “asking Groq…” message that only goes away once the actual answer provided. ## Quantum phantom
The phantom version of the player appears at a random location, moves through the walls in your direction. The passed wall receives a slight charge. This idea stemmed from ChatGPT, although the first version worked infrequently because it required the ghost to be only up to 24x away from the center of the wall. However, walls can be as wide as 140px, so I made changes to the spawning position of the ghost.

The failure of watching seems different now

Now watching an obstacle and failing does not shake the screen as before. A light freezing-blue light appears instead of shaking the screen since the failure is actually caused by you.## Bugs that caused me trouble

• The ghost class malfunctioned in three different ways: one instance is code at a class level, where there’s no self, second is using camera.x instead of camera_x and third is missing out .choice from random([-1, 1]).
• I misspelled the name of the environment variable with GRQO_API_KEY, causing the game to return “no key found” no matter what action was taken.
• The title screen was stuck on “checking” forever, as the timer never progressed during that time.
• Finally, I experienced a fallback trivia answer being set to index 0, which was incorrect.
• There was a bug when restarting, as the barrier I was standing on before the timer ran out persisted through the next run.
  The trends are clear: while everything works smoothly, bugs persist every time there’s a reset or an edge case.

What I’m planning next

Cleaning up the code and improving the decoherence timer.

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.

In my second devlog, I have completed the entire game since my previous update. Various features have been implemented such as gravity, bouncing, different kinds of balls and collision physics, as well as determining the time needed for the guessing game, and two mini-games called Catch and Dodge. The most remarkable feature, in my opinion, is the sports joke/milestones system. In this system, I connected my scoring levels to real-life events, such as visiting RCB’s matches (49-10), Barcelona’s loss to Bayern Munich, and Germany’s win over Brazil (7-1). As a result, once a score has been reached, the game shows a related message.

Packaging the whole game into an executable file was challenging, as I found out that I had two different Python installations on my computer. As a result, pip and Python send different signals according to the command, and pygame has installed successfully but has disappeared when I tried to build the project. I needed to use the full path to direct my commands to one Python installation.

First devlog Was going to make a game on gadot,but was unsuccessful,got fed up and steak was broken and stickers now lost which were upcoming.Gathered the courage to make a write few lines of codes for a new physics minigames i am working on since i was feeling pretty bored.wrote my first 42 lines of code and got this on pygame and learnt a lot of significance of the indentation during debugging

First devlog Was going to make a game on gadot,but was unsuccessful,got fed up and steak was broken and stickers now lost which were upcoming.Gathered the courage to make a write few lines of codes for a new physics minigames i am working on since i was feeling pretty bored.wrote my first 42 lines of code and got this on pygame and learnt a lot of significance of the indentation during debugging

Added mass and charge to the stimulation working

What happened since last time added a reset buttong and graphical representation the learning still continues

started working on this project,trying to create a visual representation of qubit decoherence on my own