That’s the trailer, and guess what? that’s not a video technically (LOL ask me what it is)

Subscribe now

By now you know I love nostalgia baiting in my stories, here’s a fresh tidbit to start off with. I didn’t grow up in the 80s, and India didn’t really see a tech boom until a couple decades later, so the earliest (and the only) game console in the possession of my childhood self was a “Famiclone”, bought for the equivalent of 15-20 dollars at that time. I never really played the OG Breakout from 1976, the legendary game developed by Steve Wozniak, with assistance from Steve Jobs (seriously) among others.

The version I played, was an obscure clone made by The Foundation Company called Brick Break Classic, from 1999, just a couple years before I was born.

I first started my game dev journey in 2014, when my CS teacher in class announced that there’s a new game jam competition for middle and high school kids in various cities to participate in given a theme within a week. The only game engine I had heard of until that point was Gamemaker. I taught myself unity 4.x, dragged some of my friends into this hobby. We won some, we lost many, but those were interesting and also dreadful times. Lack of resources or tutorials online, lack of creativity on our behalf, and so on.

We tried different things in these competitions. The earliest one I can recall was a first person exploration game, where you’re supposed to traverse grassy terrains filled with Unity’s standard tree assets and such to recover a stolen diamond. There were some interesting ones too, one had the player maneuvering an alien with a battery pack on its back, shoot enemies and survive for as long as possible. Other titles include a racing time trial game, an endless runner, and so on. One time in 2017, I ditched unity entirely and wrote a visual novel with a time loop story based on Source Code (2010) using Ren’py. We made it to the finals and lost to a paid asset flip.

The problem was, the two annual competitions we participated in, really weren’t serious in the same way you can’t really expect middle school kids to make indie masterpieces in a time period where there weren’t nearly as many resources to get into computer science’s toughest domain that easily. All the titles ended up being abandoned the moment the results of the jams were announced, and while my team changed every time, there were a few constants, that I ended up starting a tech company with, but games weren’t part of that venture, for better or for worse.

I didn’t really talk all that much about game dev, because I had to invent some BS to cover the fact that I didn’t even have a portfolio or a single game to show for it. After several years, I told myself, you know what, screw it. I am going to force myself to build a game every month. That was Jan 2023, after I had wrapped up my bachelors degree. I made something I genuinely enjoyed, an alien invasion type game with a fresh ballpoint pen on paper art style. I wish I put it out on itch.io or somewhere then, it’s currently rotting in my old laptop back home in India. The second month, I made a top-down 2D racer, which I abandoned halfway for whatever reason, and never continued with it. The game a month challenge resulted in 1.5 games that year, more than any thus far.

Three years later, my life was dramatically different. Moved countries, shifted goals, life was not the same anymore. New York City changed my mentality when it came to building things, and I realized, people saying “don’t make your dream game first.” did have a point, so I went and told myself, “make something so ridiculously simple that you can’t even have scope creeps”, and returned to a timeless mechanic, the humble Breakout-style brick breaker, and this is what I came up with.

Share

Idle thoughts of reminiscing the good ol’ days made me remember the brick breaker I played all those years back, and I thought hmm, let me make one. I didn’t end up publishing the alien invasion game, maybe I can do another retro classic without falling to scope creep.

I made an interesting architectural decision here, that surprisingly turned out much more helpful than I thought. A few weeks back, I remembered how I used the mood tracker journal - Pixels on my phone during the COVID years and thought, maybe I should build one for Windows? I had never really built desktop apps to modern standards until then, having built FinderPlus with PySide6 during the summer before moving to the States last year, and I was pleasantly surprised with how good Jude - built with Electron, turned out, and I got actual people to use it and got valuable feedback on itch.io. This encouraged me to work on more desktop products, and I followed it up with an absolute banger — a clock that shows percentual time, how much of your day, week, year (and lifetime) has passed already, forcing you to be on your toes in an elegantly shaped way.

But what the heck are you talking about, you ask? Coming to it — It’s the choice to actually NOT use Unity and just build the game with good old Javascript on Electron instead. I was having a blast working with Electron with these apps, and figured a retro arcade game wouldn’t hurt to build web-first, and I can just ship it as an electron based game, bloat be damned. Then, in a conversation with my beloved Claude, I discovered the beauty that is Tauri. A genius Rust framework that uses the OS’ inbuilt Webview2/Webkit library to eliminate the chromium bundling that causes the huge exe sizes in electron apps. I was able to execute the migration cleanly, and the gains were incredible.

