Activity

oggythebuilder01

Shipped this project!

“Hey everyone! As this is the final devlog for Pixel Beast, I just want to say a massive thank you for following along. Building this 2D game has been an amazing journey, and your support made it all possible. I can’t wait for you to finally play it!”

oggythebuilder01

Project Completion Report: Final Build
This document marks the final release of the project developed using the Godot Engine. All core mechanics, levels, and the final boss encounter have been successfully implemented.

⚠️ Performance Note
Initialization Delay: Upon selecting ‘Start’ or ‘Play’ from the main menu, the system requires a few seconds to load assets and initialize the game world. Please do not close the application during this period; the game will begin shortly.

🕹️ Technical Specifications: Player Controls
The following table outlines the input mapping for the game. Please refer to this guide for navigation and combat:

Attack key E ,V ,enter, return, Primary attack and menu confirmation.
Jump Space Character jump mechanics
Movement Arrow Keys Horizontal character navigation.

🛠️ Development Summary
Engine: Godot

Status: Version 1.0 (Stable)

Key Features: Integrated Boss , polished UI, and finalized input handling.

This game is a reflection of my growth as a developer. Thank you to everyone who followed the progress. Now, go ahead, hit play (and give it a second to load!), and enjoy the world I’ve built.

See you in the next project!

0
oggythebuilder01

“I finished the UI design and have been busy testing the game and fixing bugs. I also tried adding some new animations/features to spice things up. It’s looking good! Now, the only thing left is the Boss.”

0
oggythebuilder01

I’ve been playtesting the game a lot and fixing bugs to make everything feel smoother. I balanced the scorpion swarm areas so they aren’t too annoying, and I’m currently redesigning the boss frames to make them look better.

Since I’m short on time, I’m focusing on the core gameplay and skipping the health bar for now. It’s finally starting to come together!

Attachment
0
oggythebuilder01
  1. The Scorpion Swarm (Attack Zones)
    I have implemented new “Attack Zones” using collision detection. When the player enters these specific areas, a swarm of Scorpions will suddenly emerge.

The Mechanic: Individually, these scorpions deal minimal damage, making them easy to survive if you’re quick.

The Challenge: The real danger lies in their numbers. I’ve tuned the spawn rate to create a “pressure” situation where the sheer quantity of enemies can overwhelm the player if they don’t clear the area fast enough.

  1. Scripting & Enemy Placement
    I spent some time cleaning up the Godot scripts to ensure the spawning logic is efficient and doesn’t cause performance lag during high-entity counts. Additionally, I’ve mapped out several enemy placements across the current levels to balance the difficulty curve.

  2. Boss Redesign
    The Main Boss is currently under construction. I wasn’t entirely happy with the original animation frames—some of the movements felt off—so I am back in the design phase to polish those frames. I want the boss to feel impactful and visually distinct, so taking the extra time to get the “feel” right is a priority.

  3. Project Constraints & UI
    Due to tight time constraints, I’ve had to make some tough “triage” decisions regarding features.

Current Status: Enemy setups are mostly complete.

The Trade-off: I likely won’t be able to add a dedicated Health Bar system in this current sprint. I’m focusing more on core gameplay stability and enemy behavior before polished UI elements.

0
oggythebuilder01

The session started with a harsh reality check: the project folder had become a disorganized mess. Storing assets, scripts, and scenes without a strict hierarchy led to broken dependencies and insoluble scene corruption.

Dependency Recovery & Rebuilding: Several crucial files had been accidentally deleted or corrupted. I had to manually recover these and rebuild the broken .tscn (scene) files from scratch.

Asset Purge: I completely scrubbed the project of old enemy sprites, outdated animation files, and redundant scenes.

The Lesson: In Godot, treating your file system like a “garbage dump” inevitably leads to broken resource paths and missing dependencies. Organizing assets into a strict modular structure drastically reduced the engine errors I was facing and optimized the project’s load times.

  1. The Enemy Scripting Roadblock: The Case-Sensitivity Trap
    A significant portion of the scripting time was dedicated to coding the behavior for the newly designed enemies. However, I hit a massive wall with the detection logic.

