I am using a 32 bit integer to store 'class' designations, and I need 9 more ideas to fill up the total of 32 bits. Here is what I have defined so far. Can anyone help me figure out 9 more classes to fill up these options? enum ClassValue { Commoner = 0, CommonKnight = 0x00000001, // stronger than commoner, not as strong as normal class Fighter = 0x00000002, WeaponMaster = 0x00000004, Archer = 0x00000008, Ranger = 0x00000010, Paladin = 0x00000020, AntiPaladin = 0x00000040, Monk = 0x00000080, Cleric = 0x00000100, Priest = 0x00000200, // difference between a priest and a cleric. Cleric has more combat, Priest more magic DarkPriest = 0x00000400, WhiteMage = 0x00000800, BlackMage = 0x00001000, RedMage = 0x00002000, BlueMage = 0x00004000, Thief = 0x00008000, Bard = 0x00010000, Assassin = 0x0002000, BeastMaster = 0x0004000, Ninja = 0x0008000, // Help Me Fill In these Samurai = 0x00100000, Unused0 = 0x00200000, Unused1 = 0x00400000, Unused2 = 0x00800000, Unused3 = 0x01000000, Unused4 = 0x02000000, Unused5 = 0x04000000, Unused6 = 0x08000000, Unused7 = 0x10000000, Unused8 = 0x20000000, // Help Me Fill In Above DarkMaster = 0x40000000, // Dark Master has the all the abilities of anti-paladin, black mage, and thief LightMaster = 0x80000000 // Light Master has all the abilities of paladin, white mage, and weapon master };

Just wondering why so many classes? If you want an open game with lots of choices why not go with a open class system where the player selects what they want to specialize in. Then you could have a 32 bit 'attribute' designator.

I agree, I dislike it when games throw a long list of diverse (yet overlapping) classes at you.

I prefer that it be either:

1) simple, with a few set classes (eg WoW). Easier for the player to get into, easier for the developer to balance. But lacking in customization.

2) open ended, without set classes (eg ultima online). Players choose their role depending on what skills they take. Allows the user to pick the precise role they want, but also a headache for the developer to balance.

To me it looks like you're trying to do both: create a ton of classes to cover every possibility. In my opinion that'll turn off a lot of players.

Regardless, you could add to your list Necromancer, Druid, Enchanter, Illusionist, and various crafter classes.

Fletcher. Haberdasher. Plumber. Periwinkle mage.

If you used a more data-driven approach, you could have an infinite variety of classes defined in a configuration file of some sort. With a bit more work, you could be able to combine them together, like a ninja-assassin-poet or something [grin].

Actually... The BIT flags are for GENERAL... The customization comes with the fact you will be able to have up to 4 classes. You have to attain certain levels in your prior classes before obtaining another.

DarkMaster and LightMaster are classes that can be chosen as a START AFTER being unlocked when certain conditions are met.

I am planning this out so this will work. I created a StatAdjustment type, that stores signed values that represent all a 'creatures' stats, (NPC will be derived from creature, and PC derived from NPC)... Racial/Class/Gender/Effect adjustments will be applied as a modifier to adjust the values within StatAdjustment (relative, just flat modifier there) and then by calling this function will modify correct values.

