Well this topic is more controversial than I thought! 😅 Please leave a comment if you have any feedback on the methods shown in this video, or want to share another way to use metadata! (Let's make this video a collection of metadata information/usage, since there doesn't seem to be much out there yet)
I never really messed with metadata but it's really interesting as I now think about it. 🤔 I _think_ I would roughly come up with a rule of thumb now like so: Is it about your object sharing the same property with other objects? And is it likely that you will search for all of those objects with the same property to do stuff with them? For example: _"I have a building object and I need that one as well as all other building objects in my scene tree to start burning."_ → Use groups. You can simply use the group-related methods of your scene tree to grab all building objects and make them burn or whatever. Is it about your object having a property regardless of if other objects with the same property exist? And you only care about that property when dealing with the one object to detect stuff or to identify specific behaviors? For example: _"Is my game character looking at a building or at a monument so that I can display a little infobox for the object?"_ → Use metadata. "Ask" your currently looked at object for its purpose and display either a memorial tablet or residental stats or whatever. As others have stated, this could be easily done with exported variables but then you're right, this always needs a script to be attached to it. Other than that I'd like to add that even if a script is attached you might not like the idea of adding that one exported variable to the script for whatever reason (maybe because the script has some basic function in your class hierarchy that many different objects share … whatever else reason there could be doesn't matter actually in detail, main point is you don't want to add that export var). So you would have, of course, the opportunity to inherit that script class with another one to add just a little variable export. But that could lead to lots of classes inheriting from that base one you didn't want to touch and also another potential issue is coming up. Let's say you got a `GameObject` script attached to all game objects and now you wanna inherit that one to get a `BuildingObject` and another one to get a `MonumentObject`, both with different export variables (like size, year of construction, cost, sponsors, a label with who or what is honored, and whatnot). This would work until you would need something like a `MonumentalBuildingObject`. Then things could easily get out of hands because you need all export vars from the building and also all export vars from the monument … now let that thing be built out of grass. 😉 And that's when things could easily get out of hands. By using metadata you could get rid of problems that polymorphism brings, I guess. Why not still using groups in that case? - Well, because a group is nothing more that a string value attached to an object. But as pointed out in the video metadata can have one of many datatypes. Could be a string, a number, a vector, anything. That makes you more flexible in how to deal with your metadata (in comparison to a group). As said, I never used metadata in any project but I'm starting to think about considering it for a few situations at least. It's really something I should have thought about earlier. Extremely interesting the more I think about it. That being said, thanks for the video! Keep up and best of luck! 😘👍 PS: Hope I could explain myself well enough. Non-native speaker over here.
From what I can gather, metadata is useful, if you need certain properties that some classes or individual objects have and are not critical to classes, objects and inheriting classes. From your example, some things might need descriptions and others don't need that. Since descriptions only affect info box script, metadata might be preferable then adding "description" variable to every script in game in hopes that eventually single random thing will need to be described. At least that is how I interpreted this.
I'm starting to wonder if we might also use metadata as a replacement for somethings that people have used componetization for. For example, someone might have made a health component which has a script to control that health and signal anything that needs to update because of it changing. That would probably be something you'd use an export variable on for the max health. But what about damage? Sure you'd have a script probably to handle the actual dealing of damage, but what if your game has elemental damage types? And probably resistances to those types as well? Well instead of having 2n extra exports purely for how much elemental damage they deal and resist you could have metadata for any that are different from a baseline (0 damage dealt and 100% taken most likely) which would then allow that damage compenent to check the required values on the entity and apply it accordingly. Although, now that I read this again, this was more about using components and metadata together rather than replacing one with the other. An example of replacing it would be if you had a score component which the only purpose of was to have an export value for the score and then upon recieving the death flag it would send that score. Instead of using that you could just use the metadata and have that checked by whatever handled the dying state. Or it could be used for contextual button prompts. If the object has_meta("context button") then display that button when the vector is pointed at it.
i've been using godot for like a year and i've never heard of this before, no one talks about them no one uses them yet i see great potential, it amazes how no one even bothered to talk about a feature like this, Thank you bro
@@poleve5409 Metadata has a button and it is listed under the script within the editor description section so they weren't wrong about it being below the script. However, you ARE wrong about it being below the inspector because it is _inside_ the inspector that you access it. So take your advies and never talk again. XD
maybe I'm quite late to the party :D and I agree that the "Switch vs If/Else" example wasn't that good, but I think that the concept is still clear. I'd personally do something like this: Add a metadata to the sprites called "frictionModifier" which is an int and if the player is on top of the sprite, I'd just do something like: "movementSpeed *= get_meta(frictionModifier)" basically. Therefore I don't need a branching structure at all and I can achieve a different behaviour for different materials, without having to define a script. Sure if the material gets lots of metadata or if I need to do some custom logic, I'd probably still use a script. I've never used this concept before, but for me it's well suited for "static data for a specific thing". Using this for materials is really neat, because those tend to be static anyway. Thanks for your video :)!
You do bring up an interesting discussion, which I believe has and will be around forever as long as there are programmers around. So, I guess I gotta get my opinion out on this, too :P First off, I like that you didn't advertise metadata as an all-round solution for everything since there are usually multiple concepts that work roughly equally well, depending on the scope of the project. Though, I must say, I did not quite get your entire point for metadata. The main reason being that your given example doesn't really achieve more than changing your script from using if-statements to a switch-statement. Additionally, - and this is a bit beside the topic, but... - to me, this seems more like a job for inheritance: Since all the different properties of floors could just be inherited to the objects and I wouldn't have to keep track of the property names when assigning metadata. Going from there, I feel like you may have focused a bit too much on showing how you can use metadata instead of groups while they are two fundamentally different things: Groups are meant to provide an easy way to access many nodes at the same time and give some meta-structure to your node-tree without changing the render hierarchy; Metatada are properties which are attached to singular nodes and should thus enhance or describe that node individually. In my opinion, it is this distinction that gives both their utility and rightful purpose in the first place. As such, I don't see much reason to compare them over problems where they are a bit less or more useful since they solve completely different problems to begin with.
"The main reason being that your given example doesn't really achieve more than changing your script from using if-statements to a switch-statement" THIS! I think the example was very weak and hoping there is a better example to demostrate why one would use it over Groups. I personally prefer groups because like you say you can call many all nodes within a group to do something, you can determine how many objects belong to a group quite easily. With meta I see it like adding a Var to a node without having to apply a script, which could be useful?
Agreed the "look you can use a switch statement instead of if-else by using metadata instead of groups" didn't really grab me. I'd definitely still use groups for something that belongs to a group. My take away is that metadata is simply for when you need some properties on a node but don't need a script. If you otherwise were just going to make a script that only held some simple variables and no functionality: metadata. Which, yes, is a different use case than groups. I see this being useful for something like let's say picking up a health jar where maybe you don't want a script on the jar just to queue_free() it so you do that on the player script, but you need the health jar to have the amount of health it provides, so you make an integer metadata value on the jar. Could also work with a weapon, maybe the weapon needs no functionality but just needs an attack power. Or as another commenter suggest a sign that just needs a string of text to pop up for what the sign says when the player gets close.
W video, I use metadata to store resource files across UI elements, such as inside a Tree node. Makes it so much easier to make editors for complex game resources!
Could you explain what you mean by thiss? I'm failing to picture what you're doing and how that makes things easier. Always waant things to be easier if they can be XD
This is also a very good way to implement soft modding into your game. It's what Minecraft is doing with commands/datapacks. You can essentially change the game's behaviour without giving players access to the code. Although it's very limiting, people have made a whole database saving system with it as well, so it's a matter of knowledge and time before they start doing crazier stuff
that would be similar to groups, depending on what you want groups might be the better option because what if you want to disable all of the interactions, using metadata might not be the right thing, while groups you can grab all of them.
Cool but I just don't see a use case that exports and composition can't do better. Maybe I would use it very temporarily but not as part of the final game's core logic, also having proper code completion with the fields actually being part of the node is nice.
if I might add something to your comment: I'd even go as far as saying that the surface detection example could have been achieved in a much cleaner and maintainable way by using inheritance. I still don't see any reason to make my code harder to read by using metadata instead of exports, composition or inheritance.
I thought the same. Even the prime example for it over groups, for me it introduces more issues of user error. I also find myself using resources to avoid having to use strings as much as possible is grass feels better than is "grass" because I trust intellisense more than myself haha :D I still can't see having meta_data as more useful than setting up a "type" or enums. But I'm glad it's there to be used regardless of what people use it for. Maybe there are better examples?
@@rungeon83 Yeah idk, only real example I can think of is prototyping maybe, like having hardcoded references to $NodeName in your scripts. By the end of it I would want it to be type-safe, or only reference nodes or in this case metadata that are explicitly part of the nodes. I understand that it could technically be used as a way to only execute certain code if a node has certain data, but at that point I would just make my own new component scripts rather than writing absolutely all of it on the base node. Idk brain is still blanking on how it might be useful as part of the core code and not just as a way to test something real quick.
@@rungeon83 I think metadata is more useful for things that would differentiate from the norm. An example someone else gave is stats on items: Most items would probably have a sell price, but not every item needs an attack and defense value. Now you absolutely could just use inheritance to create multiple class types (weapons, armors, usable items, materials, key items that don't have a sell price, etc.) and then only apply the needed values but that requires two things: One is that every value in that given class _must be_ addressed even with a default value and that nothing that uses that class will require something else. We often alleviate that with componentization to give a few extra datapoints or things that would be interchangable like a health component, but it's also completely possible to set up items with metadata for things like category, stats, sell price, rarity, etc. You'd then operate on the metadata in essentially the same way as though you had built the classes for them. Caveat being that you don't necessarily require a script on the item itself for it. But as has been said, this comes at the cost of making sure that you type things correctly and lack of intellisense to catch if you have messed up anywhere which means that bug fixing becomes more of an issue. That could potentially be alleviate in the future if Godot adds more metadata support, but I've long since learned not to expect Godot to update/fix specifically one thing or another XD To give an example of something I did that I probably could have used metadata for: I had a little idle clicker game. It had a 3 categories of upgrades and for these upgrades I had one super class and then a class that inherited it for each of the upgrade types. Each upgrade type worked on slightly different logic: One was to upgrade the 'generators,' another to upgrade the material mining, and lastly the final category which just made thigns more efficient. Had I known about metadata then I would've set things up such that the currency required for each upgrade was in a metadata, especially when one of them wasn't actually a currency but rather a metric of how deep the mining had gone (didn't want people upgrading too fast so I tied it to progress). Instead I had a function that handled every possible item type that could be used in each category, and made each of the 3 subclasses have the same exact function, adjusted for the category, to handle it when really most of them were all items that I could've just had 2 checks for: is that metadata 'depth'? if not then treat it as an item. I did build the whole game using just inheritance, but it actually ended up being even more messy because of it (and because I hadn't learned componentization yet, but I doubt it would've been much better). So it isn't like it was an impossible thing to do without metadata, but that metadata might've made it a little bit cleaner. Keyword being _might've._
I think your example would combine nicely with the strategy pattern. You could create a custom resource type and load it up with values for footstep_sound_effect, friction_value, etc... then the player can just call material.do_stuff() and it doesn't need to keep a potentially growing list of all the possible materials and their respective logic. I also think you glossed over a different big advantage of Metadata. It's great for if you want to add properties to a node w/o giving it a script, but it's *perfect* for giving properties to a node that might "conflict" with the script it already has. Take for example if you had a node with a MovingPlatform script, you wouldn't want to add material data to that b/c it isn't relevant to "moving platform" logic. But Metadata is a great way to make those values available w/o having to muddy up your script
the way I see metadata here is the way i see new properties in blender. it can be very helpful combined with drivers. it depends on how do you prefer really. there is not a "must" or something like that but I'm sure I'm gonna use it later. (I'm new to godot and still learning it)
I use metadata to fix the problem with GDScript not being able to determine Script class_name inheritance. Every one of my components has a "BaseComponentName" string and a "ComponentName" string in metadata entry. That way I can easily determine what hierarchy the Components share. Yes, it could have been done with Groups, but I didn't want the Group Editor to get overly crowded. This way, I can determine if all the required components are present on my parent scene by just checking the metadata of the children. Also, by using Metadata, it is transferable from project to project without adding and re-assigning all the groups.
This is fascinating, can you expand on what you mean by components or give an example? I sometimes find it annoying to figure out which of my scripts for for custom resources and which ones are base classes that have been extended from and etc
@@young_kdo9877 Sure, but it is a fairly long explanation. Is there something specific you want to know, or just an overview of how I implement my component architecture? I don't want to hijack Queble's thread here. 🙁
I haven't had this problem with my components. I've always been able to make strong use of class_name inheritance using things like "is" and the like for conditionals. Then again, In using components, I've strayed rather far from depending much on inheritance in most cases. It's still useful in part to extend the node feature-set to accommodate a greater variety of organizational tools. I mostly use a component system to allow myself considerable modularity in designing complex stat-driven gameplay features. I have a modular ability/support system akin to Path of Exiles in the rogue-lite I'm working on right now as an example of that. Anything that can have a numerical property that could be changed can have a stat, and a stat is a class that can contain and manage its own modifiers with unique name references in dictionaries so that things which have given those modifiers can connect their exit_tree() and other signals to the stat's remove_modifier function to dynamically remove their modifier. It lets me hot-swap around anything in the game in real-time without having to recalculate a lot of stuff all at once. Quite nice for finding powerups that could affect a lot of things all at once. Of course, that wouldn't work without a script that dynamically explores the node tree quickly to find the stat that needs to have a modifier applied (I do this fast by just reducing the search parameters up-front as much as possible with focused searching). Sorry, here I am gushing, but I legit figured most of this out by myself. It's hard not to be a little proud about it. lol I had actually never considered using metadata. It has some potential, but it's no more effective than reserving a dictionary for the same exact purpose. I guess metadata is that dictionary for us, so that we don't need to make our own all the time. I mean, that really is 99% of it's functionality. It's got some additional searching methods, but it's not more efficient than those a dictionary type already has, they're just a little easier to read in the code than strictly using dictionary methods and access patterns.
@@keithwinget6521 That's an interesting approach. I don't like using "is" for this purpose because "is" requires you to compare it to the class_name you want to check which creates dependencies, which I try to avoid at all cost for components. GDScript does have a get_class() method that returns the class name, however, it cannot be overridden in the current incarnation of GDScript, so it only works for the Nodes that come with Godot 4 (i.e. Node2D, Area2D, etc.). Allowing overrides of imbedded methods would solve several issues with GDScript, but maybe someday. Maybe there is some other way to do this that I'm not aware of, but I have read many threads complaining about not being able to get the class_name (as a string) of the attached GDScript. It would be a welcome feature.
You can do the exact same thing that you did with the groups... just use case switch based upon what group is present. But I do like the fact that I have another tool now. thank you
Good timing. Exploring some way to leave notes in the project (for collaboration, reminder, or communication with myself in the future). I created custom Resources for that, and attached it to a script in the Scene. But with metadata, you can do that without a script. I tried it just now, could work (and have the benefit to not have to create a script to attach to), but the Editor for metadata, contrary to a script, don't filter to the custom Resource that I need. A workaround is to drag and drop the resource, or quick search it. But you lose some friendly intuitive way of doing things that way (and can be prone error). For now, the cons with that way of doing things are : - you can't store the custom resource in the scene file (break the benefit of having a sole location in the Editor) - you cant' create a new instance of the custom resource, and then save it if needed for reuse - you can't change the location of the metadata in the Editor for custom workflow Still, good to know that you can add metadata, will definitely find ways to use it somewhere in the future
Update, answering to myself. Actually (just before deleting the test), I found a good way to still use it in my use case... - I can create and store a custom property attached to the script - then save it as a custom resource file - and use it in some Nodes as metadata (without script then), referencing the same custom resource Acts as a post-it spread here and there if needed for quick notes of documentation purpose (like a refresher about a design concept, or contextual infos)
I can see the benefits. one example: use groups(or metadata strings) to all objects in a scene. then when clearing the labeled objects in scene having some use a metadata bool for its "state" to free up now or wait till its metadata is switched to free up state
I'm making an application, not a game. But i use meta data as database values. I load all the db values for a specific object to the metadata, and update those values. When it's time to save an object to the database i just use the meta data. So i basically use the metadata as a link between the database and Godot objects/nodes.
Metadata has uses, but it feels more like a workaround of the engine than a proper use. It clearly helps in flattening your inheritance tree, which you may like. And for fast prototyping is awesome. But I feel like metadata should be avoided if possibly on big team projects. As it will add hidden behavior to objects that may not be easy to spot by other people. Since it's clearly never meant to add behavior. If you are solo and are working on a small project go for it thou
I understand the concept, but can't think of a real work use for my games, I work mostly with C# so I love to abstract things, so to make the same different floor different sound, thing, but without metadata I'd just create an abstract class that would be named like surface and would have an exported property named stepsSound and would attach that script to each kind of floor, this would guarantee that every object that is a floor would have that property. Maybe I'm over complicating but I like the static typing and metadata appears to be something very broad and not guaranteed to be present
Just think of it as a way to include custom variables to an object without having to script it. Or, as an alternative, a collection of _unknown variables_ of various types, numbers, and data you can't control. Say, like, modifiers to a spell or vehicle that are _qualitative._
Another way you can use it is on physical objects (which is an extension of the "include custom variables to an object without a script). If you have a scripted area that changes the velocity of physical objects by reference, if can search for a "mass" variable on the metadata and alter how "hard" it gets pushed, etc. Now you don't need to record look-up tables and all objects can have their own unique mass.
I mean, even if you can't put your mind to it (understandably)... You like most programmers understand on instinctual/subconscious level that it's just useless lmao. I would go even one step further, it's a bad practice. This guy might have chosen the worst types of example, for this. As the name "meta" + "data" suggests, it's something that goes beyond the standard understanding. "Meta" comes from Aristotle's "META"-physics ('ta meta ta fysika'), which means "that which comes after physics", where he discusses concepts that go beyond material plane. He seem to treat 'meta' just like regular data (that is extremely unsafe/mutable as you don't even have a script object). What would I use it for? For multiplayer or general player's event-tracking for data-collection (eg. You have a single-player game and you collect, which events or dialogues they triggered as a data points). For example you have metadata packages that correspond to how many players and when they stepped or triggered on something. It's an easy solution in-engine that doesn't require external functionalities or plugins. There are like 2-3 external libraries that do analytics, but they are heavy, not really ideal and might be complicated. If you just want a simple data collection, then you have more control over it by doing it yourself. To be clear, I don't think it's an ideal solution for a large scale project, but it's good enough for prototyping and iteration. All you need is "SQLite Godot" for a database. It's literally as simple as passing the variable in JSON... Metadata seems INSANELY good when you think about it this way, as it doesn't really interact with the game data (it's "meta", so 'after' it). It doesn't create any scripts or modify the game itself UNLESS you write that functionality in the code like this person ("if it has metadata then do XYZ"). I wouldn't use it as a 'quick' data substitute, that you can just 'pop' in, as the video suggests. People in gamedev seem to have unhealthy fetish for mutable data with side effects and then they cry tears that their code is shyt and they get lots of bugs or unintended behaviour... Then maybe don't use things like metadata and use a proper IMMUTABLE structures? Even Godot officials are aware of this potential problem (because they are good programmers, I guess? Who would have thought right?). We can read: "set_meta can be useful to store information that the object itself does NOT(!) depend on. To keep your code clean, making excessive use of metadata is DISCOURAGED(!)." This guy is using metadata CONTRARY to what is it's intended use. As in his example, these objects DEPEND(!) on their type recognition, as it fundamentally changes game functionality (different friction physics & sounds). My proposition for using it as an analytics tracking seems to be one of the intended usages. Basically it's a type of data that is meant to be used as a commentary for the developer for either debugging purposes or to "note" on how player's data impacts the game. PS. To solve his problems there are literally dozens other methods that are less complicated... You can use a dictionary; you can use inheritance & polymorphism; you can use composition to encapsulate behaviours; you can even use functional approach... Simple solution: Create a 'TypeObject.gd' -> extends CSGBox3D var object_type: String = "" static var type_behaviors = { "grass": func(obj): print(obj.name, " is grass. Waving in the wind."), "metal": func(obj): print(obj.name, " is metal. Clanging sound.") } func set_type(type: String): object_type = type func get_type() -> String: return object_type func process(): if object_type in type_behaviors: type_behaviors[object_type].call(self) Then you have an object like 'grass.gd': extends "TypedObject.gd" # Called when the node enters the scene tree for the first time. func _ready() -> void: connect("body_entered", Callable(Area3D, "_on_area_3d_body_shape_entered")) print("CSGBox ready and waiting for collision") set_type("grass") process() func _process(_delta: float) -> void: pass func _on_area_3d_body_shape_entered(_body_rid: RID, body: Node3D, _body_shape_index: int, _local_shape_index: int) -> void: if body.name == "Player": print("Collided") set_type("metal") process() if object_type == "metal": self.material.albedo_color = Color(0, 1, 0) # Change to green For this I set up a CSGBox3D with Area3D child and CollisionShape3D child (yes, shytty workaround). When you collide it changes type What we get is: "CSGBox ready and waiting for collision grass is grass. Waving in the wind. Collided grass is metal. Clanging sound." It's literally like re-inventing the wheel, when inheritance literally exists in Godot. It's not as deep as in Java for example (there is no multiple inheritance), but the child node system is a workaround for it. I think my code even though shytty is simple and elegant, it shows the idea. Bro, if you had to type "if object.has_meta(material)" and if it matches object.get_meta("material"): grass... Then you would probably lose your mind. The same way I think you can quite easily loose track of how you call all those metadatas and categorize them. Using this class method, you DON'T have to specify the behaviour, since it's already specified in the class how it behaves....... Also, if you make a one parent class that inherits to the children then... Then you can simply enter this parent class and check how it works & edit it every time at your whim. Using some silly metadata you will just jump from code to code, very disorganized. My feedback would be: Bro, if you want to use metadata. Then just use it as an analytics tool. Connect Godot-SQLite and show people how you can pass metadata to your database using JSON. How cool is that man?
I think that in all of these examples, you would be better creating custom resources with a method like "handle_walk_on_sound" for example, so you can use composition + polymorphism to avoid huge match cases. To me, you should use metadata to add "meta" informations to nodes. A stupid example on top of my head : imagine you want to store the time at which a node did something in particular, then you would set metadata at runtime on the node. Don't forget to try to type your metadata so you dont rely on magic strings
The main benefit is if you don't want to attach a script to the object. For the case example in the video, you wouldn't need to attach an "object" script to each object in your game, but instead attach metadata for the material, and then you'd still have the flexibility to code any other logic for different types of objects aside from the using scripts
also if you're creating nodes programmatically but still need them to carry information they can't by default. for example creating UI buttons based on a dynamic number of choices, and they need to transmit unique data on clicked signal, you can attach the data to each button on creation with `set_meta()`
While the example you pointed out is interesting i would not be setting metadata from the editor for the simple reason it is too prone to human error, i would preffer to set it from script on ready
It all depend on the job. Didn't know this features. Plus this game engine suppose be module in some ways. It help sort which nodes are using meta data. For example break down the turret as it own module part that can be change without need to script. Just 3D model with meta data. For speed it turn. Mount points.
I used it to set meta for buttons (which are instanced in code) so when I click I can get the meta data to do stuff. Making many scripts, variables, groups can get messy. Also I'm going to use it for sfx's. I can just attach sound resource to a node and make audiostreamplayer to play that meta sound resource :D
With your current logic of metadata, are you doing almost the same as with groups, yeah maybe the condition is better, but I don't think is a good example. I think the good solution will be to have in the metadata the diferent keys or modifiers you need. that way you should avoid having conditions. and should be as simple as get_meta("sound"), check is there, reproduce sound. get_meta("friction"), apply friction...
So if I understand correctly, in my game I plan to have several spaceships of the same kind in a fleet, I could use metadata to give each of them an unique name, record unique hull damages, and things like that?
If i create a resource metadata that has multiple variables and i only want to get one variable. How do i go about doing that? Edit: For those of you who had the same question. I think its best to have a resource as Metadata. Just create a variable for it
What would happen if you were getting two separate sets of metadata that would conflict. Using your floor material example, what if you were standing on both a grass and metal tile because the game doesn't restrict you to a single location. Assuming you didn't build the system to only check whatever material is at the end of a specific vector or something, thereby limiting that, you'd get both properties returned, wouldn't you? I don't think the example is the best for my question because there's a lot of ways to avoid even being in that situation, but I'm just curious on whether or not there would be such an issue with using metadata that could conflict with things in such a way that you'd want to use some other system instead.
Bro this is so cool can you actually attach resources like this withoit creating a cyclic reference ? For example i got item resources that hold my guns scenes so can i attach the item scene to the guns?
Interesting. Would it become hard to trace when you have a bigger project, like forgetten what meta data you have in which nodes in which scene? Sometimes I find it impossible to remember what groups I have set up where. Is there some smart search method for metadata?
I doubt it as well but it might have some potential if any node can access it without any signals. Imagine accessing property of any node in a scene without coming in contact with it. Hehe
I don't get it. You said you can use metadata to avoid using a script, yet you still use a script to access and set the node's metadata. What different functionality does this provide than a regular export variable?
The idea is the script accesing the metadata is not the same one holding the metadata, so you make this check instead of _ready in example _on_body_entered_area() or in process if is_on_floor() get_colliding_bodies()
You're not having to constantly check every single object for all of those types, just checking if the object has the method, then you get that value if it does, then you operate on that directly. Yeah, the example wasn't the greatest, but that's because of A) he was keeping it simple, and B) as he said at the end, it isn't something people have to use and there are other ways of doing it, but he wanted to make the video to let people know that it is an option if you want it.
5:06 and 6:20 have literally nothing to do with using metadata or groups. Whatsoever I'm willing to go to the point that using groups in your example is much much better than using metadata, because with groups you're more organised, while using metadata is more open to making mistakes (like miss-spelling something). An actual useful (and "makes sense") example could've been item attributes. For example, you could add "Damage" as metadata to a sword, and "Armor" as metadata to a Chestplate (aka attributes that could be on many items, but not on others). A counter example for this is "price", because every item can have a price, but not every item can have damage/armor modifiers.
I totally agree. I used meta and almost immediately I lost my job as a senior robot polisher and my girlfriend left me for a scruffy hunched-backed busker she met on the subway. Messed up my whole life. Don't use it unless you have no other option.
Well this topic is more controversial than I thought! 😅
Please leave a comment if you have any feedback on the methods shown in this video, or want to share another way to use metadata!
(Let's make this video a collection of metadata information/usage, since there doesn't seem to be much out there yet)
I've always wondered what I would use metadata for... Today I'm dealing with the detection of surfaces (grass, gravel, stones, ...) and lo and behold.
Thanks for the idea 🔥
bruh i m doing same xD
I never really messed with metadata but it's really interesting as I now think about it.
🤔 I _think_ I would roughly come up with a rule of thumb now like so:
Is it about your object sharing the same property with other objects? And is it likely that you will search for all of those objects with the same property to do stuff with them?
For example: _"I have a building object and I need that one as well as all other building objects in my scene tree to start burning."_
→ Use groups. You can simply use the group-related methods of your scene tree to grab all building objects and make them burn or whatever.
Is it about your object having a property regardless of if other objects with the same property exist? And you only care about that property when dealing with the one object to detect stuff or to identify specific behaviors?
For example: _"Is my game character looking at a building or at a monument so that I can display a little infobox for the object?"_
→ Use metadata. "Ask" your currently looked at object for its purpose and display either a memorial tablet or residental stats or whatever.
As others have stated, this could be easily done with exported variables but then you're right, this always needs a script to be attached to it.
Other than that I'd like to add that even if a script is attached you might not like the idea of adding that one exported variable to the script for whatever reason (maybe because the script has some basic function in your class hierarchy that many different objects share … whatever else reason there could be doesn't matter actually in detail, main point is you don't want to add that export var).
So you would have, of course, the opportunity to inherit that script class with another one to add just a little variable export. But that could lead to lots of classes inheriting from that base one you didn't want to touch and also another potential issue is coming up.
Let's say you got a `GameObject` script attached to all game objects and now you wanna inherit that one to get a `BuildingObject` and another one to get a `MonumentObject`, both with different export variables (like size, year of construction, cost, sponsors, a label with who or what is honored, and whatnot). This would work until you would need something like a `MonumentalBuildingObject`. Then things could easily get out of hands because you need all export vars from the building and also all export vars from the monument … now let that thing be built out of grass. 😉 And that's when things could easily get out of hands.
By using metadata you could get rid of problems that polymorphism brings, I guess.
Why not still using groups in that case? - Well, because a group is nothing more that a string value attached to an object. But as pointed out in the video metadata can have one of many datatypes. Could be a string, a number, a vector, anything. That makes you more flexible in how to deal with your metadata (in comparison to a group).
As said, I never used metadata in any project but I'm starting to think about considering it for a few situations at least. It's really something I should have thought about earlier. Extremely interesting the more I think about it.
That being said, thanks for the video! Keep up and best of luck! 😘👍
PS: Hope I could explain myself well enough. Non-native speaker over here.
From what I can gather, metadata is useful, if you need certain properties that some classes or individual objects have and are not critical to classes, objects and inheriting classes.
From your example, some things might need descriptions and others don't need that. Since descriptions only affect info box script, metadata might be preferable then adding "description" variable to every script in game in hopes that eventually single random thing will need to be described.
At least that is how I interpreted this.
I'm starting to wonder if we might also use metadata as a replacement for somethings that people have used componetization for.
For example, someone might have made a health component which has a script to control that health and signal anything that needs to update because of it changing. That would probably be something you'd use an export variable on for the max health.
But what about damage? Sure you'd have a script probably to handle the actual dealing of damage, but what if your game has elemental damage types? And probably resistances to those types as well? Well instead of having 2n extra exports purely for how much elemental damage they deal and resist you could have metadata for any that are different from a baseline (0 damage dealt and 100% taken most likely) which would then allow that damage compenent to check the required values on the entity and apply it accordingly. Although, now that I read this again, this was more about using components and metadata together rather than replacing one with the other.
An example of replacing it would be if you had a score component which the only purpose of was to have an export value for the score and then upon recieving the death flag it would send that score. Instead of using that you could just use the metadata and have that checked by whatever handled the dying state.
Or it could be used for contextual button prompts. If the object has_meta("context button") then display that button when the vector is pointed at it.
i've been using godot for like a year and i've never heard of this before, no one talks about them no one uses them yet i see great potential, it amazes how no one even bothered to talk about a feature like this, Thank you bro
Wait youre telling me the button below the script actually does something??
@@poleve5409Learn some manners.
@@poleve5409 Metadata has a button and it is listed under the script within the editor description section so they weren't wrong about it being below the script.
However, you ARE wrong about it being below the inspector because it is _inside_ the inspector that you access it. So take your advies and never talk again. XD
@@poleve5409 im not talking, im typing
@@sujimayne How have 22 people liked this? This was the most blatantly sarcastic/satirical comment I've seen in my life
Sorry to say this but,
Ur explanation was so long that I had to skip it.😊
Sorry 😅
maybe I'm quite late to the party :D
and I agree that the "Switch vs If/Else" example wasn't that good, but I think that the concept is still clear.
I'd personally do something like this: Add a metadata to the sprites called "frictionModifier" which is an int and if the player is on top of the sprite, I'd just do something like: "movementSpeed *= get_meta(frictionModifier)" basically. Therefore I don't need a branching structure at all and I can achieve a different behaviour for different materials, without having to define a script. Sure if the material gets lots of metadata or if I need to do some custom logic, I'd probably still use a script.
I've never used this concept before, but for me it's well suited for "static data for a specific thing". Using this for materials is really neat, because those tend to be static anyway.
Thanks for your video :)!
You do bring up an interesting discussion, which I believe has and will be around forever as long as there are programmers around. So, I guess I gotta get my opinion out on this, too :P
First off, I like that you didn't advertise metadata as an all-round solution for everything since there are usually multiple concepts that work roughly equally well, depending on the scope of the project.
Though, I must say, I did not quite get your entire point for metadata. The main reason being that your given example doesn't really achieve more than changing your script from using if-statements to a switch-statement.
Additionally, - and this is a bit beside the topic, but... - to me, this seems more like a job for inheritance: Since all the different properties of floors could just be inherited to the objects and I wouldn't have to keep track of the property names when assigning metadata.
Going from there, I feel like you may have focused a bit too much on showing how you can use metadata instead of groups while they are two fundamentally different things: Groups are meant to provide an easy way to access many nodes at the same time and give some meta-structure to your node-tree without changing the render hierarchy; Metatada are properties which are attached to singular nodes and should thus enhance or describe that node individually.
In my opinion, it is this distinction that gives both their utility and rightful purpose in the first place. As such, I don't see much reason to compare them over problems where they are a bit less or more useful since they solve completely different problems to begin with.
"The main reason being that your given example doesn't really achieve more than changing your script from using if-statements to a switch-statement" THIS!
I think the example was very weak and hoping there is a better example to demostrate why one would use it over Groups. I personally prefer groups because like you say you can call many all nodes within a group to do something, you can determine how many objects belong to a group quite easily. With meta I see it like adding a Var to a node without having to apply a script, which could be useful?
Agreed the "look you can use a switch statement instead of if-else by using metadata instead of groups" didn't really grab me. I'd definitely still use groups for something that belongs to a group.
My take away is that metadata is simply for when you need some properties on a node but don't need a script. If you otherwise were just going to make a script that only held some simple variables and no functionality: metadata. Which, yes, is a different use case than groups.
I see this being useful for something like let's say picking up a health jar where maybe you don't want a script on the jar just to queue_free() it so you do that on the player script, but you need the health jar to have the amount of health it provides, so you make an integer metadata value on the jar. Could also work with a weapon, maybe the weapon needs no functionality but just needs an attack power. Or as another commenter suggest a sign that just needs a string of text to pop up for what the sign says when the player gets close.
W video, I use metadata to store resource files across UI elements, such as inside a Tree node. Makes it so much easier to make editors for complex game resources!
Could you explain what you mean by thiss? I'm failing to picture what you're doing and how that makes things easier. Always waant things to be easier if they can be XD
Yeah curious for an explanation of this if you don't mind
This is also a very good way to implement soft modding into your game. It's what Minecraft is doing with commands/datapacks. You can essentially change the game's behaviour without giving players access to the code. Although it's very limiting, people have made a whole database saving system with it as well, so it's a matter of knowledge and time before they start doing crazier stuff
I created a simple interaction system for myself, and I made use of metadata.
Basically, any node that has the target metadata can be interacted with.
that would be similar to groups, depending on what you want groups might be the better option because what if you want to disable all of the interactions, using metadata might not be the right thing, while groups you can grab all of them.
Cool but I just don't see a use case that exports and composition can't do better. Maybe I would use it very temporarily but not as part of the final game's core logic, also having proper code completion with the fields actually being part of the node is nice.
if I might add something to your comment: I'd even go as far as saying that the surface detection example could have been achieved in a much cleaner and maintainable way by using inheritance. I still don't see any reason to make my code harder to read by using metadata instead of exports, composition or inheritance.
I thought the same. Even the prime example for it over groups, for me it introduces more issues of user error.
I also find myself using resources to avoid having to use strings as much as possible is grass feels better than is "grass" because I trust intellisense more than myself haha :D
I still can't see having meta_data as more useful than setting up a "type" or enums. But I'm glad it's there to be used regardless of what people use it for. Maybe there are better examples?
@@CielCat Exactly
@@rungeon83 Yeah idk, only real example I can think of is prototyping maybe, like having hardcoded references to $NodeName in your scripts. By the end of it I would want it to be type-safe, or only reference nodes or in this case metadata that are explicitly part of the nodes.
I understand that it could technically be used as a way to only execute certain code if a node has certain data, but at that point I would just make my own new component scripts rather than writing absolutely all of it on the base node. Idk brain is still blanking on how it might be useful as part of the core code and not just as a way to test something real quick.
@@rungeon83 I think metadata is more useful for things that would differentiate from the norm.
An example someone else gave is stats on items: Most items would probably have a sell price, but not every item needs an attack and defense value. Now you absolutely could just use inheritance to create multiple class types (weapons, armors, usable items, materials, key items that don't have a sell price, etc.) and then only apply the needed values but that requires two things: One is that every value in that given class _must be_ addressed even with a default value and that nothing that uses that class will require something else.
We often alleviate that with componentization to give a few extra datapoints or things that would be interchangable like a health component, but it's also completely possible to set up items with metadata for things like category, stats, sell price, rarity, etc. You'd then operate on the metadata in essentially the same way as though you had built the classes for them. Caveat being that you don't necessarily require a script on the item itself for it. But as has been said, this comes at the cost of making sure that you type things correctly and lack of intellisense to catch if you have messed up anywhere which means that bug fixing becomes more of an issue. That could potentially be alleviate in the future if Godot adds more metadata support, but I've long since learned not to expect Godot to update/fix specifically one thing or another XD
To give an example of something I did that I probably could have used metadata for:
I had a little idle clicker game. It had a 3 categories of upgrades and for these upgrades I had one super class and then a class that inherited it for each of the upgrade types.
Each upgrade type worked on slightly different logic: One was to upgrade the 'generators,' another to upgrade the material mining, and lastly the final category which just made thigns more efficient.
Had I known about metadata then I would've set things up such that the currency required for each upgrade was in a metadata, especially when one of them wasn't actually a currency but rather a metric of how deep the mining had gone (didn't want people upgrading too fast so I tied it to progress). Instead I had a function that handled every possible item type that could be used in each category, and made each of the 3 subclasses have the same exact function, adjusted for the category, to handle it when really most of them were all items that I could've just had 2 checks for: is that metadata 'depth'? if not then treat it as an item.
I did build the whole game using just inheritance, but it actually ended up being even more messy because of it (and because I hadn't learned componentization yet, but I doubt it would've been much better). So it isn't like it was an impossible thing to do without metadata, but that metadata might've made it a little bit cleaner.
Keyword being _might've._
YES THAT WAS EXACTLY WHAT I WAS LOOKING FOR. THAANKS SO MUCH
I think your example would combine nicely with the strategy pattern. You could create a custom resource type and load it up with values for footstep_sound_effect, friction_value, etc... then the player can just call material.do_stuff() and it doesn't need to keep a potentially growing list of all the possible materials and their respective logic.
I also think you glossed over a different big advantage of Metadata. It's great for if you want to add properties to a node w/o giving it a script, but it's *perfect* for giving properties to a node that might "conflict" with the script it already has. Take for example if you had a node with a MovingPlatform script, you wouldn't want to add material data to that b/c it isn't relevant to "moving platform" logic. But Metadata is a great way to make those values available w/o having to muddy up your script
the way I see metadata here is the way i see new properties in blender. it can be very helpful combined with drivers.
it depends on how do you prefer really. there is not a "must" or something like that but I'm sure I'm gonna use it later. (I'm new to godot and still learning it)
I use metadata to fix the problem with GDScript not being able to determine Script class_name inheritance. Every one of my components has a "BaseComponentName" string and a "ComponentName" string in metadata entry. That way I can easily determine what hierarchy the Components share. Yes, it could have been done with Groups, but I didn't want the Group Editor to get overly crowded. This way, I can determine if all the required components are present on my parent scene by just checking the metadata of the children. Also, by using Metadata, it is transferable from project to project without adding and re-assigning all the groups.
This is fascinating, can you expand on what you mean by components or give an example?
I sometimes find it annoying to figure out which of my scripts for for custom resources and which ones are base classes that have been extended from and etc
@@young_kdo9877 Sure, but it is a fairly long explanation. Is there something specific you want to know, or just an overview of how I implement my component architecture? I don't want to hijack Queble's thread here. 🙁
I haven't had this problem with my components. I've always been able to make strong use of class_name inheritance using things like "is" and the like for conditionals. Then again, In using components, I've strayed rather far from depending much on inheritance in most cases. It's still useful in part to extend the node feature-set to accommodate a greater variety of organizational tools. I mostly use a component system to allow myself considerable modularity in designing complex stat-driven gameplay features. I have a modular ability/support system akin to Path of Exiles in the rogue-lite I'm working on right now as an example of that. Anything that can have a numerical property that could be changed can have a stat, and a stat is a class that can contain and manage its own modifiers with unique name references in dictionaries so that things which have given those modifiers can connect their exit_tree() and other signals to the stat's remove_modifier function to dynamically remove their modifier. It lets me hot-swap around anything in the game in real-time without having to recalculate a lot of stuff all at once. Quite nice for finding powerups that could affect a lot of things all at once. Of course, that wouldn't work without a script that dynamically explores the node tree quickly to find the stat that needs to have a modifier applied (I do this fast by just reducing the search parameters up-front as much as possible with focused searching). Sorry, here I am gushing, but I legit figured most of this out by myself. It's hard not to be a little proud about it. lol I had actually never considered using metadata. It has some potential, but it's no more effective than reserving a dictionary for the same exact purpose. I guess metadata is that dictionary for us, so that we don't need to make our own all the time. I mean, that really is 99% of it's functionality. It's got some additional searching methods, but it's not more efficient than those a dictionary type already has, they're just a little easier to read in the code than strictly using dictionary methods and access patterns.
@@keithwinget6521 That's an interesting approach. I don't like using "is" for this purpose because "is" requires you to compare it to the class_name you want to check which creates dependencies, which I try to avoid at all cost for components. GDScript does have a get_class() method that returns the class name, however, it cannot be overridden in the current incarnation of GDScript, so it only works for the Nodes that come with Godot 4 (i.e. Node2D, Area2D, etc.). Allowing overrides of imbedded methods would solve several issues with GDScript, but maybe someday. Maybe there is some other way to do this that I'm not aware of, but I have read many threads complaining about not being able to get the class_name (as a string) of the attached GDScript. It would be a welcome feature.
You can do the exact same thing that you did with the groups... just use case switch based upon what group is present. But I do like the fact that I have another tool now. thank you
Good timing.
Exploring some way to leave notes in the project (for collaboration, reminder, or communication with myself in the future). I created custom Resources for that, and attached it to a script in the Scene. But with metadata, you can do that without a script.
I tried it just now, could work (and have the benefit to not have to create a script to attach to), but the Editor for metadata, contrary to a script, don't filter to the custom Resource that I need.
A workaround is to drag and drop the resource, or quick search it. But you lose some friendly intuitive way of doing things that way (and can be prone error).
For now, the cons with that way of doing things are :
- you can't store the custom resource in the scene file (break the benefit of having a sole location in the Editor)
- you cant' create a new instance of the custom resource, and then save it if needed for reuse
- you can't change the location of the metadata in the Editor for custom workflow
Still, good to know that you can add metadata, will definitely find ways to use it somewhere in the future
Update, answering to myself.
Actually (just before deleting the test), I found a good way to still use it in my use case...
- I can create and store a custom property attached to the script
- then save it as a custom resource file
- and use it in some Nodes as metadata (without script then), referencing the same custom resource
Acts as a post-it spread here and there if needed for quick notes of documentation purpose (like a refresher about a design concept, or contextual infos)
I can see the benefits. one example: use groups(or metadata strings) to all objects in a scene. then when clearing the labeled objects in scene having some use a metadata bool for its "state" to free up now or wait till its metadata is switched to free up state
I'm making an application, not a game. But i use meta data as database values. I load all the db values for a specific object to the metadata, and update those values. When it's time to save an object to the database i just use the meta data.
So i basically use the metadata as a link between the database and Godot objects/nodes.
Metadata has uses, but it feels more like a workaround of the engine than a proper use.
It clearly helps in flattening your inheritance tree, which you may like. And for fast prototyping is awesome.
But I feel like metadata should be avoided if possibly on big team projects. As it will add hidden behavior to objects that may not be easy to spot by other people. Since it's clearly never meant to add behavior.
If you are solo and are working on a small project go for it thou
I agree 💯
I understand the concept, but can't think of a real work use for my games, I work mostly with C# so I love to abstract things, so to make the same different floor different sound, thing, but without metadata I'd just create an abstract class that would be named like surface and would have an exported property named stepsSound and would attach that script to each kind of floor, this would guarantee that every object that is a floor would have that property. Maybe I'm over complicating but I like the static typing and metadata appears to be something very broad and not guaranteed to be present
Just think of it as a way to include custom variables to an object without having to script it. Or, as an alternative, a collection of _unknown variables_ of various types, numbers, and data you can't control. Say, like, modifiers to a spell or vehicle that are _qualitative._
Another way you can use it is on physical objects (which is an extension of the "include custom variables to an object without a script). If you have a scripted area that changes the velocity of physical objects by reference, if can search for a "mass" variable on the metadata and alter how "hard" it gets pushed, etc. Now you don't need to record look-up tables and all objects can have their own unique mass.
I mean, even if you can't put your mind to it (understandably)... You like most programmers understand on instinctual/subconscious level that it's just useless lmao. I would go even one step further, it's a bad practice.
This guy might have chosen the worst types of example, for this. As the name "meta" + "data" suggests, it's something that goes beyond the standard understanding. "Meta" comes from Aristotle's "META"-physics ('ta meta ta fysika'), which means "that which comes after physics", where he discusses concepts that go beyond material plane.
He seem to treat 'meta' just like regular data (that is extremely unsafe/mutable as you don't even have a script object). What would I use it for? For multiplayer or general player's event-tracking for data-collection (eg. You have a single-player game and you collect, which events or dialogues they triggered as a data points). For example you have metadata packages that correspond to how many players and when they stepped or triggered on something. It's an easy solution in-engine that doesn't require external functionalities or plugins.
There are like 2-3 external libraries that do analytics, but they are heavy, not really ideal and might be complicated. If you just want a simple data collection, then you have more control over it by doing it yourself. To be clear, I don't think it's an ideal solution for a large scale project, but it's good enough for prototyping and iteration. All you need is "SQLite Godot" for a database. It's literally as simple as passing the variable in JSON...
Metadata seems INSANELY good when you think about it this way, as it doesn't really interact with the game data (it's "meta", so 'after' it). It doesn't create any scripts or modify the game itself UNLESS you write that functionality in the code like this person ("if it has metadata then do XYZ").
I wouldn't use it as a 'quick' data substitute, that you can just 'pop' in, as the video suggests. People in gamedev seem to have unhealthy fetish for mutable data with side effects and then they cry tears that their code is shyt and they get lots of bugs or unintended behaviour... Then maybe don't use things like metadata and use a proper IMMUTABLE structures?
Even Godot officials are aware of this potential problem (because they are good programmers, I guess? Who would have thought right?). We can read: "set_meta can be useful to store information that the object itself does NOT(!) depend on. To keep your code clean, making excessive use of metadata is DISCOURAGED(!)."
This guy is using metadata CONTRARY to what is it's intended use. As in his example, these objects DEPEND(!) on their type recognition, as it fundamentally changes game functionality (different friction physics & sounds). My proposition for using it as an analytics tracking seems to be one of the intended usages.
Basically it's a type of data that is meant to be used as a commentary for the developer for either debugging purposes or to "note" on how player's data impacts the game.
PS. To solve his problems there are literally dozens other methods that are less complicated... You can use a dictionary; you can use inheritance & polymorphism; you can use composition to encapsulate behaviours; you can even use functional approach...
Simple solution: Create a 'TypeObject.gd' -> extends CSGBox3D
var object_type: String = ""
static var type_behaviors = {
"grass": func(obj): print(obj.name, " is grass. Waving in the wind."),
"metal": func(obj): print(obj.name, " is metal. Clanging sound.")
}
func set_type(type: String):
object_type = type
func get_type() -> String:
return object_type
func process():
if object_type in type_behaviors:
type_behaviors[object_type].call(self)
Then you have an object like 'grass.gd':
extends "TypedObject.gd"
# Called when the node enters the scene tree for the first time.
func _ready() -> void:
connect("body_entered", Callable(Area3D, "_on_area_3d_body_shape_entered"))
print("CSGBox ready and waiting for collision")
set_type("grass")
process()
func _process(_delta: float) -> void:
pass
func _on_area_3d_body_shape_entered(_body_rid: RID, body: Node3D, _body_shape_index: int, _local_shape_index: int) -> void:
if body.name == "Player":
print("Collided")
set_type("metal")
process()
if object_type == "metal":
self.material.albedo_color = Color(0, 1, 0) # Change to green
For this I set up a CSGBox3D with Area3D child and CollisionShape3D child (yes, shytty workaround). When you collide it changes type What we get is:
"CSGBox ready and waiting for collision
grass is grass. Waving in the wind.
Collided
grass is metal. Clanging sound."
It's literally like re-inventing the wheel, when inheritance literally exists in Godot. It's not as deep as in Java for example (there is no multiple inheritance), but the child node system is a workaround for it. I think my code even though shytty is simple and elegant, it shows the idea.
Bro, if you had to type "if object.has_meta(material)" and if it matches object.get_meta("material"): grass... Then you would probably lose your mind. The same way I think you can quite easily loose track of how you call all those metadatas and categorize them. Using this class method, you DON'T have to specify the behaviour, since it's already specified in the class how it behaves.......
Also, if you make a one parent class that inherits to the children then... Then you can simply enter this parent class and check how it works & edit it every time at your whim. Using some silly metadata you will just jump from code to code, very disorganized.
My feedback would be: Bro, if you want to use metadata. Then just use it as an analytics tool. Connect Godot-SQLite and show people how you can pass metadata to your database using JSON. How cool is that man?
I think that in all of these examples, you would be better creating custom resources with a method like "handle_walk_on_sound" for example, so you can use composition + polymorphism to avoid huge match cases.
To me, you should use metadata to add "meta" informations to nodes.
A stupid example on top of my head : imagine you want to store the time at which a node did something in particular, then you would set metadata at runtime on the node.
Don't forget to try to type your metadata so you dont rely on magic strings
And why should we use meta data vs a exported variable?
The main benefit is if you don't want to attach a script to the object.
For the case example in the video, you wouldn't need to attach an "object" script to each object in your game, but instead attach metadata for the material, and then you'd still have the flexibility to code any other logic for different types of objects aside from the using scripts
@@queblegamedevelopment4143 You can't mean state machine - like mechanism
also if you're creating nodes programmatically but still need them to carry information they can't by default. for example creating UI buttons based on a dynamic number of choices, and they need to transmit unique data on clicked signal, you can attach the data to each button on creation with `set_meta()`
While the example you pointed out is interesting i would not be setting metadata from the editor for the simple reason it is too prone to human error, i would preffer to set it from script on ready
It all depend on the job. Didn't know this features. Plus this game engine suppose be module in some ways. It help sort which nodes are using meta data. For example break down the turret as it own module part that can be change without need to script. Just 3D model with meta data. For speed it turn. Mount points.
I used it to set meta for buttons (which are instanced in code) so when I click I can get the meta data to do stuff. Making many scripts, variables, groups can get messy. Also I'm going to use it for sfx's. I can just attach sound resource to a node and make audiostreamplayer to play that meta sound resource :D
With your current logic of metadata, are you doing almost the same as with groups, yeah maybe the condition is better, but I don't think is a good example. I think the good solution will be to have in the metadata the diferent keys or modifiers you need.
that way you should avoid having conditions. and should be as simple as get_meta("sound"), check is there, reproduce sound. get_meta("friction"), apply friction...
Thank you.
How to change theme?
So if I understand correctly, in my game I plan to have several spaceships of the same kind in a fleet, I could use metadata to give each of them an unique name, record unique hull damages, and things like that?
I hate / love that it's not a type safe retrial mechanism. But you can make it type safe if the rest of your code is type safe ;-).
OMG !!! this will solve so many things!!! thanks
Such as?
If i create a resource metadata that has multiple variables and i only want to get one variable. How do i go about doing that?
Edit: For those of you who had the same question. I think its best to have a resource as Metadata. Just create a variable for it
What would happen if you were getting two separate sets of metadata that would conflict.
Using your floor material example, what if you were standing on both a grass and metal tile because the game doesn't restrict you to a single location. Assuming you didn't build the system to only check whatever material is at the end of a specific vector or something, thereby limiting that, you'd get both properties returned, wouldn't you?
I don't think the example is the best for my question because there's a lot of ways to avoid even being in that situation, but I'm just curious on whether or not there would be such an issue with using metadata that could conflict with things in such a way that you'd want to use some other system instead.
Bro this is so cool can you actually attach resources like this withoit creating a cyclic reference ?
For example i got item resources that hold my guns scenes so can i attach the item scene to the guns?
I'm having this same problem lol
Interesting. Would it become hard to trace when you have a bigger project, like forgetten what meta data you have in which nodes in which scene? Sometimes I find it impossible to remember what groups I have set up where. Is there some smart search method for metadata?
ty
ah this is kinda like using case switches... intresting
match is the case switch of gdscript, yes XD
But is this faster and more efficient in runtime?
Depends on how you use it.
I doubt it as well but it might have some potential if any node can access it without any signals.
Imagine accessing property of any node in a scene without coming in contact with it. Hehe
Queble Video
I don't get it. You said you can use metadata to avoid using a script, yet you still use a script to access and set the node's metadata. What different functionality does this provide than a regular export variable?
The idea is the script accesing the metadata is not the same one holding the metadata, so you make this check instead of _ready in example _on_body_entered_area() or in process if is_on_floor() get_colliding_bodies()
06:13 ? you only add an IF layer... what metadata semplify?
You're not having to constantly check every single object for all of those types, just checking if the object has the method, then you get that value if it does, then you operate on that directly. Yeah, the example wasn't the greatest, but that's because of A) he was keeping it simple, and B) as he said at the end, it isn't something people have to use and there are other ways of doing it, but he wanted to make the video to let people know that it is an option if you want it.
5:06 and 6:20 have literally nothing to do with using metadata or groups. Whatsoever I'm willing to go to the point that using groups in your example is much much better than using metadata, because with groups you're more organised, while using metadata is more open to making mistakes (like miss-spelling something).
An actual useful (and "makes sense") example could've been item attributes. For example, you could add "Damage" as metadata to a sword, and "Armor" as metadata to a Chestplate (aka attributes that could be on many items, but not on others). A counter example for this is "price", because every item can have a price, but not every item can have damage/armor modifiers.
learn something new, thank you
That is really not a great use for this, it leads to the same mess as groups.
I bet you were inspired by one of my videos. This is not a bad approach to using metadata.
appreciate the tutorials but have people told u that u look like Eminem lol
Don't use metadata at all. It will mess up your game/app.
Very bold take 😅
Would you please explain your reasoning for not using it? :)
How will it mess it up?
I totally agree. I used meta and almost immediately I lost my job as a senior robot polisher and my girlfriend left me for a scruffy hunched-backed busker she met on the subway. Messed up my whole life. Don't use it unless you have no other option.
@squarerootof2 😂😂
citation needed...
Godot died and Unity removed their fee.
Return to Unity or something else please