Dungeon Room Transitions - Godot 4 Intermediate Tutorial

[@uheartbeast]

Thanks for watching the video! Here is the github repo for the project: github.com/uheartbeast/WASarD-Room-Transitions You can wishlist WASarD on Steam with this link: store.steampowered.com/app/1151870/WASarD/ Leave a comment if you have any questions for me. Ben

[@hamsu7453]

Bro your actually the GOAT in the Godot space, hope there more to come! All these videos are amazing and I am learning so much from you. ❤ (More procedural generation videos but with room instead of tiles will be an amazing video, everyone follows your procedural videos first!)

[@JB-xb3of]

Can you do the level generation next? It looks manageable, but before I watched the video, I briefly thought about how I would have solved the task and was totally surprised by how elegant and simple your solution is in the end.

[@ZachAR3]

Look at his procedural tile map generation and just modify that to spawn your dungeon scenes instead of tiles.

[@hamsu7453]

@@ZachAR3sounds great but do you have an example on how to do that?

[@7_rlz_714]

​@@ZachAR3 I think it would be more complicated with the camera transition to another room, assuming that random rooms are generated at random distances, you would have to calculate with the camera where to go.

[@ZachAR3]

@@7_rlz_714 no.... If you use a tilemap you can easily just offset the given position of each tile by the size of the room so it follows a grid.....

[@magnazone69]

Awesome to see the tutorials, great work man

[@luckyknot]

Fantastic explanation on how to transition rooms, much appreciated sir!

[@cabbanisbrasil]

Nice to see, everyone is learning godot!

[@Pepeutra]

I followed the tutorial word for word until 3:40 but when I loaded in the game it shifted the camera so that it only displayed the top left half of the room, and it stopped doing that when I removed the Events.room_entered.connect(func(room)... portion of the camera2d script. Have any ideas of what might be going on and ways to fix it? Edit: It does shift the rooms shift the rooms like the video, it just places the camera in the wrong spot and moving the Camera2D around doesn't change anything

[@jeffvenancius]

Maybe instead of setting a target position for the player you could set a amount(?) If it's vertical, set the position.x + or - this amount, etc... That way the player will keep his original path and it will be more natural.

[@uheartbeast]

Admittedly this is actually what I do in WASarD haha. I simplified it a tad for the video.

[@jeffvenancius]

@@uheartbeast É nóis

[@mystcj]

I've followed up on your tutorial until around 3:45 and I'm getting this error "Parser Error: Identifier "Events" not declared in the current scope." in the DungeonRoom script at the Events.room_entered.emit(self) line. What might be the issue here?

[@uheartbeast]

Sounds like your Events script hasn't been added as an autoload in the editor.

[@wi-chung2603]

Could you do a tutorial on how to generate the dungeon/rooms? that would be extremely helpful and very appreciated! thanks for the vids either way and WASarD looks great!

[@SheepUndefined]

Literally was doing stuff with empty node2ds as spawn markers and wishing I could do the thing Unity did with letting you assign editor-only sprites to those. And then I find out about Marker2d through this video, lol

[@Mrme-cn9je]

Hi Benjamin, Can you kindly explain the reason why you didnt opt to use signal up call down principle but prefered the auto-load? Is it because you came to decide autoload is better than that? I'm a novice but I had watched some tutorial saying autoload is actually dependency. Is that right? Thanks.

[@uheartbeast]

Hey! I used an Event Bus pattern for this. The main reason is because my rooms are generated dynamically (by the level generation system) and so connecting each room to the camera would be a huge pain. It's much easier to have a single signal inside an event buss and then connect the camera to that and have each room emit the signal when entered. There is a great article by GDQuest that talks about event busses if you want to learn more about the pros and cons: www.gdquest.com/tutorial/godot/design-patterns/event-bus-singleton/

[@Mrme-cn9je]

@@uheartbeast Thank you.

[@Drazard]

wouldn't a simpler fix be to make the top door collisions smaller ? or possibly add an extra collision specifically to handle the door transition on the player. it only has to be a small 1x1 pixel collision in the center of your player. and with a small say 10 pixel wide door step for each door collision and it would be extremely precise. excellent video tho. all of your videos have been amazing.

[@FutureChaosTV]

The transtition between the rooms would probably look a bit better, if the player disappeared for 50-100ms so it doesn't look like he is walking through/above walls... Or change the Z-position and change it back when the other room is entered.

[@_nyx_the_killer]

I love your videos❤, can you do a metroidvania tutorial? like Castlevania or momodora

[@felipezymor9970]

Can you do a tutorial of this room-based dungeon generation? Seems like The Binding Of Isaac and Scourgebringer, it's exactly what I need for my game...

[@Dillonian]

my camera is still just teleporting from room to room after turning smoothing on and trying all different speeds nothing works any ideas?

[@toxicallehhighlights658]

Can you have two different collision points? One for the character when you want it to be hit by mobs etc and one for the collision for the doors. In that way you could technically make the door collision get even more precise? :) Cool video though :D

[@uheartbeast]

Yes! I do that in the actual game. I've got 2 collision shapes. One for hitting walls and one for being hit by enemies.

[@kunai9809]

why didn't you put the collision shapes inside the door scenes? And why didn't you just center the player position in the middle of its collision shape?

[@uheartbeast]

1. In case I wanted the ability to use polygon shapes on some doors. 2. Because of the perspective in the room. It would look strange if the player couldn't walk in front of walls or other solids.

[@ThantiK]

WOO HOO HE'S BACK!

[@isagarcia4752]

Unrelated with your actual project but could you consider make a tutorial of how to make a party system? Like how to change companions off battle, swap in battle, etc. Like a jrpg for example persona or pokemon

[@_nyx_the_killer]

Can you do a tutorial for mobile touch screen controls? Pls ;--; (Sorry for any english mistakes)

[@lounestb3718]

really cool

[@_nyx_the_killer]

Can you do a tutorial for mobile touch screen buttons? Every time I try it never works

[@drakenork]

Thx for video ❤

[@capycapy8920]

Please do a vid on room generation and linking

[@floatingcowinvasion]

this guy sounds like gabe from the office

[@cherrymanmay]

Bro, can you make a dungeon room generated video

[@debrucey]

When did you go from Benjamin to Ben?

[@uheartbeast]

I use them interchangeably and don't notice the difference haha

[@fatmike5038]

nice

[@lincolnpepper816]

this doesnt seem like a good solution, specifically i dont think using singletons for node communication like this is a good idea. couldnt you simply use signals and achieve the same thing?

[@uheartbeast]

An events bus singleton is a pretty common and established programming pattern. I think this is a good example of where the pattern is useful. It prevents coupling between the camera and the rooms (whereas connecting the rooms directly to the camera would couple them together). If you'd like to read more about it, here is a useful article by GDQuest that talks a bit about the pros and cons: www.gdquest.com/tutorial/godot/design-patterns/event-bus-singleton/

[@lincolnpepper816]

@@uheartbeast thanks for the informative response.

[@SheepUndefined]

I always hear people bring up encapsulation principles and all that, but honestly, the real deal is just that it's annoying to hook them up. The object has to know about the object it's connecting to, in order to hook up a signal, which means get_node() and a bunch of extra boilerplate code every time you want to hook into a signal programmatically. Singleton event buses are universally known, so there's no get_node() overhead, and neither the emitting object, nor the receiving node don't need to care about what's on the other end anymore. That's prolly what people mean by the whole encapsulation thing but that's sorta hard to parse unless you already know what they're referring to, imo.

[@uheartbeast]

@@SheepUndefined That's a fair point. Connecting every room to the camera would be a huge hassle, especially since the rooms are instanced dynamically by the level generation system. Having an intermediary (the events buss) between the room and the camera *might* have benefit later on if I need to make changes (who knows) but the benefit right now is that the code ends up much cleaner and easier to understand.

[@thegameissimple]

Not so advanced, tbh, but cool nonetheless. Thanks!

[@mammonth]

Ладно

[@왜못할거라생각해]

Very bad lv design are you sure you a developer??? Like wtf You are just a seller Not game developer

[@jedikoops]

[@NguyễnLinh-z2f]

Stop being a untitled Karen, touch grass, the video is used to help ppl, not flexing his level. Touch grass you Karen.