Setting up PlayerController/Character/State best practice(?)

Hey Folks :).

I got a few questions on the above mentioned BPs. I think I do know some basics about the intended usage of the BPs. I have read some of the threads of how to use them and some things could be handled in different ways (Like setting the Movement in Character or Controller).

What I want to know are some best practices of the “intended” usage.

Lets say it is a game with a SP and MP Part, with different SP content like a Tutorial and normal SP-Mode; the “Main” GameMode is a persistent Multiplayer.

My sample Setup:
GameMode, GameState, PlayerController, PlayerCharacter BP and PlayerState are for/from Multiplayer. The Idea is to setup the controls, HUD, … only once. Thats why I thought of making the BPs for the SP and Tut as childs of the original MP ones.
Furthermore I thought about the following:

  • PlayerCharacter: Input Key Actions like Jump or Rotating; Generating Input for the Controller
  • PlayerController: Movement “logic” with an energy drain system (Functions Basing on Values of PlayerState)
  • PlayerState: e.g.: Storing the energy/HP values and maybe things like Inventory/EXP/Currencies
  • Or: CalculatingBPInstance: to provide the functions for calculating displayed values

It is not about being an MMO with a unique Hero-Character. The Character is kind of generic and the same for every player, not like a individual Hero like in a MMORPG. The Inventory storage is just optional (for me to understand the context).
As the Character is generic and always identical, it seems logical to me, to hook HP/Energy to the PlayerCharacter BP. But If I want to add some RPG-Mechanics i think it should be added to PlayerState to handle sth. like playerlevel-based Modifiers.
It is NOT an issue that a player could posses a Character with different base stats as they are all the same. (To prevent issues with saved HP values)

**What I want to do: **

  • Supply a consistent movement system for every character in every game mode as I want to have different Character BPs
  • The Character as a simple hull without a deeper connection to a player
  • Saving XP/Progress and the possibility to save logout location, HP, Inventory in a persistent world. These values should be saved in a Database (or locally for SP) and are loaded back into the game if the connected Player Account/Profile continues playing
  • Applying the same “rules” and general conditions (e.g. “Persistant” SP with the stored values). Calculating (Movement, Damage, Energy, …) on the server to prevent (?) cheating.
  • As AI does not have a PlayerState, Energy/HP/Inventory are calculated/stored in the AI-Character BP.

Questions:

  • Is this the way “its meant to be”? My question is not about how to set up this stuff, but just where to put it and how to organize if I want to do it clean and understandable.

  • If I use childs, which blueprint-parts are used? Just the Events, when called “from parent”? Whats about the “Input Key Action” do I need to call or add them too? E.g. for altering the HP (normal to immortal in Tutorial) or unlock Input Key Actions (like a jump) after specific events/quests.

  • Do I adapt from AI usage? HP/Energy/Inventory as part of the owned character and just store things like Level/EXP in PlayerState? What about logging out “injured” or prevent modifying(cheating) values/calculations?

I do hope you understand my questions :D.

Thank you in advance,

Laexxi

It’s really up to you how you want to build your game. UE4 has this flexibility in mind far more than UDK/UE3 did.

That being said, the built-in Gameplay Framework is a good guideline for best practices if you want to make the most of the engine features that are provided for you.
Reading up on the official documentation for that will help a lot in making decisions like whether to store a variable in the Game State, Game Mode, Player State, or Player Controller, for example.

Anything that would be a best practice using another dev kit or engine, will probably be the best practice in Unreal Engine too, most of the time. Some special cases may exist with regard to physics, networking, etc. but for the most part, good design principles are good design principles regardless of the engine.

Your question covers a lot of topics. For best results, I recommend breaking it down into several topics so people who answer can focus in on specifics without getting lost among all the other answers that pertain to other features in the engine.If you’re lucky though, you might get an answer from someone who has the time, amounting to a small book of several pages which covers sufficiently all the sub-questions in your post. It’s been known to happen once in a while :slight_smile: