Hi Michael,
Just a note, the characters for the code formatting are ``` as opposed to … 
am i on the right track
Lets take a look. So we said above about having a class that was for the character, and potentially any character, as such I would probably rename it so, as at the moment it is specifically relating to the player.
It may not even need to inherit from MonoBehaviour, depending what we do with it later, but we will leave that in for now.
public class Character : MonoBehaviour
We also said about needing to be able to store the base values as well as any modified(current) values, so that at any point in the game we can refer back to what the player had when they started, despite any modifiers which may be in effect.
I would have approached that by having two sets of variables. Also, because the Character class is about storing data, it doesn’t need references to the Text UI GameObjects, think of this as more of a holder of the data;
public int baseStrength;
public int baseDexterity;
public int baseConsititution;
public int baseIntelligence;
public int baseWisdom;
public int baseCharisma;
public int strength;
public int dexterity;
public int consititution;
public int intelligence;
public int wisdom;
public int charisma;
I would typically create all of my member variables as private variables also, until we know which/when/why they need to be public, but again, for now, for simplicity, we will leave them as public, but add a note to remind us later.
With regards to race and class (of character), these wre our enums from the CharacterCreator class, because we didn’t specify a different underlying type, they will have defaulted to int, zero-based, so if you look back at the earlier posts,
private enum CharacterClass { Barbarian, Bard, Cleric, Druid, Fighter, Monk, Paladin, Ranger, Rogue, Sorcerer, Warlock, Wizard };
These would have the following int values;
- Barbarian = 0
- Bard = 1
- Cleric = 2
- Druid = 3
- …
As such, we could just store these as an int in our Character class but for now we will use the distinct types which we created when we defined our enums. Later on, these could potentially evolve in complexity in such a way that we want/need to create specific classes for each type.
public Race race;
public CharacterClass characterClass
Note I have used characterClass rather than just class as the variable name. There are a lot of keywords/restricted words in C# which you either can’t or just shouldn’t use as it can lead to confusion. I would prefer to not have the word character as a prefix, as this is the name of our class, another option would have been type but that is also a reserved word. This is where looking at your game rules may come in handy, as there may be an alternative word which describes class which we could use. Another good source is often thesaurus.com - for now, I’ll leave the prefix.
So at the moment, I’d probably have something resembling this;
using UnityEngine;
public class Character : MonoBehaviour
{
// TODO: reconsider access modifiers
public CharacterClass characterClass;
public Race race;
// base attribute values
public int baseStrength;
public int baseDexterity;
public int baseConsititution;
public int baseIntelligence;
public int baseWisdom;
public int baseCharisma;
// TODO: is baseHealthPoints needed?
// TODO: consider dropping the suffix "points"
public int baseHealthPoints;
// current / modified atttribute values
public int strength;
public int dexterity;
public int consititution;
public int intelligence;
public int wisdom;
public int charisma;
// TODO: Consider dropping the suffix "points"
public int healthPoints;
}
I spotted that you had snuck in the health points also 
so I popped that in too, but I don’t know what your maxHealthPoints means, is this effectively another base value which is calculated when the character is created? If so, we’d want to add another base variable for it too. I’m not overly keen on the points suffix, and would probably opt for just health and baseHealth (if appropriate), only because, all of the other attribute value are also points really, and it’s good to be consistent in our code - I really wouldn’t want to add that prefix to all of the variables, and I believe that because we have a type of int for these attributes, points is effectively inferred.
One final thing we will need to change, with regards to those enums, at the moment they are locked away inside our CharacterCreator class, and our Character class will have errors about accessibility for our two variables which reference them;
using UnityEngine;
public class CharacterCreator : MonoBehaviour {
private enum CharacterClass { Barbarian, Bard, Cleric, Druid, Fighter, Monk, Paladin, Ranger, Rogue, Sorcerer, Warlock, Wizard };
private enum CharacterRace { Dwarf = 0, Elf, Gnome, Half_Elf, Half_Orc, Halfling, Human };
// ...
}
I would move those up so that they were outside of the CharacterCreator class definition, and make them public, thus when they are used, you do not need to precede them with CharacterCreator each time, although later, as we find more things like this, we may want to consider giving them their own namespace.
I would also drop the prefix Player from PlayerRace and replace it with Character, our class is now generic enough to be used by perhaps an NPC character.
using UnityEngine;
public enum CharacterClass { Barbarian, Bard, Cleric, Druid, Fighter, Monk, Paladin, Ranger, Rogue, Sorcerer, Warlock, Wizard };
public enum CharacterRace { Dwarf = 0, Elf, Gnome, Half_Elf, Half_Orc, Halfling, Human };
public class CharacterCreator : MonoBehaviour
{
// ...
}
Note, on the enums we have prefixed them with the word Character, as enums are often shared across the entire project, at the moment it makes sense to do this. For example, if we wanted to introduce an enum for the class of Sword (Rare, Legendary perhaps), the enum name Class would have already been used, but we could do this;
public enum CharacterClass { ... };
public enum WeaponClass { ... };
These are now very distinctive.
I know you are working through the RPG course, so I don’t want to stress you out with posts here and the course materials to work through also, but for reference, the next steps I would be considering with the above would be;
- make a decision/investigate ref TODOs about health
- consider constructors / properties / member variable setting
- make the connections between the scene, the dice rolling and the attribute storing
- modifiers
As mentioned before, my laptop appears to be fairly dead at the moment, I’ve managed to use SafeMode to create this post, but will be replacing drives and reinstalling Windows, I’m also away for a couple of days so my responses, certainly of this length, may not be quite as frequent.
A screenshot of your features breakdown would be good to see, not sure what you are using in the way of tools for the project planning.