The Null Instance Bug: The enemies were completely failing to detect the player character. After deep-diving into the script, I traced the bug down to a single character: Case Sensitivity.

Technical Breakdown: In the Godot script, I was referencing the player node using a capital P (e.g., Player), but the actual node in the scene tree was named with a lowercase p (player). Godot’s node path system is strictly case-sensitive. This mismatch returned a Null instance, breaking the entire detection loop. Once fixed, the tracking logic instantly snapped into place.

Sensor Nodes: To enhance the enemy behavior, I implemented Godot’s sensor nodes (utilizing Area2D and RayCast2D mechanics). This gave the enemies proper spatial awareness and collision detection without relying on heavy physics processing. Surprisingly, integrating the sensor logic went very smoothly with no major hitches.

  1. Kinematics & Animation State Machines
    Moving a character is easy; making it feel good is hard. I spent a solid 1 to 2 hours purely focused on the player character’s visual feedback.

Refining Movement: Tweaked the character kinematics to ensure acceleration, friction, and jumping felt tight and responsive.

Animation Polish: I dug deep into the character’s animation frames. By adjusting the frame rates and smoothing out the transition logic between the idle, run, and action states, the character movement now feels vastly more natural and grounded in the 2D environment.

  1. Environmental Rendering, Lighting, & Hazards
    With the logic running smoothly, I shifted focus to the game’s atmosphere and environmental design, specifically focusing on the Cave level and the final ending sequence.

Color Grading & Illumination: I spent several hours dialing in the color grading and complex lighting setups to give the environment a distinct, moody atmosphere. This involved adjusting ambient 2D lighting and shadow casting to make the visual layers pop.

Level Design (The Cave): Expanded the cave design, focusing on creating a unique visual language for the game’s final ending sequence so it stands out from the rest of the levels.

Kill Zones: I programmed and implemented “Kill Zones” (hazard areas using Area2D overlap signals). The script successfully detects body_entered signals from the player, triggering the correct death/reset state seamlessly.

  1. UI Prototyping & Documentation
    The final stretch of the session was geared towards the Front UI and technical research.

CanvasLayer & UI Nodes: I began laying the groundwork for the Front UI using Godot’s Control nodes. However, sourcing the right UI elements and setting up the anchors proved time-consuming. It’s still in the early prototype phase and will be the primary focus of a future session.

R&D: Spent a good amount of time reading through Godot’s official documentation to better understand scripting best practices and node management.

Attachment
Attachment
Attachment
Attachment
Attachment
Attachment
0
oggythebuilder01

The Technical Wall
This week, my progress on “Pixel Beast” hit a massive roadblock. While I’ve been trying to get the Enemy AI to actually work, I’ve been bombarded with errors that have brought development to a standstill.

The Specific Hurdles:

The “Invisible” Player: I spent hours wondering why my enemy wouldn’t attack, only to realize my RayCast2D (the enemy’s “eyes”) was pointing straight into the ground instead of at the player.

The Infamous “Null Instance” Error: I’ve been battling a persistent error where the engine refuses to recognize the nodes in my script. Even when everything looks right in the Scene Tree, the code keeps claiming the objects don’t exist.

Script Type Mismatches: I ran into a frustrating issue where scripts meant for an Area2D (like my Kill Zones) were conflicting with the CharacterBody2D logic of the characters.

Signal Failures: Trying to get the game to reset when a player falls or gets hit has been a struggle because the signals between the nodes and the script just weren’t connecting as they should.

The Mental Toll
To be honest, I am completely overwhelmed by errors this time. I have no words left to say. When you’re staring at a red error console for hours, it stops being about the game and starts being a mental battle. It’s a side of game dev people don’t often see—the frustration of a simple “laser” not pointing the right way.

Attachment
Attachment
Attachment
Attachment
Attachment
0
oggythebuilder01