Jude and Tokei went from hundreds of megabytes to practically 20x smaller, and I knew I was making the right decision for the brick breaker as well. The prime differentiator of my game compared to the hundreds of breakout clones made over the last 50 years? It would have a context-aware narrator. NOT an LLM, mind you. A classical deterministic work of elegance, if I may say so myself.

The narrator started as a single idea: what if the game noticed you. Not in a scripted, "nice combo!" way, but something closer to a presence that's been sitting in the wall the entire time, mildly bored, occasionally curious, and increasingly less okay with what it's watching. I built it as a state machine, five stages, tied directly to bricks destroyed rather than time elapsed or level number, because I wanted the tone shift to feel earned by what the player actually does, not just handed to them on a timer. Stage one is corporate indifference, the kind of voice that sounds like it's reading from a manual it didn't write. By stage five, it's stopped pretending to explain the rules and started asking questions it clearly doesn't expect you to answer.

I also wanted this mechanic to not just be a gimmick, but combine it with a routine of the game “fighting you back”, with boss battles on every third stage, where the entity starts shooting back. Each boss has a multi-stage health bar and its own attack pattern, and the ball gets faster with every hit it lands, 1.1x each time, resetting only once the boss actually dies. There’s a mechanic I ended up calling “threading,” where the ball clips the exact edge of a brick instead of rebounding cleanly, and instead of bouncing off, it threads through and keeps going, taking out a few more bricks in its path before it finally redirects. I didn’t plan for it, it fell out of the physics naturally, and once I noticed it happening I just decided to name it and let it become a real, repeatable skill instead of treating it as a bug.

The game’s simple, nostalgic, replayable, it tracks your moves and events, and posts badges of honor in the title screen, fully aware, like a roguelite but not really. There’s no high scores to chase, but a momentary distraction from whatever you’re busy doing, that’s probably the aim of BREACH.

From Additional Work, with love.

And yes, Additional Work is a brand new venture, but also, not really. I competed as “Lantern Studios” from 2014-18, and while nothing substantial came of it, this will carry its legacy, with a fresh coat of paint, and “tomorrow’s glycerine included”. Make of that as you will. You can visit our site at additionalwork.quest (yes that’s a domain, try it.)

Get the game on: Itch.io | GameJolt | IndieDB | Website

Leave a comment

Share

Subscribe now

Subscribe now

I switched to CBSE under the assumption that learning science would be more “practical”, but that was not really the case, probably because I was stuck with the pointless dream of wanting to go to IIT, thanks to some early brainwashing. Funny thing is, my parents never forced me, it was all me. I was enticed into enrolling for my school’s JEE coaching system by a fairytale promise of us kids getting Laptops to use in class.

You see, my handwriting sucked. I suppose it was a mix of my left handedness combined with my giant brain processing things faster than my poor hands could handle. I always preferred typing things out. I hated that we had to make paper presentations and such for schoolwork, and, lets just say, if I had a dollar for every mark I lost on a banger of an exam answer just to get marks cut for my handwriting ‘cuz no teacher actually cared enough or had the patience to read responses, especially in English, I would’ve been a thousandaire at the very least.

Anyway, I digress. Going for “IIT Coaching” kind of restricted me from extracurriculars, and also whatever practical education CBSE in general offered, which just got replaced with more classes of Math. I can’t say i disliked math, especially in middle school, that was pretty fun. Physics however, was not my strong suit.

I was okay with kinematics, not great at mechanics, and sucked at electronics. To the dismay of my dad, who would in a few years actually try to convince my bumbling ass to major in electronics instead of computer science, partly because tuition at VIT was significantly cheaper, but still. In 2014, my dad picked up his first Arduino Uno R3, which he’s been smitten with since. I saw him slowly give up nearly every other hobby he had, as he sunk hours and hours into the world of microcontrollers. He unsuccessfully tried to teach me the basics of this, several times over the years, but I was just not into it enough to try to understand, especially since it concerned the branch of physics that I didn’t really like, having preferred Chemistry in general over it.

I did pick up some of the things he taught me, like what exactly a microcontroller was, how the little LED blink was the hello world equivalent and all that jazz, even helped my dad pick out the right Linux flavor for his first Raspberry Pi back in the day. Twelfth grade had a lot of electronics stuff, I was perilous, at one point thinking I might not even pass the board exam for physics. I refused tutoring or help from dad because he’d always start from the absolute fundamentals and I would just give up before he reached the point from which my doubts make sense.

