Not my acronym, the engine’s acronym for the systems it already provides for doing Procedural Content Generation. Overview docs here
That was one of the suggestions yes.
Yeah, IDs are tricky. Using index into an array is really only a good idea for things in a single execution. They are brittle to changes made to content or code. Even your example code would easily break if someone inserted a new blueprint path instead of adding to the end. And you end up with a very disorganized list.
But you could use the path, or an ID property on the asset.
Generally asset settings are saved in the uasset file, not into files in Config. You can do that by marking up specific class properties as Config, but it’s not the default behavior.
Great question! There are a few reasons to prefer them in this case.
First is that they are very easy to enumerate (get a complete list of) at runtime. This makes it very easy to write systems that don’t care about the details of the content (like a hardcoded list) and just try to work with the pile of content that it finds. In a team this means that it’s very easy for non-coders to add more content to the game. And as I hope you find out, also makes it easier for you to add more content faster (since you don’t have to restart to test any of it).
Second is that it provides a very easy way to include the content in a packaged or cooked build. The cook starts with a known set of assets, recursively gathers up all their dependencies and cooks them. When you setup a new primary data asset type it’s very easy to configure the type to ‘Always Cook’ and you can not worry about it. There are alternatives to this, you can set up content directories that should “always cook”, but that is open to human error if they put something where it shouldn’t be or you want to reorganize your content layout.
Thirdly, they provide easy ways to load the secondary assets (textures, blueprints, meshes, etc) that the asset references using “asset bundles”. This is functionality that allows you to markup properties as being part of one or more “bundles” so that you can load “all the content needed for UI” without having to write code that loads individual members of the class.
Oh! They also have an existing ID system that you could use instead of trying to manage your own! Not why I would use a PDA, but in your case a boon!
You could do that. You could also do multiples, but not one per asset (something like one for all chairs, one for wall sections, one for traps, etc).
But with what I was proposing the PDA was acting a more than just a reference to the asset but also as metadata about the asset. Things you want to know about the asset without having to actually load it. It could have variant information, so two PDA reference the same blueprint asset but after spawning it you use some info from the PDA like a color or material reference to make the chair blue instead of green.
Or let’s say you want an in-game editor for debugging or to be player facing. The PDA could have a display name and short description to populate the UI and show all the hundreds of choices without having to load any of the blueprints until you actually want to place one.
Yes … you’ll possibly have another asset for every one of the blueprints you make as a PCG element. But I think you underestimate the number of assets each element will likely already involve that adding one more isn’t a big hurdle. It’s not like you’re making them en-masse. You’re making one at the same time you’re making one new blueprint.
Of course there’s also the built-in PCG systems the engine provides that I don’t have any direct experience with. Setting up content to leverage that instead would probably have entirely different set of advice from someone.
Sure it should, if you get the paths right and a few other things. But yeah, I think it’s a waste of time trying to get those things working when you can more easily set up hard or soft reference properties, fill them in in the Editor and either have them be loaded already (hard reference on somthing you load) or calling LoadSynchronous on a soft ptr.