Does it make sense to add the player to the autoload?

Setting up my gun architecture, and I realized something. My player scene handles raycasting because it has the camera, so my gun scene needs to tell the player to raycast and return what the raycast hits. Well, to do that I need to access the player scene in the level. There's various ways to do this obviously, but I wondered:

Since the player is going to be accessed by a lot of things in this game, and the game is singleplayer, wouldn't it make sense just to add the player to the autoload so any script can access it easily?

Still slightly new to autoload, so what do you guys think? Does this make sense?

Answers

  • sparrow_altosparrow_alto Posts: 8Member

    I think it would make more sense to add the player to its own group. That way, you can access it just by calling get_tree().get_nodes_in_group() as long as the player exists in the scene.

    https://docs.godotengine.org/en/latest/tutorials/scripting/groups.html

  • Erich_LErich_L Posts: 590Member

    I'd say absolutely! I'd put a pointer to your player in your autoloaded Globals script.

  • cyberealitycybereality Posts: 3,714Moderator
    edited December 2021

    I wouldn't make the player themselves autoloaded. But one good use for autoloads is to have a sort of catchall global script that handles stuff for other objects. So you can make a reference to the player in the autoload, and other scripts, enemies or whatever can call:

    Global.player
    

    or:

    Global.get_player()
    

    The good part about this is that the player itself can handle registering with the Global script. So if you change the scene the player is in, or move stuff around the tree, things will still work without massive code changes. It is also good for stuff that should be available everywhere, like playing music, opening the options menu, quitting the game, etc.

  • OpinionatedGamerOpinionatedGamer Posts: 200Member

    Wow, thanks for all the answers guys, they are all pretty helpful, I didn't know about the get_nodes_in_group() function, so that will be really helpful (thanks @sparrow_alto ), and I really like the idea of a Globals autoload, so thanks @cyberreality and @Erich_L .

  • cyberealitycybereality Posts: 3,714Moderator

    Nodes in group is good to get a list of objects. You can use it to get all enemies in a level, for example. You can also sort of hack it, by just putting one item in the group, then when you call it you just get that item (like the player or the camera or stuff you know there is only one). However, if you are doing this often, and the list doesn't change, then either cache the result (maybe only call it on _ready() and then save the reference to the player) or just use the global autoload as that will be less code and potentially faster.

  • OpinionatedGamerOpinionatedGamer Posts: 200Member

    Was looking for an alternative to Unity's find_all_objects_of_type() function, and I guess this is it. Thanks!

  • OpinionatedGamerOpinionatedGamer Posts: 200Member

    ok, I ended up using the globals script like @cybereality suggested, and it works super well, but I also tried the other options and realized something important that I hadn't really thought about. Getting the node is different than getting the script attached to that node, which seems obvious but I had never really tried this.

    So how do i get access to a script through the node the script is attached to? I don't need this for my game yet, but I think it would be useful to know.

  • Erich_LErich_L Posts: 590Member

    @OpinionatedGamer Do you need access to the script to instantiate another copy of that node? Not clear as to why you're looking for that. If you just want to instance it you can leave a var for loading it:

    var pathingFile = load("res://Terrain/Pathing.gd")
    
    func doStuff():
        var pathing = pathingFile.new()
        #todo: add pathing to tree somewhere
    
Sign In or Register to comment.