Using objects right - using the right objects

Help Programming
,
1

Godot Version

3.5

Question

Hello, I collected several general questions about objects in GD-Script.

I’m quite new to Godot (and this forum) and have some programming skills but not much. I have a little project and it grows bigger. It is a simulation. So I thought about restructuring it and am not sure which objects to choose for what purpose. It’s a thick fog I don’t see through.
Please excuse misused words, I’m non-nativ-writer.

What I Understood:
I won’t use the real object because I don’t have any clue about managing memory.
So:
Reference would be fine for serializable objects,
Ressource for nonserialized Data,
Node if I need some of those special node-features.

1.) Resource ist very good for saving. So I thought it would be useful to store all saveable Data in resources. Does that make sense? Saveable Data would be: Personal Stats of the player, the map (a tilemap), stats of cities and NPCs.
An example: when I have a NPC, which has multiple instances of it: let say bears wandering around the map and I want to save the bears and their bear-stats. My first thought would be: use a bear-node which stores the stats and instanciate it for every bear I need. Or would it be more wise to make the bear of a reference-object. And store all those bear-object-instances in an array, placed in a resource. And the node and it’s instances are only for visual representation (they bear no stats :wink: and are not needed to be saved because they can recreated while loading the saved data.

  1. Grouping objects is only possible for nodes. Is there a similar opportunity for other objects? I found it quite handy to cycle through all objects of a group and can think of many purposes for it.

  2. Is it possible to create a resource on runtime? Based on a reference-object? I don’t have any current use for it, I just wondered.

  3. I saw people using „class_name“ on top of their resource-objects. What sense does that make if a resource cannot be serialized?

  4. Autoload should be avoided. But I wondered: As far as I understood it is possible to access any object from any other object via path or similar. So what difference does it make if I can acces it anyways? E.G.: If I can load my resource in any other node it’s quite similar to autoload, isn’t it? But probably I missed a point.

  5. A question about memory: I have a reference-object „TileStats“ that stores all the information of a tile (what landscape, height, population…) and a lot of functions, proceeding those data. And I have lots of instances of TileStats. I wondered if every instance of that object would use memory-space for the functions? Or if the functions would be stored „central“ and called from every instance. In the first place it would be memory saving to out-sorce those functions.

Thank you very much for reading this essay. If you could give me answers to one or two questions I would be very joyfull.`

2

I can give you some answers you are looking for.

  1. yes saving with resources is a common and easy way to do saving

  2. You can create a autoload with a array in which you can add all the resources you want, or you could just use a static variable as a “group”

  3. and 4. Yes its possible to create a resource on runtime and thats what the class_name is for:

class_name MyResource extends Resource

var myvar1
var myvar2

func _init(_myvar1=0, _myvar2="Something") -> void:
    myvar1 = _myvar1
    myvar2 = _myvar2

Now you can create one even with a constructor:

# some other script
var new_resource = MyResource.new(10, "Test")
  1. Autoloads are always loaded, so they wont be freed when changing scenes for example. They are quite handy for stuff like Networking or a Central-GameManager.

Yes you can technically can access any node with a path, but first of all you would have to know the path to the node you are looking for and if theres more than one of a type their names will also be hard to find out. Autoloads are just easier to access

1 Like
3

Thank you very much Herr Spaten, that helps me a lot! May ask further?
2) What do you mean by static variable? A constant? I know the concept of static variables in C++, but as far as I know that’s something different in Godot.

A further question, close to the top ones arose in me: 7) I have functions I need in two or three scripts. So I thought about putting them into a resource and load it a the place I need them. Is that adequate? Because I read that objects in general should manage data not functions. And in the documentation it also says, resource is for data. Other possibility would be an autoload. But I don’t want a ton of autoload-scripts because I want to use the same code only in a few spots. Is it reasonable to use a resource in that manner?

4

static is just like a autoload, but instead of autoloading a whole scene/script you autoload this variable/method.
This may also answer your 7)
Do these methods work independent of script-variables, meaning do they only use variables that are past to them via method-call. If yes you can create static methods which can be called anywhere:

class_name StaticTest extends Node

# example of static-variable
static var counter = 0

static func do_stuff(var1, var2):
    return var1 + var2

### other script ###

func _ready():
    var value = StaticTest.do_stuff(1, StaticTest.counter)
5

for question 1, make a script called global and then in the settings make it auto load. then you will be abl to reference variables and stuff inside it by doing Global.myvar. Im not super knowlagable on save data but im pretty sure you have to make a root to a folder and then save it there. heres a vid about save data and a vid about global vars

6

Thank you again very much! That is a very interesting possibility! Just for later readers I add: static variables are not possible in Godot 3.5 as far as I understood it.

1 Like
7

Ah sorry didnt see this is godot 3 :sweat_smile: