[C++] Quest system implementation ideas

[smartyMARTY]

@;634279

Some thoughts of mine about this:

• The idea to make the Quest AActor as base isnt very wise to choose. I assume it is because BeginPlay and Tick which is also not a good idea fmpov. But every quest has many things from actor it will probably never need (like a Transform, InputComponent a.s.o)

• One good thing with an event driven system is that you can have less Tick functions. In his example the tick function is obsolete too.

• instead of BeginPlay i would assume to have custom Start/Update/End functions.

• the next thing is that even Objectives are actors, which he spawns on BeginPlay. Usually you process through a quest from Objective to Objective, there is probably no need to have all of them “Spawned” at the same time. Well it really depends if a quest is considered as a whole or there might be a Quest holding an array of Subquests each with own objectives…

• I would use UObject as a base, so a baseclass with minimal overhead. And maybe the gameinstance to keep quests alive during Level transition. Since he spawns his quests in a world means, as soon as he switches to another level will probably lead to problems.

• in the end the idea is always the same: A quest has conditions and is alive until we succeeded or failed them. But what are conditions exactly? Maybe a condition is “TalkTo_Cthulhu”, when this condition gets activated by the quest, how do you notify your quest system about the update? Well, one way might be to have somekind of callback you register when the player talks to someone and check if its “Cthulhu”. If it is, mark this condition as solved and maybe activate another which was dependent of the previous.

Kind regards

Hey. My Quest implementation (the one I created after this wiki article) follows along similiar to what you have state you would do. I had a UObject base class that was call UMission that was merely a collection of UObjectives (where they were also UObjects, marked with a Within UCLASS specifier to exist within only a UMission, while have type safe access to it’s outer’s interface). From there each UMission had UReward objects to support adding a reward system. Each of my UMission objects implemented BeginPlay, Activate, EndPlay, Deactivate, GetWorld, GetLifetimeReplicatedProps, ReplicateSubobject (to replicate UObjective and UReward Collections and children UMission Objects). From there, I added an entirely evented system as well. I also implemented several UObjectives for common event handling. Such things were Time Trials using the TimerManager and custom Notifications received from various Actors in the Game.

However, from there, to support networking, you would also need to get some kind of interface for the UMission to interact with the world. These interfaces could be something as making it a Subobject of an AActorComponent to make easily plug and play into your game. Another way would be to make it a Subobject of an AActor class (which supports subobject replication without hassle and RPC) such as AGameState (Server Only) or APlayerState (Replicated to all Clients).

Couple things to mention about your argument against using AActor. It is not just for BeginPlay and Tick. It is because of the fact that they support the replication of subobjects out of the box, they support RPC out of the box, AInfo does not have a Transform within the world, it is the whole point of the class, to have an Actor that does not have a position within the world - just information. AActor does not have to have any Components and perhaps the use of components would be an easy way to extend the AQuest object.

However, the most painful part of the whole Quest thing within UE4 is that most system that are for sale fail on multiple accounts due to being data driven. This leads to generic, flat, and uninspired quests. The best quest system would be able to be dynamically created, that is why UObjects are best, AActors should be used for ease of use / prototyping, and custom implementations do not require a lot of overhead. Finally, the hardest part would be implementing a good design UI for your quests.

In a closing note, using AActors would be easier for a beginner, as UObjects require a lot of work and integration if it is to be a multiplayer game. On top of that understanding how instancing and DataAssets work would be more overhead as well. But, there are always a hundred ways to do the same thing when it comes to programming.

Final Remarks: " in the end the idea is always the same: A quest has conditions and is alive until we succeeded or failed them." - I find this the crux that quest systems lack robustness. Would it not be better to implement quests more like a dumb weight based AI system that selects the result of a quest completion test? I find that questing does not have to be/is not binary in nature.