@anujkishan918

Final Devlog(hopefully :) ):This project taught me a lot more than just how to use Godot.When I started, I thought game development was mostly about writing code and making mechanics work. Somewhere along the way, I realized it’s just as much about knowing when to simplify, when to step away, and when to stop chasing the “perfect” feature.There were days when everything clicked and I made more progress than I expected. There were also days where I spent hours fixing one tiny bug, hit burnout, or even forgot to post a devlog and paid the price for it. Looking back, those moments are just as much a part of this project as the finished features.I’m really happy with where the game is now. It’s gone from a few scattered ideas to something you can actually play, with combat, enemies, checkpoints, UI, and a world that finally feels alive. I even managed to hide a little Easter egg that I hope someone smiles at when they find it.This definitely isn’t the end of the project,just the end of this chapter. More than anything, I’m a lot more confident in Godot and in my ability to build something from scratch.

Devlog #8I completely forgot to post yesterday’s devlog, and that mistake ended up costing me 5 hours. It was definitely frustrating, but I guess that’s part of sticking to a challenge like this—building the game is only half the job, documenting the journey matters too.On the development side, I made good progress despite the setback. I refactored parts of the enemy AI state machine to make transitions between Patrol, Chase, and Attack states more reliable, reducing animation glitches during combat. I also fine-tuned hitbox timings and attack cooldowns so enemy encounters feel more responsive and fair. Along the way, I fixed a few collision issues where enemies could occasionally get stuck against TileMap edges.To keep the project maintainable, I reorganized several scenes and scripts, reducing duplicate logic and making it easier to add future enemy types. It wasn’t the most exciting work, but it made the codebase much cleaner.Losing five hours hurt, but the game itself is in a much stronger state than it was a few days ago. Every bug fixed and every system cleaned up is another step toward the first playable milestone.

Devlog #7: Today felt like a turning point after the slowdown earlier this week. With the scope now under control, I was able to focus on making meaningful progress instead of constantly jumping between unfinished features.I expanded Level 1 by adding new combat encounters and refining enemy placement to create a smoother difficulty curve. I also continued polishing the combat system by improving attack responsiveness, animation transitions, and enemy interactions, making each fight feel more satisfying and consistent.Beyond gameplay, I cleaned up parts of the project structure, removing temporary code and reorganizing scenes to make future development easier. It’s one of those changes players will never notice, but it makes a huge difference when building and maintaining the game.For the first time, the game feels like a complete vertical slice rather than a collection of separate systems. There’s still plenty to build, but the foundation is solid, and I’m getting closer to the first milestone with every session.

Devlog #6The past two days have been rough. I hit a pretty major burnout, which I guess is just part of being a maker. I got caught up trying to implement too many features at once, and instead of making steady progress, I ended up overwhelming myself. To top it off, I lost my 17-day streak, which was a little frustrating.Oddly enough, watching Project Hail Mary helped me reset my mindset. The optimism and overall vibe of the movie reminded me why I enjoy building things in the first place. Sometimes stepping away for a bit is exactly what you need.With a clearer head, I decided to scale back a few features and focus on what actually matters for the first milestone. That decision has made development feel much more manageable, and I genuinely think the game is now very close to reaching that milestone.I also snuck in a small secret Easter egg that I hope players discover and enjoy. It’s a tiny detail, but I think little surprises like that make a game feel more memorable.

Devlog #5 Not a huge development day, but I made some quality-of-life improvements. I designed the game’s starting UI and also refined the existing boss fight interface to make it cleaner and more consistent with the overall visual style. Small UI changes like these go a long way in making the game feel more polished.Tomorrow, I’ll get back to gameplay development and continue working on Level 1.

Devlog #4Today’s work was focused on refining the first combat encounter rather than adding lots of new content. I expanded the enemy AI by improving its patrol and chase behavior, making transitions between states much smoother and more predictable. I also spent time adjusting hitboxes, attack ranges, and movement speeds so fights feel fair while still requiring good timing from the player.I added the first environmental obstacle to the level and made sure it integrates correctly with the existing TileMap and collision layers. Most of the day, however, was spent debugging. Small issues like animation interruptions, collision edge cases, and state transitions took longer than expected, but fixing them has made the gameplay feel noticeably more polished.While Level 1 is still a work in progress, each iteration is making the core gameplay loop more enjoyable. My next goal is to add another enemy type and continue building out the encounters so the level gradually introduces more challenging combat scenarios.

