Hi all, I made a system over in Unity where all the objects that have the same script (Resource) have an int that is a unique ID for identification on a server. The script was super simple, but I'm not sure how to recreate the same idea in gdscript. The way I had it set up, the first object that runs the code gets its serverID set to 1, and the next object that runs its version of the code is set to 2, so on and so forth. How would I do this with gdscript?

Also, does Godot not allow for multiple scripts on the same object?

  • xyz replied to this.

    CorvaNocta Add a static int property to the class. Let it store the next available id. In the class constructor assign the next available id to the regular id property. Increment the next available id.

    And yes, only one script can be attached to an object.

        xyz ah nice! That was easy!

        Shame about the single script. How do people split out their code for different functionality? When I was using Unity I could have a script for player movement and a different script for player inventory. Do people just use child nodes to get the same effect?

            CorvaNocta You solve problems as you would in any programming language that doesn't feature multiple class inheritance... which imho is a dimension of evil in and of itself 😃.

                CorvaNocta

                "Do people just use child nodes to get the same effect?"
                Normally yes, but it depends, when you start to get more confident with godot, you will see that this is an better aprouch, for your example "player moviment", you can create an Node called "PlayerMoviment" and attach it as an chield node to your char, if you want it to be an AI for example, it will have an AIMoviment insted, and so on...

                  CorvaNocta Shame about the single script. How do people split out their code for different functionality? When I was using Unity I could have a script for player movement and a different script for player inventory. Do people just use child nodes to get the same effect?

                  Yes, split your code into multiple components. It's pretty elegant if done correctly and IMHO better than Unity's giant blob objects.

                      Toxe I never minded the big objects 😁 it was pretty easy to just have lots of components.

                      But speaking of, how do I grab a specific node off of something? If I click on an object and it has a child object of "inventory", how do I access that node? Is there a way to search for a child node called "inventory"?

                          CorvaNocta as a godot cultist, i think you're cool.
                          i use giant objects all the time. i never split code into child nodes unless that code is explicitly for that node. so far the only downside is i have to use the "Filter Methods" search bar in the script editor a lot.
                          for both my and @CorvaNocta's sake, let me know if this is stupid and something terrible will happen to make me undo the entire last week's worth of code. i doubt it, i am a genius after all.

                              packrat If an object has a lot of work to do then it needs a lot of code. Nothing wrong with that 🙂

                                packrat The only "real" advantage to splitting code between the objects I can immediately think of is for logic that needs to be in process, but may not be needed all the time, so you can toggle processing on a node on or off to enable/disable that node/code branch. But you can do that just as easily with an if statement. Or match. Or whatever.

                                  CorvaNocta But speaking of, how do I grab a specific node off of something? If I click on an object and it has a child object of "inventory", how do I access that node? Is there a way to search for a child node called "inventory"?

                                  get_node("Inventory") or $Inventory. And there are also ways to search for nodes but you should not do that all the time.

                                    packrat i use giant objects all the time. i never split code into child nodes unless that code is explicitly for that node. so far the only downside is i have to use the "Filter Methods" search bar in the script editor a lot.

                                    It depends. If everything belongs together and it isn't too much code then it's fine to have it in one script. But personally I prefer to split my code into smaller components that each deal with (ideally) only one thing.

                                    For example in my Defender Clone I have the Main level scene. But that script only deals with the higher level logic like loading/unloading the level (World), ending it after the player got destroyed or starting the next level after all enemies got destroyed. Also some UI stuff.

                                    Even counting the score and dealing with lives and extra lives is done by two sub-components.

                                    The "real" physical level with all the enemies and the background is in the World scene. But this World scene itself doesn't do much work either. Instead it delegates most of the work to sub-components.

                                    There is one component that only handles the wrap-around of the player and enemies around the level. In Defender if the player or enemies fly all the way to one side they eventually come back in from the other side. meaning the level repeats.

                                    Then there is another component that only deals with the timing of spawn waves and a special type of enemy called "Baiter" that spawns after a while. But again this script only deals with the logic of spawn waves and it has no idea how to create the enemies themselves.

                                    Spawning the actual enemies in proper places and not too close too each other or the player is done by the spawn component.

                                    This is how I prefer to write my code. Break things down into smaller units that each deal with a little bit of logic. At least as long as it makes sense to do so. And if everything works out perfectly then I could even reuse those components without too many changes in other projects. For example a movement component or a "firing shots" component.

                                    I could of course put all the above code into the main level scene but that would make it quite long. Well, it's not too long, it would still be manageable, but yeah, I prefer to split my code apart a bit. But of course the problem with splitting it apart is that you need to look in several places and it's not always obvious how things are coupled.

                                        Also worth noting that not everything has to live in the SceneTree either - logic and data can quite often simply be a Custom Resource, which is (more or less) the same thing as Unity's ScriptableObject. An example here is the inventory mentioned - if it's just holding data for a view that's assigned to a node (doesn't matter what kind of node, but let's assume the player), then its logic and data could be a custom resource. And of course, a node could have many custom resources.

                                        Naturally, this highly depends on project and game structure and the level of effort required to create small, discrete bits of functionality versus monolithic objects and scenes.

                                          spaceyjase A lot of stuff doesn't even have to be in Resources. A plain RefCounted inherited class can suffice. Also the code that's not associated with any particular class/object can be held in custom static classes.

                                              4 days later

                                              Toxe makes a lot of sense! The layout is easy to follow too. Appreciate the examples!

                                              I think I will be splitting out my character like that. So I'll have primary node be generic player code, not much there. Then have a child node for the inventory, a child node for equipment, and so on. Should make it easy enough to follow!

                                                spaceyjase oh wow! I didn't even think a out doing that. It might take me a little while before I start trying to tackle that form of coding. Need to make sure I get the basics first too haha. But that is awesome to now!

                                                  xyz I think I will have to look at that soon too. That is going to help me a lot later on actually!

                                                    a year later

                                                    About generating unique IDs in GDScript, I've done something similar in the past, though not exactly for a resource system. For a quick setup, you could use a static variable in a singleton script to track the last used ID and increment it every time a new object is created. Then call generate_id() from your resource script when creating new objects. Also, on the server side, I’ve used the Identity Verification API before for handling unique identifiers and verifying user data securely. It’s pretty handy: https://www.idanalyzer.com . Maybe not directly related to your script, but thought I'd share since it could inspire ideas for secure ID management!