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!
Thank you for your suggestion. Right now Iām experimenting with State Trees to handle mission flow (ex: Interact with Tablet ā Escape), it works well so far with sequencing the tasks. What Iām trying to figure out is the best way of doing the missions, especially since I want a main mission select level that shows the missions for each level (ex. Mission 1: Retrieve the Tablet).
For example, in my first mission:
The primary objective is retrieve the tablet
If the player kills enemies before grabbing it, extra enemies spawn near the original entry point (since thatās also the escape route)
If no enemies are killed, the player can sneak out without more enemies being spawned.
So Iām wondering what the best approach is based on your advice of Data tables and tags aswell as potentially state trees depending on how they both work with progression.
What Im currently thinking now with your advice of data tables is
Using State Trees for the mission flow and conditions (tablet interacted, escape started, alerted state, etc.)
Data Tables + Gameplay Tags for defining mission-specific data like objectives, enemy waves, spawn rules, and reactions to certain events
That way, each level could reference its own mission data, while the logic stays reusable and clean. The State Tree would react to high-level events (like a Gameplay Tag fired when an enemy dies or the tablet is picked up), and the actual behavior would be driven by data instead of hard-coded logic.
Does that sound like the best way of achieving this or would there be a better way?
I think on the right track, for sure. Using data tables is a great idea for keeping your stuff centralized. My spawn functions i use simple params and have to adjust all by hand, but having that in a data table would make it easier to tweak overall settings. Just start simple, get it working solid, and build up from there.
I think of gameplay tags as global boolean, enum or flags you can access/use nearly anywhere. I use them a LOT, not just for events, but descriptors ie for weapontype (Weapon.Type.Cannon), state management (Weather.Storm.Heavy), whatever really. They are also really fast and flexible for search and comparison operations.
I think youāre on a really good track as well. If you run into any questions during implementation, feel free to use the forum,someone there will surely be able to help you with whatever you need.
Happy developing!