Today was all about bringing Level 1 to life. After finishing the layout yesterday, I shifted my focus from building the environment to implementing gameplay. I integrated the first enemy into the level, created its AI state machine, and connected it to the player’s combat system so encounters now feel like actual gameplay instead of isolated mechanics.A significant part of the day went into tuning collision detection, attack timing, and animation synchronization. Since the player now has both light and charged heavy attacks, I had to ensure the enemy reacts correctly to different attack windows without breaking the animation flow. I also refined the checkpoint logic so the shrine is now properly integrated into the gameplay loop.What I’m happiest about is that the project is finally starting to feel like a game rather than a collection of individual systems. The combat, movement, checkpoint, and level all exist together in a single playable experience. Tomorrow I’ll focus on expanding enemy behavior, adding more encounters, and introducing environmental obstacles to improve the pacing and challenge of Level 1.

Devlog #2Today was mostly spent fighting the software rather than the hardware. Arduino Lab turned out to be much more challenging than I expected because many of the libraries I needed were originally written for older AVR-based boards. Fortunately, most of them weren’t completely incompatiblethey usually just required a few small changes to the source code. The catch is that Arduino doesn’t let you modify installed libraries directly, so I had to clone the repositories myself, place them in the correct location within the filesystem, and patch them manually before I could even start debugging. It was frustrating at first, but I ended up learning a lot about how the Arduino ecosystem and its library management actually work under the hood.On the UI side, I experimented with the new Bricks implementation and built a dashboard that displays live sensor readings along with other useful information such as notes and system status. The feature I’m happiest with, though, is the display loop I wrote. Instead of showing a single static screen, the interface now automatically cycles through different pages, making much better use of the limited display space without requiring any user interaction. It feels polished, works exactly as I imagined, and is probably my favorite improvement I’ve made to the project so far.

Today was one of my biggest learning days with Godot so far. I spent most of my time understanding how the engine handles player mechanics, animation state transitions, and level construction, and I am very happy with the progress I made.The achievement I’m most proud of today was creating and integrating a completely new charged heavy attack for the player. Instead of simply reusing an existing animation, I designed a custom pixel-art sprite sheet that matches the style of the rest of the character animations and successfully integrated it into my animation state machine. I updated the player controller to support a dedicated HEAVY_ATTACK state with its own animation timing, input handling, and state transitions, ensuring it behaves independently from the normal attack combo while remaining compatible with the rest of the combat system.On the level design side, I completed the entire layout for Level 1 using Godot’s TileMap system. This involved constructing the full traversable floor, shaping the terrain, and ensuring the level can support future gameplay systems such as combat encounters, checkpoints, and environmental hazards. Moving to a TileMap-based workflow has already made level creation significantly more efficient and scalable compared to manually placing collision objects.Although the level is not yet populated with enemies, I implemented the first checkpoint by placing a shrine/statue that will serve as the player’s respawn point. Since checkpoint systems are a core part of Souls-inspired games, getting this foundation in place was an important milestone for the overall gameplay loop.Tomorrow’s goal is to begin populating the level with enemy AI, obstacles, and combat encounters. Once those systems are in place, Level 1 will become fully playable from start to finish, allowing me to start balancing exploration, difficulty progression, and combat pacing.

Devlog #1 — Finally Starting My First Godot GameI’ve finally started working on my first 2D pixel art game with Godot. The idea for this game has been in my head for a long time. It’s based on a part of Greek mythology that doesn’t get talked about very often, and I’ve wanted to turn that story into a game for years. But before I could even think about making that game properly, I knew I first had to learn how to make games.Most of my time this week actually wasn’t spent inside Godot. It went into all the background work that people usually don’t see. I spent hours finding, generating, and organizing pixel art assets, making sure they worked well together and were all roughly the same style and scale. I sorted everything into folders for characters, enemies, tilesets, UI, backgrounds, and animations so the project wouldn’t become a mess later on.Learning Godot was honestly harder than I expected. I watched quite a few YouTube tutorials and read different guides, but I always felt like I was just copying what someone else was doing instead of understanding it. What finally helped was Godot’s own Learn to Code with Godot course/app and this one is really hands on . It starts with the basics and slowly introduces GDScript, nodes, scenes, signals, variables, loops, and functions. After working through it, I finally felt like I understood why things worked instead of just memorizing code.Once I felt comfortable enough, I created the project, imported all of my assets, set up the project for pixel-perfect rendering, and gave it a temporary (very goofy) name that will definitely change later. I also built a simple title screen and a basic HUD. One of my favorite moments was getting the menus fully navigable with just the keyboard—it made the game feel like an actual game instead of just a collection of sprites on the screen.This first milestone wasn’t really about gameplay. It was about building a solid starting point and getting familiar with Godot’s workflow. Even though there isn’t much to “play” yet, I learned a lot about how scenes are structured, how nodes fit together, and how everything in Godot connects.Next, I’m moving on to the second milestone, where the real fun begins. The plan is to build the first playable side-scrolling level inspired by games like Dead Cells. I’ll be focusing on the core mechanics player movement, jumping, collisions, animations, camera movement, enemy behavior, combat, and interactions. If I can get those systems feeling good, I’ll have a strong foundation to start building the rest of the game on.

