I was looking at some of the practice projects I recently finished tutorials for and was wondering why some blueprints were built in different event graphs.
I’ve used Unreal Sensei’s FPS tutorial on a target shooting game, and Smart Poly’s tutorial on blueprints.
Is there a better reason to use one over the other? I’m mostly concerned when I would be better off using one over the other.
For example, in Unreal Sensei’s tutorial the game’s win/lose conditions via hitting targets/running out of time were built in the gamemode; in Smart Poly’s, the HP system was built into the character.
When I utilized the game over screen I learned from Unreal Sensei with Smart Poly’s HP system, I felt like I should have built it in the gamemode event graph.
Since I had already made it in the character BP, I couldn’t bring it over without getting a bunch of errors.
Does anyone have any thoughts?
edit: I also tried using Smart Poly’s HP system made for a 3rd person game in Unreal Sensei’s tutorial game for FPS, but couldn’t get it to work so I’m wondering if that has to do with the gamemode/character blueprints just having different requirements overall. I thought you could do a bunch of stuff in the same way, but I haven’t gotten it translate over correctly.
Above its how much I build in Character BP from Smart Poly’s tutorial with some extra stuff I looked up that manages play hp, death/ragdoll and game over screen, knocked out/ragdoll, invulnerability frame, damage types
Here is Unreal Sensei’s target gamemode blueprint that only really deals with hitting x/x amount of targets in an allotted time. I couldn’t get the HP system to work in the characterBP or gamemodeBP.
Are you making a single player game? If so, then it’s pretty much free-for-all but common sense should apply, ofc.
the game’s win/lose conditions via hitting targets/running out of time were built in the gamemode
Sounds about right, this does not really belong in a Pawn. But if your game is super-duper basic, it could. You could get away without overriding any of the framework classes. The engine provides default ones out of the box. You extend them if you need them to do extra stuff.
if you need a controllable pawn, make a pawn (if you’re making a pure puzzle game, you may not need one, for example)
if you need a human form with arms, legs → make a character and keep character related stuff there, tracking HP and a widget that shows it is more than fine
if you need a dedicated Game Mode for every of the 15 levels of the game because the rules change dramatically, having 15 Game Modes may as well be what you need
if you keep swapping characters around or they keep dying, perhaps more controls should be in the player controller so it’s easier to maintain
if you’re dealing with multiplayer, you’ll need to look closely at Game State and Player State, what replicates and what does not
Entry points for reading:
I couldn’t get the HP system to work in the characterBP or gamemodeBP.
If there’s anything specific that gives you a headache, consider a new thread. Blueprint comms take a while to wrap one’s head around. How to efficiently move data around is half the battle (and what feels like half the questions ever asked around here).
Thank you for the succinct input! It does make sense, especially after reading your examples. I didn’t really consider having multiple game modes either, so getting that clarified that it is an option helps.
I’ll revisit the HP system to see if I can translate it from the 3rd person tutorial to the FPS practice project after I get a bit more hands on.
I’ve already posted a few questions and I’ll no doubt ask more later hahaha. I’m fairly new to this kind of stuff.
I haven’t seen either Poly’s HP system nor unreal sensei’s game mode, but regardless when you design a system/program there are some desirable traits that makes your life a whole lot easier when your system gets bigger.
One of these important traits is coupling. In simple terms this means how reliant are parts of your system on each other. Generally less reliant (loose coupling) is preferred because you can change one part without needing to redesign/fix the whole thing. Also if one part of your system fails for whatever reason you don’t end up with a cascading failure of your whole system.
Generally speaking HP system is not really that related to game mode. Sure you may lose if your hp reaches 0, but this can be done using communication between different parts of system. You don’t need to integrate the whole HP subsystem into your game mode. You can implement it as a very loosly coupled different system which is a better choice in most cases.
Another important aspect is extensiblity/reusability. Let’s say you end up adding some kind of enemy with their own HP which might work identical to the existing HP or might differ slightly. In either case if it is an actor component you just attatch it to the enemy and now they have a fully functioning HP system as well(reuse) . If it works differently compared to the existing hp system, you just inherit the existing one and override whatever functionality you need(extension) . You can’t do this if the HP system is part of game mode. If it is part of player blueprint you can inherit the whole player BP but this will also inherit every other functionality of player which you might not need/want for your enemy BP.
These stuff might not matter that much in a very small scale project but definitely will come in handy as your project grows.
That’s good to keep in mind. Seems better just to leave the hp system attached to the actors then.
In my current setup for the third person project, the lose condition and inventory systems are also attached to character instead of game mode.
Since those systems can possibly be used in other game modes, it’s better to keep them attached to the character so that I don’t have to rebuild them in each game mode?
Right now I’m just trying to wrap my head around when and where to put blueprints together. I think it’s making more sense though.
Maybe I’m just getting confused because I’m thinking about general stuff when I need to make me specific scenarios
I still need to read into that link someone else posted hahaha
Game Rules, Spawning players, switching in/out of vehicles are typically coded in the Game Mode.
Player health, stamina, inventory are typically coded in the Player State. You can do an Actor Component and add it to the Player State.
Damage code depends on what’s causing the damage. Projectiles/Arrows, grenades etc can have the “dmg calc code”. But you generally call an event on the Authoritative proxy that passes that dmg to Apply Damage event. Then its controller → player state → deduct and set health. All of which is completely server-side.
