Hey, for future reference, you’d probably get a better response for this question in the visual blueprint scripting forum.
To the question…
If you have a large number of variables that always go together (eg. character statistics), you can create a structure (New > Blueprint > Structure), this can then be defined in your blueprints like any other variable type, accessing its elements via the make/break nodes. It also helps keep your code clean and variables relating to the same object or functionality together, and means you can pass the whole structure to other blueprints in one go if necessary.
If you want to create a list of possible classes for characters, you could create an enumeration (New > Blueprints > Enumeration), once defined this can be declared like any other variable type. An enumeration pretty much boils down to a list of options that you define giving each option a name (but behind the scenes they just equate to being numbered options 0,1,2,3,etc, and can be converted back to ints if you need to). You can then use these enumerations to run different branches of code using the enumeration as input to a switch node or an = node connected to a branch.
For the last question about a list of booleans where only one is ever true again I’d suggest using an enum (or as ClockworkOrange said use an integer). If any combination of values could be true I’d suggest using a struct.
================
p.s. (note: replacing the word “Class: Knight… etc” with “character type” to avoid confusion):
Options for implementing your character classes (types):
Option 1: Define a parent character class containing all generic character functionality (movement, character stats, etc) then use this as a parent for child classes for each of your individual character types that contains character type specific functionality (casting, combat skills, etc).
Option 2: Simply define a single character class that contains the functionality that all characters might have, then simply give that class a character type enum so you know what character type it is, and therefore what skills and functionality it has access to.
Option 3: Define a character class that contains all of the details you need to define your character (character type, skills, etc), then define a separate blueprint(s) that contain all functionality required for calculating and performing character actions).
Personally I would go with Options 2 or 3. Option 1 will probably require a lot of type casting in your code when trying to call or access a characters data, although it will mean the parent class will be cleaner as character type functionality is pulled out into individual child classes. Option 2 will mean your character class will be bigger containing a lot more data and functionality (which can be tidied into functions and data structures). Option 3 will make your character class smaller but will require a lot more data transfer when passing data between the character and action calculation blueprints.