This update was all about making the game feel complete instead of simply adding more content. I spent most of my time refining mechanics, balancing gameplay, and improving the overall player experience.

The feature I’m most proud of is the new parry system for boss fights. Players now have to react within a small timing window by holding Shift to reflect incoming attacks back at the boss. Getting the timing right took a surprising amount of testing because I wanted it to reward good reactions without letting players spam it, so I added a cooldown and carefully balanced the mechanic until it felt fair.

I also introduced three different game modes, each changing how the game is played instead of just increasing difficulty. To help new players understand everything, I built an in-game tutorial that walks through the mechanics before gameplay begins, while still allowing players to revisit it later if needed.

Beyond that, I polished the experience with independent music and sound effect controls, hid a few easter eggs around the game, balanced enemy behavior, and improved the overall feel of combat with better audio and gameplay feedback.

Most of the artwork comes from the Pocket Mortys sprite sheets, so my focus throughout this update was on programming the gameplay systems and making them work together smoothly. Looking back at the first version, I’m happiest with how much more polished the game feels now, and I hope players enjoy mastering the boss fights and discovering all the little secrets hidden throughout the game.

In the process of developing gameplay, the first thing that had to be done was getting the visual assets. Mostly, the Morty sprites were taken from the website called The Spriters Resource using the sheet of Pocket Mortys sprites, which contained various unique characters that would be suitable as falling enemies. The large sprite sheet was manually sliced into separate transparent PNGs, but only the most identifiable Morty variants, including Wizard Morty, Pizza Morty, Ghost Morty, Dracula Morty, and Evil Morty, were selected in order to allow the player to distinguish enemies easily. The visual assets are referenced as placeholders for a hobby project. Rick, the pickle projectile, and some UI elements are from the open-source project itself.Now that the assets were prepared, the development process revolved around creating a minimal and viable playable prototype. The first prototype featured a game screen where there was a Rick that was fixed to the screen and could move using a keyboard. Also included were the enemy Morty who would fall from above, the upward-firing pickles, bounding box collision detection, and the game over when all the lives were lost. This prototype was purposely kept very basic since the goal was to determine whether it was fun to dodge and shoot the falling Mortys before adding any more features. At this stage, a bug relating to collision detection which was as a result of an incomplete overlap was noticed, but was not realized until later.

This phase added the startup mascot — got Rick & Morty standing above the portal in the intro screen using pure CSS. Experienced a little issue with the alignment which I discovered later. There was still a hanging translateX(-50%) that was pushing the mascot aside. Removed the line of code and got the exact alignment with the help of the sliders (X, Y, size). Got to the desired values translate(60px,-138px) scale(0.76) and removed them right away. Rewrote the intro animation logic as well — it automatically skips after some seconds, now it will play when loaded and wait for a tap to proceed. I have experimented with making a window similar to the macOs one (traffic lights and title bar) but did not get it in time, so I reverted it.

The last part was related to the sidebar and its Pickle Rick icon. Made the sidebar collapsed into the narrow column with the rotating portal ring logo which opens and closes it. Updated the Pickle Rick image by making the design more precise (added his body, spots, teeth and tongue) and got the exact location using the same sliders technique. Made Rick’s face fade into the black instead of clashing. Last thing hooked it into the existing “annoyed” mood detection,

Fully over hauled the UI and added a pixel art intro story.

This phase added the startup mascot — got Rick & Morty standing above the portal in the intro screen using pure CSS. Experienced a little issue with the alignment which I discovered later. There was still a hanging translateX(-50%) that was pushing the mascot aside. Removed the line of code and got the exact alignment with the help of the sliders (X, Y, size). Got to the desired values translate(60px,-138px) scale(0.76) and removed them right away. Rewrote the intro animation logic as well — it automatically skips after some seconds, now it will play when loaded and wait for a tap to proceed. I have experimented with making a window similar to the macOs one (traffic lights and title bar) but did not get it in time, so I reverted it.

The last part was related to the sidebar and its Pickle Rick icon. Made the sidebar collapsed into the narrow column with the rotating portal ring logo which opens and closes it. Updated the Pickle Rick image by making the design more precise (added his body, spots, teeth and tongue) and got the exact location using the same sliders technique. Made Rick’s face fade into the black instead of clashing. Last thing hooked it into the existing “annoyed” mood detection,

Phase 4 Devlog — Deployment & Voice Reliability

Phase 4 was less about the face and more about getting the thing actually reachable and sounding right. Three separate problems, three separate fixes.

1) GitHub Pages was never going to work

Deployments sat in deployment_queued and timed out, over and over, on totally unrelated repos. Turned out it wasn’t a config issue at all — GitHub’s status page had an active incident open the same day (“Incident with Pages,” degraded performance, investigating). No amount of poking at Settings → Pages or the Actions tab was going to fix an outage on their end. Moved hosting off Pages entirely rather than wait it out.

