“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
Log in to leave a comment
“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
Log in to leave a comment
“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?”
Log in to leave a comment
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.
Log in to leave a comment
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!
Log in to leave a comment
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)! 🤞
Log in to leave a comment
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.
Log in to leave a comment
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.
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.
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.
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.
Log in to leave a comment
“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!
Log in to leave a comment
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
Log in to leave a comment
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?
“Is that actually going to happen?”
“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.”
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.
Log in to leave a comment
“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.”
Log in to leave a comment
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]”!
Log in to leave a comment
“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.”
Log in to leave a comment
THATS AMAZING!!
lookin good :)
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!
Log in to leave a comment
first look of my new project check it , i will update more update in next devlogs
Log in to leave a comment
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.
Log in to leave a comment
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.
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.
Log in to leave a comment
I’m working on my first project! This is so exciting. I can’t wait to share more updates as I build.
Log in to leave a comment