PackedSceneRandomizer and ResourceRandomizer

[pixel-boy]

In godot, the AudioStreamRandomizer resource is very useful because it allows you to:

• Create an easily reusable sound list
• Assign different weights to each sound
• Be assigned to an AudioStream property (which also accepts single sounds)
• Has different selection modes (random / avoid_repeat / sequential)
• AudioStreamRandomizer can contain other AudioStreamRandomizer elements (which I've never used for sounds but which might make sense given what I'm describing below)
• Randomize parameters (pitch/volume) which would maybe make less sense for what follows

PackedSceneRandomizer & ResourceRandomizer

This concept is practical and makes particular sense for audio, but I'd like to discuss here the idea of ​​replicating this concept for other types of elements, starting with PackedScene and Resource.

Just to give you some examples where I'd like something similar:

• Enemy wave system (lists of enemies of different levels, types, etc.)
• Loot (different items, stored in different lists) that could be used by chests, enemies, etc.
• Level list (being able to choose randomly from existing levels, or sequentially)
• And many other use cases that I won't mention here

Loot example

Using the loot example, I would have chest.tscn with a property:

@export var loot:PackedScene

And I could choose to assign it a PackedScene or a PackedSceneRandomizer.

I could have multiple loot list resources which would each contain different scenes:

- loot_common.tres 
	- sword_wood.tscn
	- shield_wood.tscn
- loot_rare.tres
	- sword_iron.tscn
	- shield_iron.tscn
- loot_legendary.tres
	- sword_gold.tscn
	- shield_gold.tscn

But also lists that contain multiple lists with different weights:

- all_loot.tres
	- loot_common.tres (weight: 10)
	- loot_rare.tres (weight: 5)
	- loot_legendary.tres (weight: 1)

Same thing could probably be applied to the Resource with a ResourceRandomizer.

Technically all of this is already doable with custom resources, but in practice nothing is as ideal as something like AudioStreamRandomizer, As with the AudioStreamRandomizer, the idea is to offer a practical and quick-to-implement tool that meets a number of use cases while not replacing more complex custom solutions for rarer cases.

I can imagine that the idea is technically more complicated in the case of scenes and resources compared to sounds or that it poses certain problems but in any case I would like to confront the idea here and see if there is a world where it could exist, because it would be very useful to me.

[AThousandShips]

This is trivial to do with a few lines of code, and I don't think there's a strong demand for this as a simple, built-in feature with limited configurability, much better to be done in a way that's the way you want it done and not being bound by how the engine decides it should be done

If nothing else this belongs in an add-on not in core

I do this myself in my own projects, as simple as:

@export var asteroid_scenes : Array[PackedScene]
...
var asteroid : RigidBody2D = (asteroid_scenes.pick_random() as PackedScene).instantiate()

If you want a weighted result just use RandomNumberGenerator.rand_weighted

[pixel-boy]

Sorry if I was annoying on some parts, it was important to me to clarify them and I wouldn't want you to think that your opinion isn't welcome, thanks for your time and feedback, I found them valuable and would be happy to hear them again.

The main point I wanted to highlight (and it probably clearer to me after all this discussion) is that the solutions I can implement via GDScript are too uncomfortable to use in the cases I encounter.
I'm aware that all the features would be more practical if they were native, and that it's not possible for Godot to meet all needs natively.

I'll try to list the generic situations that this feature could address and, as you suggested, I'm going to explore the add-on option, which is probably the logical path before considering it natively.

If other people come across this, I'm still curious about the general opinion on the subject and always open to effective workarounds.

[Zireael07]

Why are your GDScript solutions "too uncomfortable"? All projects of mine use rng/randomized scenes/resources and I don't find it uncomfy, not at all

[pixel-boy]

I described my problem quite poorly, and the solution I proposed was one idea among others, I should probably open a new discussion, but in the meantime a less clumsy way of expressing it:

• Ready to use tools to access and editing game content and lists easily, for people who are less familiar with Godot (but also for comfort) particularly in the case of games based on many elements (characters, items, enemies, upgrades, skills, maps etc...)

This is a case I encounter when my projects get bigger and there start to be a lot of game contents to manage, so maybe not a widespread case, but as I said above I was curious to hear the general opinion on this point.

I'll review the two tools I'm considering and would be happy to hear everyone's feedback / ideas / workarounds.

1 - Inspector-based approach

TDLR A better way to make lists, pleasant to edit, and with some ready-to-use features for middle cases.

This is more or less the proposition described above, the comparison with AudioStreamRandomizer has somewhat distracted from the main topic, currently reusable lists with at least one parameter (number 3 in the image) is difficult to manage comfortably, related to the readability of nested resources and arrays, which is a topic that has already been addressed by others.

Typed dictionaries are an interesting new option, but still quite impractical to edit as is.

Mockup

I started to see what I could do with an addon, the solution is limited to a single parameter but it already addresses some of the needs I encounter:

• Reusability
• Weight parameter for each entry
• Easy to read / edit
  

Even if it may seem overkill, the idea of ​​​​a List class crossed my mind (in the same way we have Nodes and Resources for example ) a kind of "To each problem, its own solution" for data lists.

Rather than the current state, which is always a choice between exported array, dictionary and custom resources, he could manage more efficiently:

• Be able to save and reuse them
• Memory management / options for not preloading all resources
• Ability to contain several types
• An interface designed for this type of data

Current solutions are honestly fine in many contexts, but also often full of compromises. I don't really have a hard time imagining a more suitable solution, although this is obviously a huge and complex topic.

2 - Main screen / sheet database

TDLR Having a kind of CastleBD integrated directly into godot (or as official addons)

The idea is to have a main screen in the form of a sheet that would allow to:

• Create kind of global typed list and sub list (scene / custom resource / source file) which can also indirectly be linked to this discussion that I had opened Tag system for files / directories #10562)

• Edit a lot of content with sheet editor with quick access to export variables, some add-ons and proposal already do more or less this:

  • https://godotengine.org/asset-library/asset/2986
  • https://godotengine.org/asset-library/asset/1479
  • https://godotengine.org/asset-library/asset/3864
  • Add a Spreadsheet resource for handling tabular data #13

This 2 tools could work together, the lists saved as resources, assignable to export variables and accessible in the global main screen sheet.

I think there may be a demand for this, I can imagine that it would solve certain workflow problems in Godot, but again It's based on my own needs and opinions, I am curious to hear everyone's feedback, and while waiting to have a general consensus, the add-ons option suits me well, if I achieve useful results I would share it with pleasure.

[Zireael07]

Tbh you can achieve both/either with a node that exports a list (array or dictionary) of resources or scenes. Drag and drop to said list to add stuff.

Note I did all of that before typed dictionaries.

Better UI for more complex cases would be great though.

[pixel-boy]

I've been experimenting with the Node-based approach quite recently, and generally I find that nodes are good for quite a few problems, in the case of lists I found it interesting, I would not say that it has solved all my problems (forced to open a scene to access the inspector, still not very confortable for custom resource lists, heavier than an exported resource) but it's a good candidate that I would probably use in combination with the plugins I develop.

For simplicity, comfort and efficiency, which are the main arguments of my proposal, I feel like we could have better in Godot, at least it doesn't cost much to consider it.

Thanks for suggesting the idea anyway, it's great to have an overview of current possibilities.