I posted the below code just as an example that I am planning for that. And also recognize the amount of statistical values. Total customization of a class/race is already out of the question due to complexity issues. (I could, however... With as many rules as the game system will have, it does not make sense to allow total customization of classes. To be able to edit their progression on their other hand, (required due to different abilities and spells that will be able to be created) is another story.

void StatAdjustments::Adjust(const VitalStats & inVital,const CoreStats & inCore,
const WeaponProfStats & inProfs,const CraftSkillStats & inCraft,
VitalStats & outVital,CoreStats & outCore,WeaponProfStats & outProfs,
CraftSkillStats & outCraft) const
{
UInt32 * pDest = 0;
const UInt32 * pSource = 0;
const Int32 * pAdjustments = 0;
UInt32 dwTemp = 0;
SizeT x;

// Vital Stats First

pDest = &outVital.MaxHP
pSource = &inVital.MaxHP
pAdjustments = &MaxHPMod

for (x = 0; x < 8; ++x)
{
if (pAdjustments[x] != 0)
{
if (pAdjustments[x] > 0)
{
dwTemp = static_cast<UInt32>(pAdjustments[x]);
pDest[x] = pSource[x] + dwTemp;
}
else
{
dwTemp = static_cast<UInt32>(-pAdjustments[x]);

if (dwTemp > pSource[x])
{
pDest[x] = 0;
}
else
{
pDest[x] = pSource[x] - dwTemp;
}
}
}
else
{
pDest[x] = pSource[x];
}
}

// Core Stats Next

pDest = &outCore.Strength
pSource = &inCore.Strength
pAdjustments = &StrengthMod

for (x = 0; x < 19; ++x)
{
if (pAdjustments[x] != 0)
{
if (pAdjustments[x] > 0)
{
dwTemp = static_cast<UInt32>(pAdjustments[x]);
pDest[x] = pSource[x] + dwTemp;
}
else
{
dwTemp = static_cast<UInt32>(-pAdjustments[x]);

if (dwTemp > pSource[x])
{
pDest[x] = 0;
}
else
{
pDest[x] = pSource[x] - dwTemp;
}
}
}
else
{
pDest[x] = pSource[x];
}
}

// Weapon Profs Next

pDest = &outProfs.HandToHand
pSource = &inProfs.HandToHand
pAdjustments = &HandToHandMod

for (x = 0; x < 21; ++x)
{
if (pAdjustments[x] != 0)
{
if (pAdjustments[x] > 0)
{
dwTemp = static_cast<UInt32>(pAdjustments[x]);
pDest[x] = pSource[x] + dwTemp;
}
else
{
dwTemp = static_cast<UInt32>(-pAdjustments[x]);

if (dwTemp > pSource[x])
{
pDest[x] = 0;
}
else
{
pDest[x] = pSource[x] - dwTemp;
}
}
}
else
{
pDest[x] = pSource[x];
}
}

// Last, Craft Skills

pDest = &outCraft.Weaponsmith
pSource = &inCraft.Weaponsmith
pAdjustments = &WeaponsmithMod

for (x = 0; x < 9; ++x)
{
if (pAdjustments[x] != 0)
{
if (pAdjustments[x] > 0)
{
dwTemp = static_cast<UInt32>(pAdjustments[x]);
pDest[x] = pSource[x] + dwTemp;
}
else
{
dwTemp = static_cast<UInt32>(-pAdjustments[x]);

if (dwTemp > pSource[x])
{
pDest[x] = 0;
}
else
{
pDest[x] = pSource[x] - dwTemp;
}
}
}
else
{
pDest[x] = pSource[x];
}
}
}

I don't know, I have to agree with everyone else: your approach just doesn't make any sense to me. The idea of haaving so many static classes, even if a character can only have four at once, seems very dated to me. I also feel a character should be defined by its skills and personality, not its title. Oblivion walked a line here by allowing you to choose from a list of default classes, each of which had a prefab array of skills. The crux was that the class name itself meant nothing; it was just a word that showed up on one of the character screens. A character in the actual game world was never addressed by his/her class, and guild membership was based on skills, not class.

I sort of see your desire to have classes because titles mean something to you, but I think they inhibit diversity. I believe the majority of gamers will want to customize their characters to their liking, to create a sense of personalization and investment, which makes the game much more fun. But if you're stuck with this class approach, do you really need to fill the entire dword? Why not reserve some space for the future, when you come up with more ideas? Keyword: expansion. It increases your game's longevity.

Then I do not believe that you get what I am saying.

Let me describe something to you. You are partially right about a 'title'. This is the generics in terms of what the class is designed to be and a general rule set when customizing that particular class. (It's NOT TOTAL CUSTOMIZATION)

I do not think that you know that Guild Trials is a game development system. (I.E. like RPG Maker, or Neverwinter Nights... It will be a 2D game system, with a 3D one planned for much later on)

The 'classes' are locked, they will have their GENERAL requirements, and for the game developed, they will be able to have the text displayed CHANGED. That is what I do not believe that you are getting.

Quote:

Original post by GuildBuilder I am planning this out so this will work.

You're dead wrong there. :)

I can tell you from experience that just planning things out is no guarantee for something to work. Theory and reality are still different beasts. Besides, it may work technically, but gameplay-wise... Let me give you some advice: playtest, playtest, playtest. If players will only use a few main classes, then the rest has been a waste of time and resources for you. If they drop the game because it's too confusing, then all of it has been a waste. And if you're writing a generic system, then hardcoding classes is not the way to go. Look into data-driven development for that.


Besides, why store these classes as bit-patterns? Surely there's a more flexible and robust way.

You cannot do custom things if it isn't data driven!

Apparently you are not reading and taking in what I say... Or you are, and you are not using common sense!

Defined MAXIMUM 32 classes. 32 bits in a bitmask can be used as USABILITY FLAGS in items, spells, etc...

The bit is just set in a CREATURE/NPC/CHARACTER's data structure. There are ClassID and CurrentClassID members, with 2 CStaticArray<UInt32,32> (homebrew) objects that denote experience and level.

I am too planning this out.