Fast forward a year, I’m in uni, and my nemesis returns in the form of EEE1001, a subject I would scrape by with a B grade. Digital Logic and Design would come in the following semester, and it would be Microprocessors and Interfacing (CSE2006) which would push me to the point where I’d need his help, for the first time since high school. I was sort of short on time, so he’d build a smaller scaled replica of the rover he built for Hyundai’s assembly line earlier that year, an ESP32 Surveillance robot that could be controlled using a web interface.

I would still only get a B considering my performance in the exams, but this tickled my fancy enough that I would independently work on another hardware based project for the Technical Answers to Real world Problems (TARP) module in third year. My team and I built a “smart” walking stick suitable for the visually impaired, complete with an Arduino R3, Ultrasonic sensors, an IR Fallback, a bluetooth module which transmits the detected obstacle’s distance from the end of the stick to a companion android app, which would then use TTS to declare, “Obstacle detected 15 centimeters away”, to the benefit of the user.

Fast forward a few years later, to March 2026, and your boy is on the train back home from New Haven, having had a disappointing outing at Yale University’s flagship hackathon, where, in a flagrant violation of the law, the powers-that-be decided to award one of the prizes to the exact same smart cane project I did as a twenty year old, only, “AI Powered” somehow. I realized that in an era where a lot of the processes involved in honest-to-god software development were being automated, a return to the physical was probably warranted.

Much to the surprise of my dad, I just spent around sixty dollars on Amazon, buying up an ESP32 WROOM microcontroller and a Raspberry Pi 2W. Two ecosystems, a small breadboard, hundreds of LEDs, resistors, cables, etc. later, I had something to start things off with, not to mention a box of assorted sensors, ranging from a joystick input to a tiny OLED display.

The packages arrived, but after a busy Tuesday, the first thing I did when I got back home was hit the sack after a quick catch up with a friend. Voila, we are in the present. I woke up today, not forgetting about the goods, but not motivated enough to get into it first thing in the morning either, until Dad called.

He wanted to see me unbox them, so I did, and then, all the way from Chennai, the man dictated exactly how I’d verify if the controllers worked, and whether everything was good to go. If it weren’t for him, I would have raw-dogged the LED without verification, or plugged the 5V supply into the board and wrecked my Pico day one. Yes, I’m that clueless.

We started off with the classic blink, on the very same Arduino IDE I quizzically stared at 12 years ago on my dad’s tiny notebook. After some board manager setup and library additions, we were up and running, but he didn’t stop there. He got me to pull out the breadboard, and my iPhone decided that autofocus was optional. with the view not resolving, I was haphazardly trying to keep the view steady while tinkering with jumper cables on the other hand, eventually setting up a shiny red LED on the board, after deciding to plug the board in directly because I didn’t have a multimeter to verify the 3.3V situation.

Turns out you have to pair the LED with a 1kΩ Resistor and connect the cathode with the GND of the controller lol, I had no idea, but soon after, one LED became three, and I had a little RGB traffic light situation. He signed off, satisfied that his clueless ward can survive off LLMs if not instructables from this point onward.

I took over from here, fooling around with different patterns, and then with the help of my trusty buddy Claude, started more complex sequencing, and patterns, with intervals and whatnot. What followed was a few hours of genuinely unhinged productivity. Starting from a single blinking red LED, I worked my way up to PWM fading across all three channels. Somewhere at this point I came to the realization that this controller came with onboard wifi, ergo a web interface akin to the one my dad helped make for my rover in college could be developed. Claude spun up a nice little embedded html that I hosted, and showcased to my dad, who had the slightest hint of pride at this point seeing his son slowly starting to figure sh*t out.

One of the pattern sequences that I liked to call “epilepsy mode”, stood out enough that I decided to make that permanent, and now the logical next step would be a trigger. It was at this moment that I discovered that the sensor kit did not come with a HC SR04, the quintessential ultrasonic sensor. I was disappointed, but there was something the kit label just called “Avoid”, which turns out to be a nifty little infrared sensor and receiver board. I figured that I can compensate for the lack of female to female cables by using the breadboard as an intermediary and Macgyvered the sensor, and programmed the LEDs to go from off to epilepsy mode whenever my hand waved a few centimeters in front of the IR sensor module.

Satisfied with the developments, I decided to add another module to the mix, the tiny 0.96 inch OLED display, which took an embarrassingly long amount of time to get working, after multiple library installs and uninstalls. I went with the official Adafruit library and built what I can only describe as the greatest thing to ever come from my mind into the physical reality we find ourselves in. You can view it here.

