Lost on where to put RPG code/variables

Development Pipeline & Plugins Editor Scripting
, , , , , ,
1

So I’ve looked at a few other posts regarding where to store some stats, but after looking at all the answers I don’t know I know enough to store my variables. This is probably because most answers are fairly general-purpose and I am not sure how to translate it to an RPG type of game.





I am working on an action RPG and want to store different variables like CurrentHealth, MaxHealth, BaseFireDamage, FireDamageModifier, FireResist, TotalXP, PlayerIsDead, EnemyCanSpawn, PlayerName

I have many, many more variables similar to these but i’m wondering where each of the above would go. Player State? Player Character? Game State? Game Instance?



This would be multiplayer, so I want to be able to keep most of these things safe (relatively) from player interference/cheating. What types of variables would you replicate/where would you replicate them? What types of these variables would be made Public?

Also, my players/enemies/NPC characters all share some basic attributes (such as CurrentHealth, MaxHealth, FireResist, CanSpawn, etc). I understand that blueprints can be parented so that I don't have to re-create 50+ variables for every single enemy/NPC in the game. Is it practical to have all my characters share a same parent that contains some common shared variables, or is this going to come back and bite me later on?



And lastly, I am planning of having save-games. I know of the existence of some save slot functions in UE4 but never really got anything working. Thats a whole topic for another post, but the variables that I keep in other places, like PlayerState, do these ALSO need to be stored in a SaveGame (or only in a SaveGame?)

Are things like PlayerState, SaveGame, GameInstance, and GameState things that need to have a blueprint created in my Content, or need to have a Pawn placed in a (or every) level? Or are these transient things that should be created by a blueprint without any sort of persistence (like a blueprint creates a SaveGame, then sets some variables)




Overall I am a bit confused where my variables and blueprint-logic are supposed to go, specifically where to store combat rules (how damage is calculated), where to store my AI (would this be like an enemy’s PlayerState?), and where to store general information, like what is in my player’s inventory or what level they are.



Lots of questions, I know, maybe not all of which belong in one post (I tried to keep them all related to things that have to do with blueprint variables), but i’m hoping there is someone who has a bit of all-around blueprinting experience who has maybe worked with an RPG before who can make everything make sense.

I am still slowly consuming some of these UE4 tutorials on YouTube, and have seen some on networking/savegames/variables/blueprint classes, but I think most of the general-purpose stuff doesnt quite make sense until you work it into something.

2

That’s a lot of questions! I can try and guide you on some of it, some I am unfamiliar with (multiplayer, although many things will be the same) and others you will honestly just have to figure out on your own because it will be highly specific to your game. So for the things I do know…yes you can parent BPs to share features. I probably wouldn’t parent an enemy with the player because they should be different enough and desired in different ways to not warrant that. For example, “get all enemies” may be something you want to do. But I don’t know why you would want “get all enemies and friendlies” likely you will only be doing something to one or the other. For something where it really doesn’t matter like distance to…“get all actors” would serve just as well. So I would recommend 2 “master” BPs one for friendlies one for enemies and make children from that. Variables you want to save all need to go into a save game object at some point otherwise there is no way to remember the data. If your players will control different characters during gameplay but you want certain abilities to be transferable keep those in a player controller as it won’t get destroyed when you switch characters. Things specific to one character can be stored in the character specific BP. Things like player score that may need to be replicated I hear you store those kinds of variables in player state. Game instance holds global variables needed for game play and persists between levels. It is a good place to perform save/load cycles because it is one of the first things to be created when you hit play and the last to go when you quit.

For other basic stuff, or tutorials on save/load, variables, game instance, game mode, interfaces, parenting etc that will be useful to you as you create this RPG game you can check out these beginner tutorials. Might find some answers there too.

As for the other questions, I am sure the community will chime in soon with more help/advice.

3

Hi Nebula,
Thank you for your reply.
I think the reason I wanted to enemies/friendlies to share a parent is because the way I am thinking of doing enemies is in part similar to frendlies. For example, there about 40-50 variables similar to FireResist (if not more) that I will use solely for combat. Both enemies and friendlies need to have these for the combat to work - but I don’t really want to have to add and configure all these variables and the blueprinting of how the combat is handled separately. Some variables may be different values for a friendly vs an enemy (hence the child classes), but 90% the same structure. I was thinking one “BaseCharacter” blueprint with two childen “BaseEnemy” and "BaseFriendly"with those two children having their own children for each individual enemy/friendly.

“Get all enemies and friendlies” isnt necessarily something I would do (and if I needed to I probably could do that with 2 seperate classes as you say), I am considering it purely to reduce some of the overhead of setting up 2 classes that I think are going to have 90% of the same variables. What are your thoughts on that? Is there something I am missing there?


As far as storing the variables in Player Controller, I am not really planning on switching to different characters with the player, but maybe thats something I want to do to leave the option open.



So would GameInstance hold my logic for combat then? (like if a sword is swung and hits the enemy, do xx damage based on enemy defense)


Or is this something I would have a separate Blueprint handle that I would just place in a level. I am not entirely sure how all the mechanics are supposed to be organized (is it usually a blueprint placed into a level seperate from the objects that are involved, or is the logic contained inside the objects?) Like do my enemies have combat logic in their Pawns, or is combat logic a seperate Actor placed in the level (CombatLogic or similar)?

4

I will take a look at some of your videos too

5

If 90% of the variables are the same then yes you could create a master parent class. That would be fine, aside from the variables this class wouldn’t have much else as “enemies” and “friendlies” I doubt share much else in common. But the theory is correct. Anything that is SHARED exactly between enemies and friendlies and you want handled exactly the same regardless of whether or not the event occurs to an enemy or friendly then yes it makes sense to have a master parent and 2 main branches from that one for enemies one for friendlies. Player controller is still probably a better place to put things like “inventory”, “Score” etc unless these things reset with player death. If it is in a player character BP it will be destroyed when the player dies. Game instance I would not use for small things like “dealing damage” during combat. Let the character BPs handle that. Game instance might be where you put your inventory, or you would at least have some functions to save inventory data for example in the game instance so that when you transition between levels the game instance can repopulate a player’s inventory in the next level based on what they had in the prior level. This is the benefit of game instance. Persistence between levels.