In this update, my primary focus was on refining the visual identity of the project through the lighting system and character presentation. Here’s a breakdown of what’s been happening behind the scenes:

💡 Lighting & Shadow Overhaul
I’ve spent a significant amount of time reworking the lighting system to create a more immersive environment.

Shadow Calibration: I have been fine-tuning the balance between light and shadow to add depth to the world.

Progress Update: While there is still a bit of “polishing” left to do, the core system is almost ready and will be completed very soon.

Attachment
Attachment
Attachment
Attachment
0
oggythebuilder01

“I initially attempted to handle the UI design, but I wasn’t quite satisfied with my grasp of it. I decided to pivot and dedicate my efforts to redesigning and refining the game’s graphics instead

Attachment
0
oggythebuilder01

“I’m running into multiple errors in my current project. My kill zone script isn’t triggering, and the basic enemy movement/logic is also non-functional. I’ve double-checked the basic syntax, but I can’t find the root cause. Has anyone encountered similar issues with these specific systems?”

Attachment
Attachment
0
oggythebuilder01

It’s time to add some stakes to this new level layout. While the new environment looks great, it’s currently too safe. Today, I worked on implementing Kill Zones throughout the cave and the starting level.

Attachment
0
oggythebuilder01

After the “Great Deletion” of the main scene, I decided not to just recreate what I lost, but to actually make it better. Since I had to rebuild the environment anyway, I took the opportunity to upgrade the visuals and the layout.

What’s New:

The Cave Redesign: The cave isn’t just a copy of the old one. I’ve changed the layout to make it feel more unique and interesting to explore.

A Fresh Start: I’ve added a brand-new level right at the starting point. It gives the player a better introduction to the world.

Adding some “Flavor”: I’ve spent some time placing decorative objects at the beginning of the stage. These small details make a huge difference in how the game feels!

A New Ending: I also tweaked the ending of the section to give it a different vibe than before.

Current Mood: Honestly? I’m glad I had to rebuild it. The game is looking much more polished now than it did before the crash. Sometimes you just need a fresh canvas!

Attachment
Attachment
Attachment
Attachment
Attachment
0
oggythebuilder01

So, quick update: I spent way too much time trying to fix those red error messages, but they just wouldn’t budge. Every time I fixed one thing, two more broke. Eventually, I had to make the hard call to start the main scene over.

The Silver Lining:
It’s not a total loss! Luckily, I didn’t have to rebuild the entire game from zero.

Survivors: My characters and enemies (the most complex parts!) are still safe and sound.

The Fresh Start: I’m only rebuilding the environment design from scratch.

The Lesson: Honestly, the new environment is already looking a bit cleaner than the old one. Sometimes a “forced” restart actually helps you organize things better.

Current Status:
I’m currently dragging my character nodes back into the new environment and re-linking the logic. It’s a bit of a grind, but the game is finally coming back to life. No more crashes (fingers crossed)! 🤞

Attachment
Attachment
0
oggythebuilder01

Well, today was a disaster. I was moving too fast, clicked the wrong thing, and deleted the main game scene layer. Just like that… poof.

The Damage Report:

Total Meltdown: The engine immediately crashed because it lost its “brain.”

Broken Characters: Since the main layer is gone, my characters have nowhere to live. They’re throwing out more red error messages than I can count.

The Rebuild Fear: Looking at a blank project and a console full of errors is honestly exhausting. It feels like I’m back at square one.

Final Thoughts:
If there’s one thing I’ve learned today, it’s that Godot needs a much bigger warning sign for deleting critical files. One accidental click shouldn’t be able to wreck a whole project! For now, I’m going to try and salvage what I can, but I might be in for a long night of rebuilding.

Attachment
Attachment
0
oggythebuilder01

