I figured that since it was a class with some management code, metadata, and had no purpose having collision or movement without getting into game implementation, it was appropriate. In fact, if I remember, there may be a section in the Wiki explaining why I chose AInfo.
Yeah, good question. Why don’t you inherit from UObjects? Is there a need for the questions and objectives to be spawned in the world?
Otherwise, for just plain data, you could/should use UObject children.
Also, if it’s really plain data that doesn’t change or needs to be unique per instance, you could have a look at “UDataAsset”.
It’s similar to, for example, texture, where you reference them and then you can use the data you saved.
I use that for recipes in a crafting system for example.
I agree, pure data would justify using UDataAsset, or even a FTableRowBase parent. However, mentioned in the tutorial, this offers the option in the framework to add quest specific game play code that effects the level. This would be similar to something like AGameMode.
Can you explain that a little more? I am a bit confused as to what you are referencing in regards to that. Are you saying you would have overridden the GetWorld() method? Because in the API docs, UObject does not define GetWorld(). It is defined in AActor.
I’ve had a lot of success doing something similiar with UDataAsset. I originally tried to accomplish this with structs, since it felt silly to bring something from UObject in just to store a couple of logical rules (e.g. “resolve to finished if you’ve killed n monsters”), but I simply couldn’t find a way to make this logic work without overridable functions and casting. Can you guys think of any reason not to do it that way? I keep worrying that I’ve somehow created a behemoth that will quietly eat all of my memory, then rear out of the water when I’ve written the rest of the system and require me to refactor everything.