Final Version — AsteroidDestroyer (Canvas Optimized) — Deployed! 🚀

What I worked on:

This is the one I’m most proud of. I rewrote the entire engine using HTML5 Canvas and a requestAnimationFrame game loop — no more DOM divs flying around. The ship, asteroids, UFOs, bullets, and particle explosions are all drawn in pure JS math every frame. This was also my first real experience writing JavaScript, so it took a lot of time to figure out, but I got there.

The result: a smooth, lag-free 60FPS game that stays fast even with tons of enemies on screen. Features include two enemy types (asteroids + zigzag UFOs), particle explosions, auto-shoot toggle, mobile touch support, and infinite level scaling.

The Git & GitHub struggle:

Honestly — Git almost broke me. I kept mixing up branches, overwriting things, and didn’t understand half the error messages. I used AI assistance to get through it, and I’m not embarrassed about that. The AI helped me understand why each command existed, and suggested structuring the commits as a version-by-version story. I thought that was a genuinely smart way to document progress.

Go try it!

🕹️ Play it here → dinithayehan.github.io/AsteroidDestroyer

A gameplay video is also here.

Honest thoughts:

It’s more intense than I expected — level 4+ gets chaotic fast. Auto-shoot turns it into a pure dodge game which feels totally different. UFOs might be a bit too punishing at high levels, but the thruster flame flicker is a detail I’m keeping.

What’s next:

This is deployed but not FINISHED.
Ideas:
highscore screen, wave mode, sound effects, local leaderboard, maybe an online one.
Drop suggestions in the comments or open a repo issue — genuinely open to ideas.

Today was a bigger game-design day because I added combat and basic game progression. I built a start screen, added lives, and then made the player able to shoot bullets upward instead of only dodging obstacles. I also connected bullet collision with asteroids, so now the player can destroy threats instead of just surviving them. On top of that, I added a difficulty increase over time by making the asteroid speed rise gradually, which made the game feel more serious and less predictable. This version felt like a major jump because the game changed from an endless dodging prototype into something closer to a real arcade survival shooter.

I focused on making the asteroid game feel more alive and more polished. I replaced the plain shapes with emoji-style visuals like a rocket for the player, asteroids for obstacles, and an explosion effect for collisions. I also added a moving star background so the game feels more like flying through space instead of playing inside a plain black box. Another thing I worked on was touch support, so the game can be moved on mobile too and not only on keyboard. This version felt important because I was no longer just making the logic work, I was starting to care about presentation and player experience too.

So after the first setup it was all about turning the static layout into an actual game loop. I added keyboard movement so the player can move left and right, then I built falling asteroids that spawn automatically and move down the screen over time. After that, I added collision detection between the player and the asteroids, plus a score system that increases whenever an asteroid successfully passes by. This was the first version that actually felt like a game instead of just a design mockup. The biggest win for me was seeing the score update live and then getting a proper game over when the collision logic finally worked.

Today I did almost finished the project and i almost forgot to update with the devlog. So I am going to fine-tune and update you all with what i did as the steps. To begin,today was mostly about building the very first base for my asteroid game. I started by setting up the main HTML structure for the play area, the player block, and the asteroid block so I could finally see the game layout on screen instead of just imagining it. I also spent time figuring out how to center the game area and make the page feel like a small space-themed arcade screen. Even though this version is very simple, it was important because it gave me the base structure that every later version could build on. Seeing the player and asteroid elements appear inside the game box felt like the first real proof that the project had started

Today I tackled one of the most annoying parts of my data: locations. Storing cities and addresses as plain text meant someone could type ‘Colombo’ or ‘Col’, and it would mess up my queries. I went deep into normalization today, creating a full location hierarchy! I set up tables for Province, District, and City, linking them all beautifully with foreign keys. Now, every station just links to a standard City ID. It was challenging to connect 3 or 4 tables deep, but knowing the data is perfectly structured and safe from typos is incredibly satisfying.

As I kept playing around with the schema today, I started noticing more duplicate data. The ‘Fuel Type’ was just a string everywhere, and I had mixed both service and refueling stations into one table even though they are used differently. I decided to normalize further! I broke out Fuel_Type into its own dedicated table so I could manage fuel names centrally. More importantly, I split the generic Station table into Refueling_Station and Service_Station because they handle entirely different operations. Wrapping my head around restructuring the tables and updating foreign keys was a bit of a puzzle, but my schema is starting to look much more professional and realistic now.

DEVLOG #2
what I worked on:
After the initial thrill of setting up my first database, I realized keeping all station details inside the refilling and service records wasn’t the best idea. If a station’s name changed, I’d have to update it in many places! So, I took my first step into database optimization. I extracted the refilling and service stations into a brand new Station table and linked them up using Foreign Keys. It was tricky getting the hang of relational data initially, but seeing how it eliminated duplicate station names felt like a massive level-up in my database design skills!

Today was all about setting up the data foundation for my Fuel Tracker app. For my App I wanted a mechanism to store data , so I heard about the there are systems called Database Management Systems from the antigravity as I asked to where to begin.. he said form there. And I heard that MySQL is a easily can be learned database so I chose that. So, I officially dove into SQL for the first time! I spent nearly 6 hours installing and configuring the MySQL Server and Workbench. Once the environment was ready, I successfully designed the initial schema to track fuel entries, including fields for liters, cost, and date. Seeing my first database table come to life in the Workbench was a huge win.

I’m working on my first project! This is so exciting. I can’t wait to share more updates as I build.