This update was all about stability and aesthetics. Instead of adding new mechanics, I spent my time stress-testing the current build to ensure a smooth player experience.

  1. Iterative Bug Fixing
    I went through multiple rounds of testing, identifying bottlenecks and glitches. Each time an issue cropped up, I circled back to the code and assets to refine them. The game feels much more stable now that the “problem spots” have been smoothed out.

  2. New Environment Design
    I’ve built a brand-new environment to expand the game world. To get the lighting and composition just right, I utilized reference photos from Picsart. This helped me translate realistic colors and moods into my 2D pixel art style.

  3. Next Steps
    Now that the foundation is solid and the new environment is set, I’ll be moving back into feature development and adding more interactive elements to the world.

Attachment
0
oggythebuilder01

“Level design for the cave is mostly done! It’s looking solid, so now I’m tackling the to-do list for mechanics. Still need to code the enemies, drop in some kill zones, and hook up the coin system and health bar. The ‘game’ part of the game is finally coming together!

Attachment
0
oggythebuilder01

I’m back with another update! My game world is starting to look much more like a real place now. Here is what I’ve been working on:

🌲 The Forest is Growing!
I spent some time expanding the environment. I added trees to fill up the space and make the world feel more alive. It’s amazing how just adding some nature makes the whole scene look so much better!

🧩 Brain-Teaser Ideas
While I was walking through my new forest, I had a great idea: Puzzles! I’m looking for the perfect spots to hide some puzzles. I want players to use their brains to get through certain areas, not just run past everything.

👾 The Enemy “Big Three” Plan
I’m currently planning the enemies that will live in this world. I’ve decided to make three different types to keep things exciting:

Small Enemies: These will be the tiny ones that keep you on your toes.

Mid-Level Enemies: These will be a bit tougher and require more skill to beat.

The Boss: The big one! This will be the ultimate challenge at the end

Attachment
Attachment
3

Comments

bontaromiii
bontaromiii 25 days ago

HEY! if you are making this project the time that you spend in godot wont be counted right?only the time you code will be counted?
are you okay with that?

oggythebuilder01
oggythebuilder01 23 days ago

“Is that actually going to happen?”

oggythebuilder01
oggythebuilder01 23 days ago

“I don’t think that’s realistic. Game development involves much more than just programming. In my opinion, the coding portion won’t even account for 1% of the project’s timeline.”

oggythebuilder01

Multilayered Environment Design
The primary focus of this session was establishing a structured environment. Instead of a flat design, the world was built using a multi-layer approach:

Layer Organization: Separated elements into distinct layers (e.g., the “Lesan” background layer) to create a sense of depth and parallax.

Visual Hierarchy: This layering ensures that the background, midground, and foreground interact correctly, allowing for easier asset management and future polish.
Enemy Design & Asset Integration
New enemy designs have been implemented into the scene. These assets were designed to fit the specific aesthetic of the environment, ensuring that the visual language of the game remains consistent between the player’s surroundings and the threats they face.

Movement Calibration & Task Deployment
Beyond visuals, I focused on the “feel” of the game:

Movement Tuning: Spent time adjusting the movement parameters to ensure navigation feels fluid and responsive.

Logic Implementation: Deployed specific tasks and backend logic to handle how entities interact within the layered scene.

Iterative Review & Testing
A significant portion of the work involved an iterative feedback loop:

Repeated Playtesting: The game scene was replayed multiple times to observe how the layers, movement, and enemies work together in real-time.

Refinement: Each replay helped identify small friction points in the movement and visual clipping issues, which were then corrected to improve the overall game feel.

Current Status:
The environment structure is now robust, and the core movement mechanics are being stabilized. The next steps will involve expanding the enemy AI and adding more interactive elements to the layers.

Attachment
Attachment
0
oggythebuilder01

“In this update, my main goal was to finally get an enemy working for the player character to interact with. The model is in, but the logic is giving me a massive headache.

Right now, I’m dealing with some major issues in my node setup. The animation nodes keep randomly freezing the character, and the rest of the behavior nodes seem to be colliding and conflicting with one another, breaking the logic completely. It’s a mess to untangle, so I’ll be spending some time debugging these node trees to get the enemy working smoothly.”

Attachment
0
oggythebuilder01

