It's better to make the tile layers children of Node2D instead of Node. Node does not have Canvas which means it has no modulate to inherit nor visibility. So if you want to make a scene invisible anything childed to Node will not inherit the ancestors visibility state.
It was pointed out to me that Node is probably better than Node2D (and they’re right) if you just want it to act like a folder. If you need additional functionality, Node2D might be necessary
I really like this change actually. As you said, dividing the tilemap layers into its own node makes it more inline to the overall Godot node hierarchy design.
I never used the tilemap layers feature, I just made separate tilemaps for Background Midground and Foreground. I made each tilemap's Z index a lower or higher value. So this new feature just makes my work easier.
Seconded. I've only spent a few hours playing around with tilemaps in Godot and found them quite fiddly. My immediate reaction to seeing this video was "thank the gods, that's much better."
I can only agree to this. Rather new to Godot and I also found it quite confusing, but TileMapLayers makes so much more sence! I guess its a question of habit?
Another really nice benefit with working directly with the TileLayers is that it's now less of a hassle to work with Parallax. Simply drop in a TileLayer into a ParallaxLayer and now you can add distant hills or foreground clutter, or perhaps the view of the distant ground in a top-down like Zelda: Link to the Past when atop the mountain.
@@baconandgames To be fair, I haven't actually checked if it works yet. But I see no reason at all for why it wouldn't. To the point that I'd call it a bug if it doesn't for some obscure reason.
I started learning godot very recently and Ive already ran into the "oh no I painted the tiles on the wrong layer" issue you mentioned. I agree with everyone else about this change making things simpler, faster, less prone to mistakes, and overall, more coherent with the node design philosophy of the engine. 10/10 update. And it doesn't look like any features where removed/lost which apparently needs to be worried about in today's age. It's always nice to see a gem that cares about the product and the users. It might have something to do with it being open source and developed by said users but what do I know 🤷♂
If you can apply different materials to different layers, then this is a WIN, because previously shader affected whole tilemap and it was not very usable for something like "fog of war"
I'm not seeing the "split" in the people. Please, don't start using drama as a clickbait for Godot. We have a nice community, let's keep it clean from fake controversy.
That’s a really fair point. It’s a wonderful community. To be honest… I wasn’t trying to create clickbait or stir up controversy. I had been hearing mixed feedback from a few other godot users and so I threw that title up there with that in mind, while rushing to get this out before the weekend. Not an excuse really, but an explanation nonetheless. My apologies. I’ll do better in the future. Most people are saying they like in the comments, but there have been a handful of gripes that have been interesting to read.
Also the “fight!” Was speaking to the nodes battling, not the people, which in retrospect makes no sense because TileMap Layer has already won 🤣. Man, I bungled this one 🤦♂️
That was not clickbait. The title is "People Seem Split on this New Godot 4.3 Feature". It's fair to assume some people are split because that happens when anything is changed no matter how miniscule or beneficial the change is. At no point does the title imply that there's some kind of civil war going on the community. Your comment is more sensationalist than the title.
@sergeantsapient I appreciate the defense but also see their point. I felt a little odd about it when I wrote it. The original title was going to be something like “I really love this new feature… what do you think?” but I changed it at the last second because I wasn’t sure if I really do love it because I haven’t used them much, as mentioned in the video. Thought this title was more middle of the road, opening up to opinions on both sides. I dunno, YT is hard and I’m still figuring this out as I go. I appreciate everyone’s feedback 🙏
@@baconandgames keep up the good work. I just started getting back into Godot after a long learning hiatus and tilemaps are one of the key features I wanted to use so I'm glad to see they're getting something that makes them more manageable. My point is changes in anything always cause a stir. This seems to be particularly common in the Godot community because a lot can change between versions. In this case I'm glad they decided to deprecate the tilemap node and not just remove it and it was a good choice.
I started just now to work with phantomCamera2D and im using my tilemap to limit the camera… do you know how its done with these new tilemap layers? I need to select one tilemaplayer that have the largest size?
Well looks like I’ve got some rewrite to do. I like this idea a lot. It also means you can make layer specific scripts, which is really nice for reducing bloat in a parent script. My biggest gripe with tilemaps is that there isn’t wildcard and either or tile matching for the autotile system. I’ve got tiles where it doesn’t care what tile is in the corner next to it. And I’ve got some that want either of two options out of 4 possible. That second one would be an amazing addition. I know there’s ways to do it by making duplicate tiles and having a different rule on each but then for each time it should be used, you need to add another tile, and that means I’m at least doubling all tilesets
Oh yeah, that's a really interesting case I hadn't considered. You could probably set custom data on your auto-tiles to handle those rules and then loop through your tiles on init or ready to swap out any incorrectly drawn tiles but I already hate this idea as I'm typing it 🤣 But I'm with you on the bloat - any time you can break code into smaller chunks I'm here for it.
I'm not against this, but it is going to cause some re-writing for me. I have a script on a Tilemap that has all of the indexes of the layers as constants, and it uses several functions that currently require the layer index as the first argument. For example, I am going to have to change all of these and more: get_cell_tile_data(OBSTACLE_LAYER, cell) set_cell(MOVEMENT_LAYER, cell, MOVEMENT_TILESET_SOURCE_ID, MOVEMENT_ATLAS_COORDS) set_cells_terrain_path(MOVEMENT_LAYER, current_path, PATH_TERRAIN_SET, PATH_TERRAIN) clear_layer(GRID_LAYER) I'm sure there are other people that are going to have to do more work than just clicking a button to do the conversion.
Yeah. There’s bound to be some breaking changes as APIs and tools evolve over time. This is why they deprecate rather than remove. There’s no need to adopt the new format for your current project unless you need the new functionality, which you probably don’t since the gains here are all editor-side. But when you finish this project, depending on how far out that is, you’ll have a decision to adopt the new method or not.
I was also sceptical at first, but then I started to tinker around with the layers and its so much easier. Not only can you attach a separate script to handle custom interactions for each layer, which is more organized megascript for all layers. You can apply modulation, and other effects to each layer separately, or even shift a single layer by an offset. It's really neat. (both in the sense of tidy and cool)
I spend quiet some time creating code that will load and save tile map at runtime, in addition to generating map dynamically. I have to redo lots of work because of this. However if I am doing a new project this would make things easier to work with.
I have recently started learning Godot, and I am trying to work with a tilemap, this seems SO much more intuitive than the original system. But I do wonder whether this will be easier or harder to work with in scripts. For example my first little exercise with tilemaps is a little editor for something, and in most tilemap functions it asks you for a layer, which makes it very easy to work with multilayer stuff, guessing this will be slightly harder with these.
I suspect it is about the same working with scripts. The API will have changed, of course, new node - but they’re reported to be quite similar. Good luck with your godot journey and your project(s)!
Honestly, i really like this, at a glance i was misled to thinking it was unecessary but the amount of times i painted a tile to the wrong layer is uncoutable
Thanks for covering this up. Tilemap Layers is way more intuitive than original Tilemap. It's not my case but imagine someone using 10 layers and finding/switching in that nested Tilemap UI.
I'm a fan of the new Tilemap Layers, I've definitely run into the same issue as you where I think I was painting on one layer only for it to have been on a completely different layer, can't wait till they're brought to the stable branch!
This is the purpose for deprecating versus removing it. Using the Tilemap won't break anything for quite some time. It's a transitional change, not a breaking change... but I understand what you're getting at.
That’s true though that’s one of those features that feels a little buggy to me because it doesn’t always update the icon which makes me wonder how stable it is.
I now understand the update much better and actually prefer it this way - the split reactions left me feeling unsure of the change at first. This discussion video was also very clear.
Layers are great been using the beta its just more godoty the tilemap has so much in it that is just split up into the layers making it way simpler to customize
I don't like this way of managing layers. I would prefer each layer to be just that, a child layer of the tilemaplayer node but currently, each layer is a tilemaplayer node on its own. TilemapNode -> all features of a tilemap (main node) ----TilemapLayer -> layer features (children node) ----TilemapLayer2 -> layer features (children node) ---- ... With this current system it is like the old tilemap node in godot 3.x.
I was chatting about this with someone in another comment, actually. It might be worthwhile to model it after Control nodes, in the way that the parent sets defaults and then child inherits or overrides. 100% That might cut way down on how much needs to be set on each layer. Excellent point! Thanks for the comment 🙏
For one, you can apply logic to a TilemapLayer in ways that weren't possible before. This also means you can modulate layers individually as well. But besides that, I think we're seeing a shift in "ideology" by breaking things down into smaller parts, just as is wise to do when making a game with Godot. We're seeing this shift with Parallax nodes and I suspect we'll see it with others as well. Godot has a bit of a nesting problem; menus within menus within menus, which make editing and organizing your project cumbersome. Can you do a TON now that you couldn't do before, no. But there may also be some stuff under the hood being done to prepare for future updates that will be significantly less cumbersome with these, rather than the old TileMaps as the base. That last bit is just speculation on my part though.
What advantage do these have over using multiple TileMap nodes? I don't dislike the change, but it's effectively the same workflow as before they added layers to tilemaps.
I would guess it’s the first step in a larger refactoring as the basis for future improvements, but no haven’t looked at the source code. So while it may not look all that different yet, it’s likely easy to build upon that the TileMap node it will be replacing.
Well you can't please everyone. Software like GODOT needs to advance and improve. That means that sometimes you may have to change the way you do something or update old code. You can not expect them to bog the software down with old features that most don't use anymore. You are getting a great piece of software for free.
Anyone able to help me? I’m trying to get into game dev, but I’m unable to drag my assets into godot, I was watching brackys vid. Is it a computer setting issue?
What kind of assets? Sound files? 3D models? 2D sprites? This is a pretty open-ended question. You might have better results posting a more complete question on the Godot forums. forum.godotengine.org/
Isn't this the exact same thing as what we had back in godot 3 where you just had multiple tilemaps where you had one for background, one for props etc... like what's the difference?
I wasn’t using Godot as much back then so I’m not sure how it differs on the finer points. From what people have been saying it certainly seems similar.
I think you would have to have a LOT of layers before the number of nodes contributing to your game’s overhead would be impacted by TileMaps. But in truth, and I’m saying this without looking at the Godot source code, I don’t imagine it’s all that different in terms of overhead because the data being tracked hasn’t changed much. They’re just changing whether one TileMap is responsible for multiple layers or if those layers manage themselves. Generally speaking, yes the more nodes you have the more overhead, but I don’t think this change is likely to be the first failure point.
I actually haven't messed with that feature yet. I did a little digging and based on the lack of mention in their build notes and the way this thread (see below) ended, I'm going to GUESS it hasn't been resolved yet. But if I find out for sure, I'll update you here. github.com/godotengine/godot/issues/72611
I don’t know for sure but my guess is that this is the first step in a larger refactor. In the same way we tend to refactor our projects and break things into smaller responsibilities, I SUSPECT that this change will make futures updates to how tiling works easier. I could see a world where there’s a parent node that controls high level settings for the children (sort of like how Control nodes work) allowing layers to inherit or override certain values specific to their tiles. I don’t know that they’re looking at doing anything like this, but breaking things down into more parts COULD indicate this. 🤷
Have the Godot devs not taken clues from other engines like Unity and Unreal Engine? Unity is so full of deprecated crap, you don't know what to use, unless you read a book on the current version. Instead of leaving old broken crap in the code, which could potentially bug things out, why not just download w/e version had that old feature? If they can back port fixes, that's great, but dam, please don't wind up like Unity, or even Unreal Engine that is so full of old, broken or obsolete crap.
I don’t think it’ll be around forever but you’re right, they would be wise not to leave depreciated features around for too long. After too many it can get bloated. But some transition time can be beneficial. You can also toggle off nodes you don’t want to turn up in the node search/add window, which I realize isn’t a solution but might be helpful for you during the transition.
Godot does remove things it deprecates. The point of deprecation is to give people room to migrate and then remove them eventually. Godot 4 removed a shitton of things that were deprecated in 3
Also yes I think this is a bad move and a good move. It's a good move in that at least it is attempting to address a problem. It's a bad move because it is creating a new problem. Larger projects that make more use to layers will now run the chance of cluttering the hierarchy. As each layer is now technically capable of being a scene, this means there can be unique logic again this is a positive and negative. I think the solution could have been to use both at the same time and to have cleaned up the ui. So selecting the active layer via heirarchy or inspector would work the same. You keep the tile map and you get the ability to add tilemap layers as scenes to a tilemap.
Oh interesting… excellent point. See, this is exactly the kind of stuff I was hoping folks would bring up because people do seem divided on it. For the small games I tend to make, I thankfully probably wouldn’t run into this issue but… I totally could too. Thanks for the thoughts!
This is largely my issue with the new implementation. There's now no single node to house, manage, or add these new layers and make global edits to them. It's just gonna clutter up the UI and make it a bit of a hassle to work with them. Like you said, the better solution would have been to keep a version of the TileMap node and require the TileMap Layers to be children of it. That way you get the granular controls with each layer while having a root TileMap node that can add new layers as children and make global edits to every layer under it.
@pixels_per_minute yeah, that hybrid approach would have been neat. The parent map would set the “master values” and then the layers would either choose to inherit or override, pretty much the way control nodes work.
I don’t believe an exact release date has been announced but their latest dev snapshot is saying “around a month”. If that holds then it’ll be some time in July, though that’s dependent upon how bug fixing goes.
I am currently refactoring my game to use the new TileMapLayer. How can I ensure common functionality is shared between nodes efficiently? For example, I have a mouse_to_tile() function: func mouse_to_tile(mouse_position: Vector2): return local_to_map(to_local(mouse_position)) I want every layer to share this function without redundancy. One option I considered is using a parent node to handle this, but that approach seems suboptimal since already my parent node takes care of other more general functions. I also thought of creating a custom class that extends TileMapLayer. What would be a better solution?
Tough to say without knowing you project, but generally I’d extend TilemapLayer to add the functionality I need OR build something through composition that can be attached to nodes that need it. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-74y6zWZfQKk.htmlsi=jcj06VNx1eyrMYZm
I could be wrong, but this kinda seems like it's just how Tilemap worked before layers were implemented, except they changed name to TilemapLayer. I haven't touched Tilemaps in ages, tbh, but I don't dislike this. In fact, I've always had the feeling that Tilemaps didn't need layers in the first place, simply because you could already layer several Tilemap nodes to achieve the effect.
There is no valid complaint, unless you are a professional complainer on Twitter, this is objectively better and I was avoiding using the 4.0 tile map because it just had so much to learn
I’m definitely of a mind that it’s an improvement. There have been some interesting gripes in the comments that I’d not considered (one being how it gets cumbersome in larger games with lots of layers) The TileMap node does have a lot of settings 😳
I’m not sure they’re actually invisible. They might just be outside the camera bounds. But if they’re set up as Scenes, you can just set visible = false in the ready() function. There’s probably a way to do it with tiles as well, I’m just blanking on that off the top of my head.
Man I just started using the current tilemap and already had to move things hetween layers due to how many mistakes I've made. I can't say im not in favor of this change
I think the devs did a nice job with the feature and the rollout. Change can be jarring, no matter how hard people try to make the transition easy. I’ve seen some valid complaints about the new system but overall I think it’s squarely in the net-positive camp. Thanks for the comment and for checking the video out. I appreciate you 🙏
@@baconandgames I'm making a voxel style extraction game, single player shooter with top down view. I'll share some videos once I have something decent.
I'm still on 4.2, I'm curious if they retained the PageUp/PageDown functionality to move up and down the layers? Or if there's a generic Godot hotkey that moves to the next/previous selected node that I'm not aware of.
I think, aside from using tiles of the same multiples (32x32, 64x64, 128x128, etc), it’s extremely rare to have tile sets of different “sizes” in the same project. So I don’t expect that’s a problem they’re trying to address. Typically tilesets within a game adhere to some kind of standard that makes them fit together. If they don’t, that’s where you end up using Sprite2D.
@@baconandgames yeah, I agree, my project has 8px and 16px tileset sizes, I need tham that way because both have autoterrain at 8,16 sizes, and I have to use both sizes, and I would have loved something that works with both in the same layer
@c64cosmin I’m pretty sure you can do that now. You can have tiles of different sizes in one tile set. Then you’d just make your grid 8x8 and paint as you normally would.
I have almost no experience with godot, and actually no experience making a "real", game yet, but this feels a lot nicer to work with! I wonder if they are doing the same with stuff like animation players?
I think what Joe was asking is whether other more complex features, like the AnimationPlayer, will get broken down to more digestible versions of themselves. Tilemaps and AnimationPlayer are among the most intimidating features to newcomers because they have so many menus and sub-menus, many of which are contextual and not all of which interfaces are super intuitive. While I wouldn’t call the TilemapLayer a huge leap forward in simplifying Tilemaps, it does seem to remove one layer of complexity (no pun intended 🤣)
You can stream-line the actions at 4:28-4:42. Just right-click the TileMap and pick "Change Type". Now you can pick Node2D and it'll convert the node to that type, and keep all settings that carries over, like visibility, transform, etc. This is very helpful, especially when working with a scene root as you can change your enemy from a generic Node2D to a CharacterBody2D for instance.
That’s a good point. I always get a little nervous about that because Godot doesn’t always seem to recognize the change (the icon doesn’t always update) and if you have a script attached extending the node then you have to be extra careful to update the base class. But you’re right, that would have been a lot quicker 🤣 Sometimes I feel like my brain slows down while I’m trying to narrate what I’m doing while recording. 🙃
@@baconandgames Yeah, the script needing to be changed is an issue that it should probably warn you about at least. I believe it works if you go down the hierarchy though, so from Node to Node2D.
In my opinion, TileMap as node gives many advantages over the old way. In this way, we can access the TileMap Layer straight from the Scene Tree without the need to access the TileMap properties to get the TileMap layer. To delete all the Prop layer? Easy. Que free the Prop TileMap node. Done
You were able to do this with the previous Tilemap node too. I know this because I did it, it would've been $TileMap.clear_layer(2) 2 being the array index of the prop layer.
I don't think there was a problem with the old way tilemap layers worked other than the fact that the interface was trash. Like, it _could_ have worked. I could definitely see a version where the integrated layers were somehow more useful and tighter than having a new node for each different layer, but it needed polish.🤷
I suspect it will continue to evolve, especially with a vocal community and it being open source. It’s one of the things I really love about godot. The users actually have a chance of being heard 😬
@samuraikina5908 oh no bother at all! Ooooooohhhhh, I know what you were referring to. That’s a picture of my niece- she’s on my consultancy page. She made her own Link costume for Halloween and wanted to show it to me when I came to visit (in February). I thought it was super cute so I put it on the website. I’m with you now. 👏👏👏
The "feature" people seem to be actually split about is the fact that you no longer can just do "if something != null" to check if you can still use that specific thing and instead you have to do much more verbose "if is_instance_valid(something)"
@@UltimatePerfection GDScript has duck-typing, so these values are cast into booleans for the "if" evaluation. You can test it with the following snippet: var a = null var b = Node if a: print("this evaluates to false") if b: print("this evaluates to true") It's kinda the same reason you don't have to typecast variables into strings before you try calling print() on them.
There's pretty much no sane programming language that even has something like is_instance_valid(). Godot is this bizarre outlier that has reference counting and yet still teaches (let alone allows) people to queue_free() their nodes and introduce crashes deliberately. If your reference is ever supposed to point to an object that could be freed, you should use Weakref
This TileMapLayer looks more useful than old TileMap nodes, but I'll wait a bit before making the upgrade, as I prefer working with more stable versions. Also, good job on setting up your consulting services. I'm rooting for you!
@@baconandgames It's a good thing I'm not using them for the current game I'm making, and honestly the TML will be more useful to create 3D levels than regular TM (since you'd need to create layers yourself and make sure they all act as intended, etc... while the TML are nodes, thus more easily rearrangeable.) The bit on the collision layers is still relevant, at least, so that video wasn't made in vain. Keep up the great work! I'll go back to my shaders (which is the main reaosn I'm not switching up to 4.3, because of a possible lack of compatibility.)
@@baconandgames This channel isn't for videos, and I haven't made any devlogs yet. However, I can explain what I discovered by myself with shaders and how to efficiently make one (using pre-existing tutorials.) If you want a good channel about shaders on Godot, I suggest FencerDevLog who makes some incredible visual and functional shaders: www.youtube.com/@FencerDevLog
@@baconandgames I just realized my response had a link, so it's probably in your spam/moderated comments. For shaders, I advise the channel of FencerDevLog, who does a lot of great Godot visual shaders, and even show how to convert from Shadertoy to Godot's shading language.
Maybe some people don't like managing lots of nodes in the editor and this adds more to their project, but to me that just says they need to structure their nodes better. Which they should be doing anyway.
I feel that. I like a nice tidy project. And often, if you have too many nodes in one tree you might need to breaking responsibilities into smaller components.
Can you create a tutorial (((gathering???)) cut trees (the tree shakes if the player cuts them) has a cut (cut trees) action limit (example: 5 times a large tree, 3 times a medium tree, 2 times a small tree) when it reaches the limit (tree aga animation (fall) and objects falling to the tree after (falling tree)
I actually wished for a rather different change regarding the layers in the TileMaps. When I draw a level, I don't want to be constantly switching between layers manually or checking whether I'm on the right layer. Instead, I want to be able to tell the individual tiles in the TileSet which layer they belong to. That an item sprite always lands on the item layer and a level tile on the level layer accordingly. Now you have to create several TileSet graphics in order to distribute them for the new TML, which at least provides an overview.
