The one time that I did mess with procedural generation, I did a similar thing. Was generating a basic Zelda dungeon and I would just regenerate until it met certain global properties that I wanted. I’m not sure why I gravitated towards that solution, other than it was a 7 day time limit and so I probably didn’t want to waste time trying to do things “properly”, but it also seemed like the only solution in a way. Because you really can’t be sure when you made a “mistake” in the generation process exactly, so it’s not like reversing the current thing back to some “known good point” and changing something is guaranteed to produce a good result. Either way, I agree that ideally generation is fast enough to just throw out the bad ones.

As a hobbyist, I recently switched from Pygame to Godot and it's very impressive.

I am curious why you chose 3D instead of 2D for this project? Interesting channel and game.

How nice that I could notice the argentine english accent just 10 seconds into the video with no prior clue haha. Thanks for sharing the project!

The idea seems great, but the specific result surprised me, haha. From the thumbnail I thought it's the other way around: when you see the light brown, then surely that means you can look into the room, while otherwise there's darkness ... Maybe there's quite a few very different possible approaches to this, but either way it definitely sounds logical to also add fog to the corridors. Maybe you can do an actual fog like effect where everything else just fades out or is in shadow without modifying the geometry, I wonder

thank for sharing. 11:30 other workaround I can think of is make @tool script. this will make that script run in editor. then make the export checkbox that when you press, it's trigger function that generate level right in the editor. this can also help the performance when testing too, because you don't have to generate level every time the game run.

I was about to say "but there is a scene view!" However, you are right, it's only for the hierarchy and not for the viewport:(

Thanks for sharing your thoughts.

This is really helpful. Thank you for making the video.

So what's the solution??

Have you considered filling in the entire area around corridors and levels with walls in the foreground? visually they could still look different but maybe it makes sense if they are not holes!

Hi, I'm creating a painting program in Godot. I need users to paint within a specific shape (e.g., a letter "A" on a texture) and prevent them from moving to the next scene until the shape is fully painted. How can I ensure that painting only happens inside the shape and that users can't proceed without completing the painting? Thanks!

Which software is that for note taking?

Looks fun and interesting!