I spent a lot of time recently focusing on character and environment design. The art is going well, but I am really struggling with the technical side—specifically understanding the function nodes. Because I’m learning the game engine while developing the game, I’m constantly running into walls. Has anyone else struggled with this while starting out?

A quick game dev tip: The issue you are describing with “function tiles/notes” is almost certainly Visual Scripting Nodes. If you are looking up tutorials on YouTube to solve your problem, search for “How to use [godot] nodes” or “Beginner visual scripting in [godot]”!

Attachment
0
oggythebuilder01

“Working more on the environment today. I added some cubes but had second thoughts about the layout, so I’m reworking a few things. I also found a new character with full animations, which I’ll be using to replace our current main character. I am running into a technical issue right now where the environment lost all its color, so it looks like I’ll have to redesign the colors/lighting from scratch.”

Attachment
Attachment
2

Comments

YourLocalSatyrFlip
YourLocalSatyrFlip about 2 months ago

THATS AMAZING!!

Adi
Adi about 2 months ago

lookin good :)

oggythebuilder01

Devlog #1: Characters, Animations, and First Steps
This is my debut game project, and I am super excited to share my progress! Here is what I have been working on:

Character Design: Currently fleshing out the look and feel of my characters.

Animation: I took my static animation frames and fully converted them into working character animations.

Scripting: I implemented some foundational scripts using Godot’s built-in features.

What’s Next? > Next on my to-do list is jumping into Level Design. I can’t wait to start building the world!

0
oggythebuilder01

first look of my new project check it , i will update more update in next devlogs

Attachment
0
oggythebuilder01

I’ve been using Docker for a while now. I type docker run, and a minute later, I have a database or a web server running. But honestly? It felt like magic. I hate magic in engineering. Magic means I don’t understand the underlying system.

I decided to stop treating containers like lightweight VMs and actually look under the hood. I learned that “containers” aren’t a real physical object in the Linux kernel—they are just a combination of normal Linux features like Namespaces, Cgroups, and Chroot working together to lie to a process.

My goal for this weekend was simple: Write a script that creates a container manually, without installing Docker, to prove that it’s just a process in a fancy costume.

Attachment
0
oggythebuilder01

Shipped this project!

Hours: 3.36
Cookies: 🍪 9
Multiplier: 2.65 cookies/hr

I build this for BROKEN UI JAM
Creating “bad” UI actually taught us a lot about good engineering:

Browser Permissions: We learned how to handle navigator.mediaDevices.getUserMedia and manage microphone permissions gracefully (or ungracefully, in this case).

Real-Time Data: We learned how to visualize audio data (the volume meter) by mapping frequency arrays to CSS styles in a requestAnimationFrame loop.

User Psychology: We discovered that “Good UX” is about reducing friction. By intentionally adding friction (physical exertion + precise timing), we realized just how many invisible helpers (like autofocus and auto-save) exist in modern forms to help users succeed.

Limits of the Web: We explored how browsers handle background tab throttling—meaning this app forces the user to keep the window open and active to suffer the full experience.

oggythebuilder01

It is an authentication interface designed to be technically functional but practically impossible to use. Instead of typing a password, the user must sustain a specific volume level (screaming) into their microphone to generate characters.
The Challenge: If the user stops screaming, the characters delete themselves.
The Trap: If the user screams too loud, the system resets.
The Twist: The system actively fights the user by blurring the screen and changing the password right before completion.
2. What We Made (Technical Implementation)
We built a standalone web application using Vanilla JavaScript (no frameworks) to keep the project lightweight and raw.
Audio Processing: We utilized the Web Audio API (AudioContext and AnalyserNode) to capture real-time microphone data
Signal Analysis: We wrote a loop that calculates the average frequency volume every few milliseconds to determine if the user is “screaming” (inputting) or “breathing” (deleting).
State Management: We created a hostile game loop that tracks “Scream Charge” vs. “Decay Charge” to manipulate the DOM elements dynamically.

Attachment
0
oggythebuilder01

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

Attachment
0