Hello,
Currently I am working on a level for my game and need advice on how to go about adding an objective to it. What I am trying to do is when the player interacts with the tablet the game will spawn more enemys outside the building the player is in. I am assuming I should implement a mission manager for the level that controls objectives enemy waves etc, but dont know how to do this.
I use an actor with a state tree component to manage the game I named Director (the gamestate is also a logical place you might do this). I use delay nodes combined with state tree events in the tree to change level access and the battles/enemy spawns. Works really well and is easy to debug/troubleshoot using the debugger window. Keeps your logic separated into easy to manage and re-useable chunks as State Tree Tasks.
State Tree in Unreal Engine | Unreal Engine 5.7 Documentation | Epic Developer Community.
Hello @Countsie
Thanks for the suggestion. What is the difference between state trees, gamestate, and a mission manager blueprint that checks whether the tablet has been interacted with and if it has spawn more enemies. I have read over the state trees but dont quite understand how they could be used to accomplish this as I am quite new to game development.
in this example i use state tree to manage state of the level progression. the state tree component can be added to any actor, so i use a blank actor derived blueprint named Director and add a state tree component to it. In Director I build only some basic helper functions to gather state of the world (ie, how many enemies are alive), and functions to call events on the statetree component (ie, CallStateTreeEvent(gameplaytag) ). then i build blueprint state tree tasks, like ‘STT_SpawnEnemies’ with params like EnemyClass and numberofenemies and spawnpointname that you can re-use in your state tree when designing your level progression
Then, during game you have state tree events fire like when a player enters or exits a collision volume. Or like your example, interacts with the tablet. I do this using GetActorOfClass(“Director”) → CallStateTreeEvent(GameEvent.Tablet.Interact). In the state tree ‘script’, you listen for those event (GameEvent.Tablet.Interact) in the transition of your current state, and use the event to move to the next state, or a whole new section of your tree, that has tasks for STT_OpenDoor, STT_PlayMusic, STT_WhateverYouWantToDo.
It’s really easy to see the progression of the player in the level as you can run the debugger when playing to watch your transitions.
Having a mission manager blueprint is the same as what I’m talking about, you just have to manually manage your state via booleans, tags or enums rather than having it done in a visual tree and is a PITA to manage and debug if it gets slightly complex… it’s why i’ve adopted this approach.
You could use GameState to do this, just make your own child GameState BP and add a state tree component to it. I’m using my GameState for a different purpose, but it might be worth thinking about. If that’s the case you should really familiarize yourself with it. If not multiplayer, GameState doesnt matter if you dont want it to… it’s a convenience actor for replicating game state to clients. I keep mine trimmed down with no logic in it, just variables. Depends on how you want to design it, really.
State trees take a bit to get ahold of but are totally worth it. Maybe it’s overkill in your situation? depends on what you’re doing. Regardless they are worth learning.
Hi @Ryd3r09 ,
I’m sharing a couple of videos where they build a quest system that could serve as a useful reference for what you’re trying to implement.
The first one is from a series that shows the full game development process, including how they design and structure missions.
The second one focuses more on the technical side and demonstrates how to manage this type of system using Data Tables and Gameplay Tags
In my opinion, I’d recommend considering the use of Data Tables together with Gameplay Tags, especially if you’re planning to add more objectives or similar events later on. The idea is to avoid hard-setting everything in one place and instead define mission behavior through data that you can easily tweak.
To use a Data Table, you first need to create a Struct. That’s where you define what kind of information each objective will have, such as how many waves there are, what types of enemies spawn, where they appear, how often they spawn, and which event triggers it. With that structure in place, you can then build a table with different configurations for different situations.
So when the player interacts with the tablet, it’s not directly handling enemy spawns. Instead, it fires an event using a tag, and the system looks up in the Data Table what should happen in that case and runs the waves based on those values. This keeps everything much more organized and flexible.
The nice part about working this way is that any balance changes , more enemies, fewer waves, different types, or timing adjustments , can be made by editing data instead of reworking logic.
Hope it helps!