Best "under the hood" setup for a party-based rpg

Development Programming & Scripting
1

So as not to confuse things I’m not going to go into details on my settings/rules etc, but will instead reference DnD to utilise common terminology.

Short description: turn based combat; customisable party; Closest reference I can think of is Infinity Engine games like BG and Icewind Dale. Click the character portrait, control that character, the AI controls the other five. So, given that, how would you structure your Character blueprints? My thinking is:

BP_PCMaster
(extends Pawn)
Everyting that is common to all player characters goes in here. Rules on movement, basic melee, how health works etc etc If it’s common to all characters, it goes in here.

BP_PCclassname
(extends BP_PCMaster)
Everything that is specific to a aprticular class goes in here. Things like rules on what spells/feats are avaialable to them, armour restrictions etc etc

BP_PCcharname
(extends BP_PCclassname)
Finally, stuff specific to individual characters like stats, character mesh, armour, weapons, location vector (for saving) etc etc.

Am I overthinking or complicating this? Will this create problems if I end up using the engine’s built in Ability system (which, after a few cursory looks, I think I probably should)? Am I not going far enough? By adding another extension above class, such as race or species, I could have a programmatic ruleset for the entire game - including all enemies/bad guys - in place and consistent. This seems to make a ton of sense to me, so the question is, what obvious problems am I not seeing? Will this hamper pawn switching, or setting up an AI Controller?

I guess the better way to word it would be, what are the obvious drawbacks to this setup?

2

Consider looking into actor components to up the modularity of what you’re building. Your master will, inevitably, become a super busy class. Being able to encapsulate data and methods in a component that can be added to (or removed from) any actor can work pretty well.

You’re probably quite familiar with the movement component. Now think health component, inventory component, race component, special (or mundane) ability component, spell casting component, buffs / debuffs, temporary or permanent status effects… you name it.

It can be either an alternative or a supplement to GAS which can be a bit over the top at times.

1 Like
3

That’s pfg. :+1:

Looks a much more manageable and simpler-to-use system than abilities…

4

@Everynone, mate looking into this more over the past couple of days and I’m now convinced you’ve absolutely nailed it. Your post has potentially saved me a lot of work. Cheers.

1 Like
5

Since you’re at it, do note that you can override a static mesh component (or skeletal, or widget) like this. Now you have a static mesh component that not only has a mesh but also a full graph, its own variables, functions and comms.

• you could make a robot boss where every body part has internal logic that needs dealing with first
• a modular spaceship where every component module is self-contained, already shows up as a mesh but also runs script, can be detached / destroyed
• advanced loot containers with skeletal animations, these can be added to any actor. A chest of drawers actor with X individual component drawers? Sure, one of them requires a D10 dex/patience check to open. Otherwise it gets stuck and can be only destroyed.

I am musing :innocent: but components support inheritance so this can really get you far.

Good luck!

1 Like