A crazy meltdown, almost perfectly capturing my mental state sometimes these days, pictured in great glitchy detail on this little contraption, coupled with the strobing LEDs. I had created a work of art in collaboration with my favorite fancy text predictor.

Then I built a tamagotchi. A proper one, with four emotional states — idle breathing with a blink cycle, happy bouncing with floating hearts, scared shaking with a sweat drop, and a full death sequence with X eyes, drooping arms, a RIP screen, LEDs fading to black, and a respawn after three seconds. It also tells the time, sort of.

Then Pong. Playable Pong, on a breadboard, controlled by waving your hand. I wonder if this thing can run doom?

I also demonstrated some of these, in an immensely entertaining video call with my mom and sister, where, to their utter horror, they saw a younger version of my dad from all these years, sitting in that chair on the corner of the room, tinkering with electronics, surrounded by plastic wrappers, cables, peripherals and open boxes with sensors, but now, on video call, straight from Brooklyn, on the other side of the planet.

I never really questioned why I liked drinking Koozh (A fermented millet-porridge drink with incredibly tasty sides) like a 1970s daily wage laborer in rural Tamil Nadu, or how my hair naturally grew wavy, and how I’d never have to worry about going bald unlike some of my more hair conscious peers. Similarly it feels like irrespective of whether I’m good at it or not, I would eventually end up at this point. You can’t fight genetics. We’ll have to see how this one goes. Until then, sayonara.

Share

Subscribe now

Beginnings are weird. You start something because it looks fun, you fumble a ton, and give up. Start something new again, maybe it grows into something, maybe it doesn’t. But the joy of starting something and giving it an honest go. Somehow five years later that never changed.

This post is both confession and a rebuild log. I’m redoing an old idea that I actually prototyped as a freshman in undergrad: a VR maze navigation puzzler used as a learning environment. I helped build the prototype, watched the paper go to conference and then to Elsevier Procedia Computer Science, and watched others do the conference presentation while I sat in the back, mostly owing to the fact that I had no plans of coughing up the dough to register since the uni was not gonna fork it. The old paper, presented at the 2019 World Engineering Education Forum, used a MALAR rubric to track student progress inside a VR learning task. It got 48 citations. That is insane. Also hilarious, because the work on this project was almost entirely mine while some teammates did not even know what a prefab was. That is a true story. The generosity of my prof to put me on fourth behind people that did nothing but volunteer is still the biggest motivation for me becoming a researcher, hoping to make much better stuff now and make my Google Scholar look good.

With that being said,

This time I am rebuilding the maze (entirely from scratch, not an asset-flipping script kiddie anymore, personal growth huh) with a few goals:

1. Make a research-grade platform that is reproducible and instrumented for real experiments.

2. Build a data pipeline that records rich, per-session behavioral telemetry so we can analyze spatial cognition at scale.

3. Create an actually enjoyable experience for the gamers/test subjects.

Below is the full story, the current technical state, and the plan. If you want the code or the logs, I’ll include links and assets when I post the first follow-up.

Short origin story: how I got my only publication so far

I was among a dozen others in the CSE1001 class that volunteered to work on projects because building things is satisfying. I will never be a code monkey, i’d rather use code for its intended purpose, making things. There were two groups, one focusing on gamified learning and the other on VR as a medium for education. The idea: students walk through cave-like VR levels, solve short Python puzzles at terminals to progress, and the system uses MALAR rubrics to adapt and track learning.

My professor called it a “mobile app” because Quest uses Android. Unfortunately I never got to co author the paper itself, so that’s what it says the prototype is, a “virtual reality mobile game”. In a way, I thank God I never ended up finishing it.

The paper got written, presented by the professor at WEEF 2019, and published in Procedia Computer Science. It performed well citation-wise. And yet despite doing most of the implementation, I did not get first author. That sucks, but it also motivated me to actually build something more complete this time.

What I am building now: concrete aims

This is not just a vanity rebuild. The platform is being built to support real experiments. Key requirements:

• Procedural maze generation that is reproducible via seed.

• Configurable visual and physical modalities (lighting, wall heights, lateral noise, biome parameters).

• Telemetry that logs movement, decisions, collisions, hesitation, backtracks, confusion, and timing metrics per session.

• A baseline AI that validates solvability and provides a performance baseline for human runs. (i started this as a tangent, inspired by youtubers that train ai to do game tasks like playing golf etc. but it actually works well as a baseline doesn’t it)