I feel like those natural edge cases like "bridge becomes solid while crate is in its position" have lots of potential for interesting mechanics. I personally would try to think of something cool that could happen. Like the simple possible interactions are that the bridge could break the block or the block could break the bridge, both of which I could imagine having interesting puzzles. For example, if the bridge breaks the block, it would give the player a way of splitting blocks that they have stuck together. That could be a cool aha moment. But I'm sure there are also other interesting possibilities. Like in Sokobrawn, Steven made it so that the "doors" are hollow boxes, and so can contain a crate. That's also interesting. Or to get a bit more abstract, maybe the bridge and block could fuse somehow. Or maybe the bridge could poke a hole in the block (i don't know what that would mean mechanically, just imagining weird possible interactions). Or in some other way, the bridge and/or block changes the other thing's properties. I feel like making the blocks fall in a particular order will just feel unnatural. Also, a thought more related to the animation issue you were showing at the start: what about a situation where the player presses a button, which makes a bridge non-solid, which drops a crate onto another button, which makes another bridge non-solid, which drops another crate, etc. I feel like you are going to need the equivalent of PuzzleScript's 'again' turns.

the todo list is smart, nice vid

Very helpful

nice! good to see gamedev stuff

cool game

I wish Godot was actually this laser focused on old systems compatibility, but it's fair, they only have so much development resources and they've chosen their focuses

Hahaha, you got me!

The fact I bought this wholesale is a testament to godot lol

Omg, you totally fooled me. 🤦‍♂️

When you have a lot of if() conditions (escpecially nested ones), there is an important paradigm, that makes debugging MUCH more efficient: - make more subroutines! - generally not use if() conditions as if(true){if(true){...}} trees (those are WAY too buggy and WAY too inflexible), but more as if(false or error or haltCondition){ return error code or do nothing GATE-FUNCTION } . - Each subroutine focuses on the constrains of its own activation or effect, that comes last within the subroutine. effects come AFTER the subroutine performs all if(false){return error code} "tests" that must be passed first. Include all tests/conditions In ANY context that it is possibly called in any future, the subroutine always has its own safe-guards. A lot of them may just result in returning "error codes" or "break" or just "return 0". - For geometry objects/properties for example, each geometric-subroutine has its own "bounding volume" and "collision-constrains" and "hit-boxes", and those may be their own subroutines or "inherit"s (if you hate data oriented programming for no good reason, in favor of OOP, that is slowly getting obsolete) - a subroutine itself ideally STARTS with all the fast-to-calculated miss/abort/break conditions, that return "halt/stop/break/nothing" or that prevent "division by 0" or that return "collision would happen so do not move this object", or "the ray/projectile mises the (bounding box) of this object (no nee to do root-solving for intersections, which is often slow code, if it already misses a simple shell-intersection test) , so a hit--event (that reduces hit-points) does not happen. - Pretty much all possible error-or-skip cases of a subroutine are caught FIRST within the subroutine. The more likely and faster-to-calculate ones are to be done first. - halt--or-error-case-checking (the start of subroutines) is always checking for math errors "division by zero, or low precision asymptotes" errors (where ever you divide by variables, check if those are too close to 0), but also physical glitches and game logic boundaries, that you seem to spend a lot of time on. NASA follows this (and others like "no recursion an no heap" to a teeth, for ALL remote-operated space vessels/probes, ever since apollo11 landing computer ran out of memory while in VERY low moon-orbit, causing it to miss its intended landing spot by a short distance.

looks like the REAL puzzle game is all the debugging.

I'm impressed by how consistently you've been putting these videos out!

Happy to see someone else streaming their game dev! Looking forward to checking out many of your other videos.

Very nice to watch your a* implementation!!!

Update: today I added entrances on the floor also, because why not :)

That makes a big difference to how nice it looks. Great job!

audio is nearly silent.

I'm terrified of the 95 moves required to reach that ore. 😱

Considering I've been doing a lot of optimization work at my day job, this type of thing is always interesting to me. With that said, I don't know too much about the profiling tools that you're using here, or the D language particularly. One thing that I definitely wonder about is if the ticks recorded in the profiler for AddCrateToThingsPushed() would include the ticks for Find() or if that gets excluded. It's also interesting that the Point + operator is your next most ticked function below those two. At least apparently from the CPU usage, a straightforward way to make the generator much faster is to just multithread it. (in so far as threading is ever straightforward)

Thanks Marcos, I found this really interesting =)

Yeah, I have learned this lesson many times the hard way. It's basically impossible to just guess where the bottleneck in your code is. I'm thinking of a recent optimization I did where there was a large hitch when spawning a bunch of puzzles. My intuition said that the hitch must be caused by trying to calculate valid positions for all of these auto-generated puzzles. But after profiling, it turned out that most of the cost was actually after a valid position had already been found, and when moving the puzzle elements into their final position. This is because the engine was just defaulting to doing swept physics tests when the objects were moved, because they had not had physics disabled.

Nice devlog!

Looks good!

what is your setup? what linux/desk env u use in this one?

Are you maybe continuing developement? I'd love to see a playthrough My bad, just saw that you are, awesome

Nice video, Marcos! Love it when you update some stickiness code and all the blocks start falling through each other. Classic gamedev things!

this looks super sick

That looks pretty fun(ny), the way he's just tumbling around and whatnot! ;u;

Has puzzle script gone too far?

Why is a robber installing safes?! That doesn't seem right.

Maybe a "pull" character has to steal the safe? :D

This looks fun!

Are you testing different engines or have you decided to use Unreal now?

*Katamari Damacy music starts playing in the distance*

Exciting! Such a lovely idea, would be great to see some kind of state change or indicator of something being collected/magnetised. The robber character is very funny!