Hey everyone! I haven’t seen much about it and I know there are several people who would like to learn it, so I made a new Wiki entry about creating a Quest/Objective Framework in C++ for UE4.
Here is the link to the wiki (so you can mess it all up :P)
Here is a link to the original content
If there is enough traction, I can continue on with a second part that shows how to design the current code to use nested sub-quests and nested sub-objectives.
Quick question; as-is, the code doesn’t compile out of the box because Quest’s declaration tries to call some method GetCompletion() in Objective. Did you possibly mean to call GetProgress() there?
Yes I did. Thank you for that. I am sure that happened after I re factored it for the tutorial.
It is fixed now
Any reason why you inherited from AInfo
Standards. I originally had it inherited from AActor. However, AInfo is a more appropriate class to inherit from in this case.
[Quoted from the Remarks section of the API]
(AInfo | Unreal Engine 5.2 Documentation)
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.
I would have chosen UObject too, I don’t see any reason to pay the overhead of an actor.
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.
I personally would have chosen an UObject and implemented the GetWorld() method to get a valid UWorld.
Yo, that was more a general information 
sorry. I tend to always give out some extra information for people reading this.
Hey, ya - information is always good. I figured using something simple would be good for a beginner tutorial. Thank you for the input
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 was thinking of making UObjective blueprintable so you can implement the logic with blueprints. But for that to work the blueprint needs a way of getting UWorld;
something like:
return OwningQuest->GetWorld();
or
return Outer->GetWorld(); //this only works if outer implements GetWorld()
In the end it is completly irrelevant if you are using Actos for everything. It’s probably even better if you like to network your quest system
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.