I’m having trouble coming up with a practical way to create linear quest/story progression using Blueprints.
TL;DR = How should I update quest progress using blueprints and interactable instances in a scene?
(1) At first I was going to create a variable named “StoryProgress” in my game-state class and update it with a custom event and switch statement. Then, I realized that I couldn’t reference scene instances (as far as I know - please educate me) anywhere but Level Blueprint.
(2) So then, I decided to store and update quest progress in Level Blueprint. However, I will have many instances in my scene not based from the same class. So it’s not practical to create an event dispatcher for each actor and bind them all to Level Blueprint.
(3) Another option is to have every interactable actor cast to the player character and call the event dispatcher (intended for Level Blueprint) from there… but that seems a bit messy especially since the player is already using BP Interfaces to talk to those actors.
(4) My last option is to create child actors of all the objects that will update the quest and instance them directly from Level Blueprint or any actor blueprint.
Phew!
I know there’s always many ways to do something but is there a professional standard that I should be using in my situation? Also, I’m using version 4.12.
Your advice is much appreciated. Thank you in advance.
Do not create hardcoded quests. Instead go for code + data model.
Doing hardcoded quests you will be forced to code same functionality for each quest. There will be ton of redundant code.
Instead do set of functions and condition checks for quest (something like quest engine).
Then drive it from database or some text file etc. That part may require some C++.
First you should write down types of quests you want, then think about progression checks for those quests.
Quest engine is big piece of code, doing it without any preparation and design documents will be quite big waste of time.
So make design document for it, split everything into small tasks, then see what functionality is common start coding from such basic functions.
In time you get more ideas about how to proceed further.
Well, I don’t know why it took me so long to find it but here’s how to reference scene instances in an actor blueprint…
I agree with everything above and I’ll take it as a compliment that you think I’m ready to tackle a project that way but I think you overestimate my current ability. I’m just getting my feet wet in UE4. Although I do have some previous traditional programming experience I don’t think I’m ready for C++ and data handling. Also, my project has just a single, linear quest that shouldn’t take much more than an hour or two.
Go here > Do this > Grab Item > Push Button etc.
As opposed to functions that take in XP, branching story paths and other parameters.
UE4 is advertised as being able to make games completely through blueprint and I’m still curious to the best pipeline for quest handling, even if one were to have multiple quests in a project.
Ahh for such simple project, start with bottom-up approach.
So you need some master blueprint that collects all quest data and has quest progression logic.
For it create blueprint actor, with some icon (or some mesh) something that is visible only in editor (And hidden in game).
Place that blueprint actor in level, this will be your logic for current quest. This way when you want next quest you place next actor like that with just different logic.
Do not put all that stuff into player controller or character, it will mess up (complicate) code there.
For starters I would do very simple prototype. For eg player can press red or green button. Or pick one of few choices. This is for time you build all communication to and from quest brain blueprint.
Because communication between blueprints is key in this project.
So in brain make event that accepts message from other blueprints.
Also make dispatcher in brain that sends out processed results. This should be some variable that tells quest stage to slave blueprints.
Now you need to make slave blueprint, that for eg displays hud with choice for player when character is inside trigger box.
Each slave blueprint should have its unique ID,
Then it should hook to brain dispatcher (find all actors of class, you get only 1 actor, then get its reference, cast to and hook dispatcher)
Also it should have function that triggers message event in brain.
That is blueprint setup.
For quest logic you should make macros that can dispatch execution to different exec outputs depending on quest state. Something like branch node is , but crafted for your quest logic. It is hard to tell how I would do it without actually doing that code, so you need to think about what custom nodes you want, how to process quest logic etc.
There is also great “engine” that you could use, it is called “behavior trees” they probably can be adopted to quest processing, they are made for AI, but with some tricks you could use them for quests. But that requires good knowledge about AI and behavior trees, and it is quite probably that you end fighting hardcoded functionality for unreal, so maybe not worth time. For it you should do fake and empty ai pawn, create tasks for behavior tree that communicate back to brain blueprint. It may be bit too advanced for you now.
Hello,
I have 2 Tutorials (Part 1, Part 1.5) on this as well as a UE4 Wiki article that can help you get started. Most of it is pretty basic and talking to the Quest objects is relatively simple. You can also bind to Quest events. I am currently using it in my game. I would offer up the Plugin I am working on as well but I have not tested any of it yet. Despite the comments, it does not have to be data-driven in the sense of external data files (which can be a mess when referencing classes, properties, etc.), everything can be configured inline with the use of the UCLASS AObjective if you make it instanced. Also, I added a QuestComponent to my main character and used that to keep track of the current Quest and Progress.
