Working on a quest system. Actor or an ActorComponent? What are your thoughts on it?

Hi guys! I am not looking for any ‘hard answers’ because I know that this is a very nebulous question. For this reason, I posted here instead of in the answer hub as well.

First, to give some context. I originally created an Actor component and attached it to a character. This wasn’t problematic, and I was able to create a basic quest. However, it seemed kind of clunky. In order to attach the quest, an actor needs to be on the field. Therefore, I need to drag/drop the actor, or spawn it. I was looking into an Actor Component instead, and it appears to be more light-weight, and in some ways also fits the bill of being attachable to an actor, and moved at will. However, Actor Components seem to have their own problems as well. You cannot create a Blueprint child of the actor, and that is what I have been doing; create the base class, then configure it in Blueprint. For this reason, I am leaning more towards an Actor class instead.

So my question is, is there a Best (or at least better) way of setting up a quest component? What do you use for quest items?

Thanks for your time, guys!

In my opinion a quest has nothing to do with the character actor itself, so i don’t see why they need to be actor components.

I’d say it fits more the gamestate, since a quest and its quest status has more to do with the state of the game instead of a character.
I’d make quests as UObjects or actors that you can create and manage in your gamestate (give it a “quests” array of “quest” Uobjects/actors). Your quest objects/actors can then place actors/actor components in the world (like trigger zones, etc).

As an example how it could work when accepting a quest:
When talking to an npc to get a quest, the NPC then (server-side) gets the gamestate, creates a quest and that quest then manages itself with whatever is neccessary for the quest (spawns monsters, checks whether player is in an area, spawns triggerbox components, etc) and tells the player “you got a new quest” with a reference to the gamestate quest entry to the quest object so you can look up quest descriptions, etc.

^ yeah, object in GameState or GameMode seems more appropriate place for a quest system…

In Final Fantasy 10, for example, everything is an Array of variables in the “main character” entity.

There’s no “object” holding any quest, item or achievement… That one big array of primitive variables is then later saved or loaded to the memory card, so the whole game progress is a very tiny KBs file. The whole game.

In Unreal I’ve seen people do weird things that results on over 15MB~100MB of save data which I honestly think is an absurd even for today’s standards.

Hm, that’s interesting. For our internal project I’ve had the entire game progress be just a FGameplayTagContainer with a bunch of gameplay tags that mark game progress. I imagine this is as skinny as it gets without sacrificing too much convenience. As for inventory, we do a similar thing where just a FPrimaryAssetId is paired with an integer count in a struct.

Hmm. That gives me a lot to think about.

So at first, I was really just over-complicating things and adding a ton of variables to the quest system. I attached my item actors in an array, and the characters we needed to talk to. I managed to simplify it down to all primitives.

Now that you mention it, a UObject is probably exactly what I am looking for; it is general enough and simple enough that it shouldn’t be too top-heavy, and I can still manipulate it like I want it.

I honestly hadn’t thought of a game state, now that you mention it. There are probably several objects inside of my character that I could move.

Having to rewrite the code is somewhat tedious, but I’ve been able to optimize and simplify quite a bit. I think I am going to simplify it a bit more for my final…err… next… iteration.

Actually UObjects are the exact opposite of what you want. Any state should be a value type, no a pointer type. Structs and primitive variables only.