2) The Fish Audio proxy needed its own home

The app calls out to Fish Audio for Rick’s voice, but the API key can’t be trusted client-side and Fish’s endpoint doesn’t play nice with browser CORS anyway. Solved both with a small Cloudflare Worker that does one job: accept a POST to /tts with fishKey, text, and a few optional params (reference_id, format, model), forward it to Fish Audio, and hand back the raw audio bytes.

The frontend already had the right shape for this call, so it was mostly a matter of getting the Worker’s workers.dev subdomain toggled on — it silently doesn’t activate until there’s an actual deployed script behind it, which cost a bit of head-scratching before the first real deploy went through.

3) Voice playback was getting blocked, then falling out of sync

Two separate bugs stacked on top of each other here.

audio.play() was firing after an await fetch(), and by then Chrome no longer considered it tied to the user’s original click — so playback silently failed with a permission error. Fixed by unlocking the page’s audio system on the very first click/keypress/tap anywhere, which browsers treat as valid for the rest of the session regardless of how much async work happens in between.

Once audio was actually playing, timing was off. There’s a fallback timer that force-reveals Rick’s reply text if the voice hasn’t started yet, originally set to 6 seconds. Fish Audio’s real-world response time runs closer to 8 seconds, so text was popping up two seconds before the voice caught up — reply and audio landing noticeably out of step. Bumped the fallback specifically for Fish voice mode to 15 seconds, leaving the faster browser-TTS and text-only modes untouched since they never had the delay problem to begin with.

Net result

The app deploys somewhere that isn’t at the mercy of a GitHub outage, the voice proxy has its own dedicated backend instead of leaking a key client-side, and audio no longer gets blocked or races ahead of the text it’s supposed to accompany.

Phase 3 Devlog — Face & Layout Polish Phase 3 added a handful of new facial states on top of the existing set (talking, angry, blink, thinking, sleep, surprised): manic, disgust, and exasperated. Each is just CSS — scaling the unibrow, eyes, and mouth per state and letting the existing transition properties handle the interpolation. They’re wired into guessMood(), so the reply text picks which one fires.The main bug was in the pupils. Bumping their size seemed trivial, but the original CSS used a multi-offset box-shadow to fake small catchlight dots around the pupil, and none of those shadow values had an explicit color. Browsers default an unset box-shadow color to currentColor, which here was the page’s neon-green text color. Scaling the pattern up didn’t just make the pupil bigger, it made a glowing green blob visible around it. Fixed by dropping the multi-dot trick for a single solid pupil with one inset highlight — simpler, and it scales cleanly.There was also a first pass that auto-cycled through every state on a timer so they’d show up without an API key connected. It conflicted with the actual reply-driven logic, so it got pulled — states now only ever fire off a real message, same as talking and surprised always did.A second bug turned up after that: the auto-blink loop was resetting the container’s full class list on every blink, which incidentally wiped out whatever mood state a reply had just set. Since blinks fire every 2–6 seconds, this meant states were getting cut short or skipped entirely. Fixed by having blink toggle its own class instead of resetting the container.Smaller changes: the chat history panel moved to the leftmost column, the unibrow got nudged up slightly to give the bigger pupils more room, and the inaccurate relative timestamps (“3m ago”) on chat list items were removed in favor of just showing message count.

Phase 2 Devlog — Voice IntegrationPhase 2 was all about giving Rick his actual voice using Fish Audio, which hosts a Rick Sanchez voice clone model. The first problem hit immediately: Fish Audio had quietly updated their API. The old speech-1.5 model name passed inside the request body no longer worked — Fish Audio now expects the model as an HTTP header (model: s2.1-pro-free), and the model names themselves had changed entirely. Once we figured that out and stripped the invalid body parameters, the request was clean. But Rick still wasn’t speaking.The bigger wall was CORS. The moment a browser fetch() call sends an Authorization header to a third-party API, the browser fires a preflight check — and if the server doesn’t explicitly whitelist your origin, the request gets blocked before it even leaves the browser. Fish Audio’s API is designed for server-to-server use, so no frontend origin gets through, whether you’re on localhost or a real GitHub Pages domain. There’s no client-side fix for this. As a temporary workaround we wired in the browser’s built-in speechSynthesis API, tuning the pitch down and slowing the rate to approximate Rick’s drawl. It worked, but it obviously wasn’t Rick.The real fix was a Cloudflare Worker acting as a one-file serverless proxy. The insight is simple: CORS only applies to browser-to-server calls, not server-to-server. So the browser calls the Worker (which is on your own domain, no CORS issue), the Worker forwards the request to Fish Audio privately, and streams the audio blob back with open CORS headers. The whole proxy is about 60 lines of JavaScript, deploys in two minutes from the Cloudflare dashboard for free.