Building something because you’re curious is one thing. Building something because your brain literally refuses to learn any other way is a different kind of desperation.
I’ve never been able to learn from a 20-minute "Intro to Java" video. I can’t do the "read this 400-page documentation" thing. Between the ADHD and the social anxiety, my brain just... shuts down. My brain is like a 2005 Dell all-in-one budget office PC, its somehow still works but takes a while, for me a keeping focus on one thing at a time is like trying to run a high-end game on a GPU that’s thermal throttling; the harder I try to focus on a screen full of text or a person talking, the hotter the "noise" in my head gets until I just have to walk away. My internal "task scheduler doesn't know what task to prioritize, almost like the procrastinating curiosity rover on Mars, I mean if a mission critical, ~250 mil dollar project, with most advanced robotics and tech humanity ever build, built by the smartest people at that time still have trouble focusing then why can't I?
This project, this messy, vector-math-filled Asteroids clone, was my attempt to stay above the water. When the depression starts pulling you into that downward spiral, the only thing that helps is the rigid, unforgiving logic of a compiler. Code doesn’t care about your mood. It just cares if you forgot a semicolon.
The Architecture of a Distracted Mind
When I started, I had zero experience in game development, I didn't know what a game loop was. All this time I was developing software for real world application like servers and client systems, these applications has like 0 math involved. I just knew I wanted to move a triangle on a screen. Looking back at the early v0.0.1-alpha release, the progress from a single moving sprite that resembles a spacecraft and circles turned polygons that looks like Asteroids to a refactored system is night and day.
I designed the architecture the only way that made sense to my brain: Isolation. Because I struggle with focus, I couldn't have one giant file, unlike the other processing sketches. I had to break it into pieces I could "see":
- The GameManager: The "brain" that handles the transitions between states like
MENU_MAIN,PLAYING, andLEVEL_TRANSITION. - The PhysicsHelper: The "mathematician" that doesn't care about the game, only about screen wrapping and coordinate conversion, and checks if some object hit some other object.
- The CollisionMechanics: The "referee" along with the help of PhysicsHelper that decides if a laser hit an asteroid or if the ship just turned into space dust.
- The AsteroidConstants: People in the developer community doesn't credit or appreciate the existence of constants files enough, I mean yeah, its a pretty straight-forward, a static class with final static variables preserving Constant values, Imaging opening your IDE one fine day and wondering why did I put this Magic number and the same values are required in the due to the same reason, for me its nightmare fuel.
- The Loggers: Don't get me wrong I kind of like programming in processing, although its not a full fledged Game-engine, its still a pretty solid tool to write visuals based programming Like I wrote some 7 or 8 music visualizers with it back in the day. The absolute lack of debugging and native logging support is abysmal, now before anyone comment yes I know there is a debugger that comes with the Processing IDE , But its user-unfriendly at the most, Buts its open-source at least, and I use the VSCode for writing Processing Sketches. Anyways back to the main topic, Loggers, I had to write a new class for JSON-like logging just to have some semblance of a debug trail, It may not be perfect, but its get the job done, maybe I can use the same logger class in my next projects or something.
I wrote the core logic, the stuff that actually makes the game feel like a game, myself. But for the repetitive, soul-crushing boilerplate (the accessors, the standard getters and setters), I outsourced it to AI. It felt like having a junior dev who never gets bored. While I was obsessing over why an asteroid wasn't wrapping around the screen correctly, the AI was churning out the repetitive setParent() and getTFont() methods.
A Blessing in Disguise: CodeRabbit
The real game-changer wasn't just the AI writing code; it was the AI reviewing it. Using PR review tools like CodeRabbit AI felt like a safety net for my social anxiety. I don't have to worry about a human judging my "stupid" mistakes or my erratic commit history.
The automated reviews caught things I missed—like NaN prevention in the physics engine. There’s a specific block in Asteroids_PhysicsHelper.pde where I had to handle asteroids being exactly on top of each other. If the distance is zero, the math breaks. The review process helped me realize that "math-wise," I was about to divide by zero and crash the entire JVM. There was the port where I have to use an epsilon value, i.e. A value that is very small but non-zero and it helps prevent floating point errors due to IEEE 754 standard, apparently computer are very bad at keeping comparing decimal numbers aka fuzzy comparisons, I mean I knew that computer are bad at floating point math, but this is my first time experiencing the issue and implementing the fix, again CodeRabbit came to the rescues here.
The "Arcane Rituals" of Magic Numbers
If you look at Title_Screen.pde, you’ll see some... aggressive comments. I wrote those because I spent hours at 2:00 AM trying to get the buttons to align perfectly.
AUTHOR’S NOTE — READ AND OBEY: These numbers were obtained through forbidden means. They are the culmination of arcane rituals performed at ungodly hours... Do NOT ask how they were derived.
I call them "forbidden means" because, honestly, I didn't use a layout engine. I used trial and error. I changed a 4.05 to a 4.06, hit run, sighed, and changed it back. Those numbers are the physical manifestation of my ADHD hyper-fixation. If someone touches that getParent().height/2.03 value, the binding circle breaks, and I might actually lose my mind.
The Hard Part: Vectors and physics Logic
The hardest part was the physics. I didn't want the asteroids to just pass through each other; I wanted them to bounce. I had to learn about coding the conservation of momentum and elastic collision on the fly. I ended up using a formula for elastic collision:
v1_new = v1 - [ (2 * m2) / (m1 + m2) ] * [ dot(v1-v2, p1-p2) / magSq(p1-p2) ] * (p1-p2).
The math for calculating the dot products and the scalar velocity changes was the most mentally taxing part of the project. But there's something incredibly satisfying about seeing two vectors finally interact correctly. It’s a level of control I don't feel in my real life.
Even the asteroid spawning is a bit "extra." I used a logarithmic scaling formula: count = INITIAL_ASTEROID_COUNT + Math.log(Math.pow(level, 4)). Why? Because I wanted the difficulty to curve smoothly. I even left a comment in the code: "It's not like we're doing anything complicated here... b-baka!".
Documenting the Pursuit
Coding is the only time the noise in my head goes quiet. When I’m deep in Collision_Mechanics.pde, deciding if a big asteroid should insta-kill the player (it does, and it gives you a score penalty because I can be an "asshole" developer), I'm not thinking about my anxiety. I'm just thinking about the state of a Spacecraft object.
This project isn't perfect. I'm worried that at level 100, the 92 asteroids on screen will be so crowded and worst-case the performance impact with this many object interaction and its calculation, the game may becomes unplayable after a certain level. I'm still looking for solutions—maybe a Quad Tree. But for now, it's mine. It's a collection of logic, magic numbers, and "fuck you" comments to any player who tries to traverse an undefined code path.
For anyone else whose brain works a bit differently: stop trying to watch the videos. Just start a project, break the physics engine ten times, and write some witty comments in your source code. It’s much better than the alternative.