• Experiment modes that change sensory cues and risk/reward.

I am starting with a flatscreen first-pass so debugging is sane. VR integration comes immediately after. I am totally not doing this because my right controller died and I had to leave my quest 2 behind in India, mkay?

Six modes I will implement first

These are not gimmicks. Each mode is meant to probe different cognitive processes. Completely tentative, I will elaborate in further posts.

1. Pitch Black mode - complete darkness except for a directional torch. Tests orientation and memory when visual cues are scarce.

2. Echo mode - no torch, but distant audio beacons hint at the exit. Tests reliance on spatial audio, I might allow an inventory of glow sticks to drop so you know if you’re repeating it.

3. Survival mode - an experimental stress condition. Touch the walls too long and you “die” and respawn. Tests risk aversion and exploration under penalty.

4. Landmark mode - sparse, unique visual landmarks placed in sectors. Tests how participants build landmark-based cognitive maps.

5. Dynamic mode - corridors shift slowly. Tests adaptability and reorientation under environmental change.

6. Baseline - normal lighting, no penalties, maximum data capture.

Every mode is “seedable” and reproducible, so experiments can be repeated and counterbalanced.

The telemetry - what I log and why it matters

I am not collecting random metrics. I designed the logger around hypotheses about spatial behavior, exploration patterns, and confusion. All the params mentioned here are tentative, things will get a lot more complicated later on.

Per session I log:

• Session duration and time to first meaningful step.

• Goal reached flag and time to goal.

• Total distance traveled and average pace.

• Cells visited (unique) and unique cells revisited.

• Revisit percentage: unique revisits / unique visited.

• Idle time: player not moving beyond a small threshold with no input.

• Confusion time: low displacement rate averaged over short windows that indicates dithering.

• Collision count and collision events with timing.

• Backtrack loops: small A-B-A oscillations measured as a 3-step pattern.

• Maze coverage: percent of walkable cells visited.

• Time spent per sector or region for heatmap generation.

• Raw trajectory and sampled head orientation / gaze (if available from headset later).

• Session metadata: seed, mode, complexity, loopChance, biome params.

All sessions are exported automatically to Assets/logs/humanlogs as timestamped text summaries and CSV for analysis.

Important design decisions I made:

• Revisited counts are unique per cell, not additive every time you step on the same cell.

• Confusion is time-normalized: we compute displacement rate over a sliding time window. If average displacement is less than X cells per second, increment confusion time.

• Collisions are reported from a tiny ControllerColliderReporter component attached to the player prefab and forwarded to the logger so the logger can live on a separate manager object.

Some Explanation of the current code:

Short, no-bull summary of the two systems that carry the project:

• MazeGenerator2 (called 2 because 1 is the classic version, proper maze, no variations in walls or biome aware design)

  • Procedural growing tree algorithm with Prim-DFS hybrid.

  • Seed-based Perlin biome parameters that tune frequency, offsets, and wall height ranges.

  • No forced “solid border” code. Maze is a grid with 0 = open, 1 = wall. Visual wall prefabs get Perlin offsets for naturalism.

  • Output: reproducible grid and instantiated geometry.

• RealMazeAI

  • Started as DFS solver, then evolved into a physics-aware agent used for validation.

  • Grid-aware sensing via stacked spherecasts and capsule checks to avoid sneaking through low wall gaps.

  • Behavior: greedily bias toward goal using Manhattan/Euclidean heuristics, plus DFS-style backtracking when stuck, and anti-oscillation nudges.

  • Purpose: Validate solvability and provide a non-human baseline.

Both systems are instrumented to output debug traces and logs for tracing problematic seeds.

What I have accomplished so far (actual milestones)

• Stable, seedable maze generation with biome tuning and safe visual offsets.

• Instance-safe wall instantiation with clamped positive scaling to avoid negative collider warnings.

• A robust human session logger that captures a long list of metrics in text and CSV.

• An Agent that solves most mazes while mirroring human quirks. It was tuned to avoid clipping through walls by using multiple-layer spherecasts and capsule overlap checks.

• Camera tools: top-down free-fly with smooth toggles, and a third-person follow mode that stabilizes on turns.

• Visual experimentation: randomizing materials per wall prefab with runtime adjustments to metallic and smoothness where shader properties exist.

• Data outputs that are ready for exploratory analysis in Python or R.

I will post a follow up with the GitHub link and the core scripts once I clean up a few remaining edge cases and organize the repo.

I did post an elaborate readme on the AI I built to solve the mazes already so you can check that out here.