Class limit should be a per-module setting -- perhaps along with the total level limit, if they want to consider unhardcoding that as well, but that's a semi-separate discussion. In this way all the OC's and old modules will work the same, servers can increase it from 3 if they want, and singleplayers can have a setting to change the class limit when starting new modules or loading new saves.
NPC's could just not have any class limit at all, so builders / scripters can design them as they please.
Semi-related, unhardcoding the level cap as well would probably make quite a few people happy as well. BD shouldn't have to worry about changing the 2das for post-40 progression, custom content creators can be left to implement that.
(Don't want to see BD spending time designing and testing post-40 progression, but I do want to see levelling beyond 40 possible where those servers/modules want to invest the time and energy for it themselves, alongside more than 3 classes, additional types of spellbooks and feats to facilitate for example fun-to-play psionics, etc.)
So the 4th class is all about powergaming and mechanical optimization. Nothing wrong with that but it shouldn't be the focus of a D&D game.
Whether it is or not the focus should be decided by the player (in the OC campaign) or by whoever plays DM (in a multiplayers setting), it should not be something hardcoded.
I don't disagree with that. But I still think adding a 4th class should be on the rock bottom of the priority list. Dev time is better spent on anything else as we can't have everything we want.
I seriously think we should not argument with difficulty to make / dev time.
Trello is there so they don't need to check 500+ pages of suggestions but choose the top voted/requested ones. From these they choose what they do themselves as it fits them or maybe not at all.
The limit should be optional, either by the player in singleplayer or by the server in multiplayer.
I would love to have more than 3 classes, but why stop at 4? pnp don't have such a limit unless your DM is no fun iirc Icewind Dale 2 and Temple of Elemental Evil had no limit.
The limit should be optional, either by the player in singleplayer or by the server in multiplayer.
I would love to have more than 3 classes, but why stop at 4? pnp don't have such a limit unless your DM is no fun iirc Icewind Dale 2 and Temple of Elemental Evil had no limit.
Limit of number of classes *is* optional already - it is very easy to limit current 3 classes to 2 or 1 if one want to do so - and it can also be seamless (ie. no ugly delevel workarounds).
The limit should be optional, either by the player in singleplayer or by the server in multiplayer.
I would love to have more than 3 classes, but why stop at 4? pnp don't have such a limit unless your DM is no fun iirc Icewind Dale 2 and Temple of Elemental Evil had no limit.
Limit of number of classes *is* optional already - it is very easy to limit current 3 classes to 2 or 1 if one want to do so - and it can also be seamless (ie. no ugly delevel workarounds).
The limit should be optional, either by the player in singleplayer or by the server in multiplayer.
I would love to have more than 3 classes, but why stop at 4? pnp don't have such a limit unless your DM is no fun iirc Icewind Dale 2 and Temple of Elemental Evil had no limit.
Limit of number of classes *is* optional already - it is very easy to limit current 3 classes to 2 or 1 if one want to do so - and it can also be seamless (ie. no ugly delevel workarounds).
but can't go higher.
right - im not against 4 classes, just against any "option-ability" because we already have the options to change the limit down
I'm personally never not going to give the thumbs-up to anything that allows the player character to (potentially) expand their experiences, and explore more of what the game has to offer, without sacrificing the care and time put into every single concept they make.
Let the Fighter/Weaponmaster/Bard/RDDs come as long as the door is also opened to more unique mixes -- like Wizard/Cleric/Fighter/Shadowdancers. Custom classes expand these possibilities; and, of course, the existence of a fourth class slot expands what the builder-end can do as well -- and should not be underestimated as a "complete waste of Beandog's time", especially when it means that your Great Wyrm may proper have as many Arcane levels and Divine levels as it does levels in its NPC class; all while not sacrificing the ability to potentially have a few levels of either a full BAB class (to maximize its chance to hit) or Monk (to increase APR) to up its CR.
I'm open to this simply because of the potential it invites on the user-end and the developer end. Viewed this way, as elaborate as it may seem; it wouldn't be a "revision", it would -- in fact -- be an enhancement.
While I love the idea of additional classes, I'd have to vote against it being added to NWN, because:
1) Its a breaking change. It was pointed out elsewhere that many modules (all that use the PRC for example) look at class slots 1 thru 3 to do character math. For example, if Rogue where in the 4th slot, it would require new custom module code for any sneak attack stacking/progression with other classes in other slots; if a prestige class that advance casting were in use, in the 4th slot it just would not advance casting without new custom module code, etc.
2) I'd prefer the devs focus on other content first.
It wont break anything as a module option that can be set. If you set your module for 4 classes or 5 classes but only check for 3 that's no different than allowing 3 classes and only checking the first 2.
While I love the idea of additional classes, I'd have to vote against it being added to NWN, because:
1) Its a breaking change. It was pointed out elsewhere that many modules (all that use the PRC for example) look at class slots 1 thru 3 to do character math. For example, if Rogue where in the 4th slot, it would require new custom module code for any sneak attack stacking/progression with other classes in other slots; if a prestige class that advance casting were in use, in the 4th slot it just would not advance casting without new custom module code, etc.
2) I'd prefer the devs focus on other content first.
I agree with everyone who says "why stop at 4?". Make this some sort of configurable option (via ini for single player and some other option for custom modules) with a default of 3 (to not break scripts of the pattern "while (current_class_no <= 3){ current_class_no ++; ... }"), with 0 being "as many as you want".
Speaking as a programmer, having some arbitrary number as a limit for anything just seems inelegant and, worst of all, hacky. There's only two distinctions that matter here in my experience; is this one thing or many things (and if it's one thing it's usually wrong).
Having said that, I'd imagine if NWN is written in C or C++ (judging by NWNScript's syntax I'm guessing it is) it would make a bunch of code more complicated as you'd suddenly have to store things in the heap and pass pointers around instead of just grabbing things off the stack. Not to mention suddenly having to deal with bounds checking where before you could just use the pattern above or pass the classes between functions as seperate parameters.
I can also imagine that "maximum number of classes is a static number" is a deep seated assumption that's rife throughout the whole code base. I can also imagine that it's also an assumption that will cause everything to burst into a towering inferno if that ceases to be the case.
Disclaimers to above opinions:
I've never written a game before. Most of my programming work falls into the "skins around databases" category.
I generally use programming languages which manage their own memory (usually via Garbage Collection or Reference Counting).
I generally have to write code that priorities not falling over when another programmer looks at it (or an adjacent piece of code) funny over being efficient.
I find managing your own memory safely via malloc/free (C) or new/delete/RAII (C++) to be an utterly terrifying experience. This alone should give you carte blanche to just ignore everything I say if NWN is written in C/C++.
I agree with everyone who says "why stop at 4?". Make this some sort of configurable option (via ini for single player and some other option for custom modules) with a default of 3 (to not break scripts of the pattern "while (current_class_no <= 3){ current_class_no ++; ... }"), with 0 being "as many as you want".
Speaking as a programmer, having some arbitrary number as a limit for anything just seems inelegant and, worst of all, hacky. There's only two distinctions that matter here in my experience; is this one thing or many things (and if it's one thing it's usually wrong).
The ammount of work to make this feature work for 5+ classes is double of what would it take to make it work for 4 classes. Making the limit optional will only make it harder to code too.
4 classes are enough. It is significant improvement over default 3 classes already. And the more classes you will enable the more opposers arise. We already have ppls against 4 classes for some reason.
The ammount of work to make this feature work for 5+ classes is double of what would it take to make it work for 4 classes. Making the limit optional will only make it harder to code too.
I'm curious as to why you think this.
Given that Beamdog have said on their streams multiple times that they intend to clean up any code that they touch (refactor in programming parlance), I can't imagine why they wouldn't just generalise everything and completely remove any assumption as to the number of character classes a character has. It makes everything simpler and less likely to break.
While this may be taken as me invoking a straw man arguement, the way I currently model the code working in my head would be something like this:
//C++ like pseudocode for a function definition
void some_function_involving_characters(CharacterClass class1, CharacterClass class2, CharacterClass class 3, ...)
{
//Have a bunch of code that's copy and pasted 3 times to work with class1,class2 and class3
}
...or something like this:
void some_function_involving_characters(Character char)
{
int i = 1;
CharacterClass char_class;
while (i <= 3){
char_class = char.getCharacterClass(i);
//do stuff with char_class
i++;
}
}
I speculate it looks like this not because Bioware are terrible programmers, but because NWN was proceeded by the Infinity Engine, which was DnD 2E. In IE characters generally only had 1 "class" (but classes could be things like Wizard/Cleric/Fighter for Multiclassing). Dual Classing was also a thing for Humans, but given how complicated it is I'd imagine it has a ton of special case code for it.
As I stated before, Beamdog have said on streams that they're going to tidy up the heck out of the NWN code (refactor). Part of refactoring code involves making each function responsible for 1 job (usually breaking them up into multiple smaller functions to do so) and removing assumptions about how the rest of the code behaves. You could rewrite the above examples as something like:
// C++ pseudocode
void do_something_with_char_class(CharacterClass char_class)
{
//do something
}
void some_function_involving_characters(Character char)
{
//map is a programming concept where you "map" a list of values onto a function
map(do_something_with_char_class, char.getCharacterClasses());
}
In this example, there's two functions, each doing one thing (one to iterate over the classes and one to do whatever it is that needs doing to the class) and they make no assumptions about number of classes; it works the same for 2 classes and 200. It's also easier to read because there's no "noise" for iterating over the number of classes and no copy and pasting.
4 classes are enough. It is significant improvement over default 3 classes already. And the more classes you will enable the more opposers arise. We already have ppls against 4 classes for some reason.
Beamdog have been very keen on the point of removing hard coding. Maximum number of classes is hard coding. They should remove it and make it up to the module builders.
Obviously the max classes for player characters is directly tied to the maximum level available for the module/server. This is just logical.
There is always a maximum, of course for creatures and NPC's this limit is not so easily defined, but I can't really imagine that you need to allow infinite classes for an NPC or creature, especially considering that feats and skills can be assigned manually, which makes the need for infinite classes almost irrelevant.
In this example, there's two functions, each doing one thing (one to iterate over the classes and one to do whatever it is that needs doing to the class) and they make no assumptions about number of classes; it works the same for 2 classes and 200. It's also easier to read because there's no "noise" for iterating over the number of classes and no copy and pasting.
There is more to this than some function to retrieve character level.
For example the classes have to be stored inside character bic file and for monsters in *.utc blueprint.
Toolset would have to be changed to allow unimited multiclass for npcs.
Nwscript functions would have to be rewritten completely.
Adding 1 more class to use would be much easier. Enabling unlimited of them would require completely redo the already existing code (current code is written similarly to your second example) and even toolset GUI. And also completely rework network code as server is sending client update for all 3 classes.
I also would like the cap of max classes a character could have to be raised. One reason for such a request is that there exists a prestige class called the Fochlucan Lyrist, which requires that the character take levels in Bard, Druid, and Rogue before entering the prestige class (which means that a Fochlucan Lyrist requires a minimum of 4 class slots).
While I would like to see a minimum of 4 class slots, I would really prefer to see no hard limit. If someone wants to play a character whose gimmick is to take a single level in a different class each time they level up, I want that to be possible.
There is more to this than some function to retrieve character level.
It was meant to be a simple illustration of a pattern that I imagine is throughout the code base. If Beamdog updates it to 4, they still have to touch all these places that follow this pattern. Then they have to test them, which is where the time sink is.
I'd argue they should just remove the notion of there being a finite number of classes altogether - the fewer assumptions your code makes, the easier it is to change it. Old, hairy code bases (Legacy Code) tend to break in unexpected ways because there's assumptions spread throughout them.
Also, I'd argue that just upping the number of classes is itself a huge potential source of bugs. I'd imagine it would be easier because you're thinking that Beamdog could just copy and paste some code and change some 3s to 4s. There's two huge risk factors that come with this - the first is missing some places (so everything falls to bits because some bits expect 3 and others expect 4) and the other is, when updating code in the future, you update a piece of code but forget/miss the second copy and pasted variant.
Given that there's risk involved anyway, why not just do it "properly"? That way you'll only have to retest them once and not have to worry so much about them breaking when you change things in the future.
For example the classes have to be stored inside character bic file and for monsters in *.utc blueprint.
Toolset would have to be changed to allow unimited multiclass for npcs.
You make a good point here, I hadn't considered these at all. I can't say I have any specialist knowledge in these regards or know anything about them. I know from the streams that the toolset is really scary to work with on Beamdog's end.
I still don't think it changes much - the key problem is the same - Beamdog has to find all the places that have the assumption of 3 classes and change them to 4 classes and then test them. Changing the code to work with any particular number (or infinite/practically infinte) is the easy bit.
In terms of implementing them, I just can't see why there couldn't be a preceding byte in each of these structures to say how many classes there are and have whatever is reading them act accordingly. Doing it this way puts the maximum number of classes at 256. Yes, it's finite, but it's not arbitrary - it's defined because that is the smallest value a modern CPU can read in one instruction. At risk of repeating Bill Gate's infamous "640k of RAM ought to be enough for everybody" quote, I really think that should be more than enough for everybody.
Nwscript functions would have to be rewritten completely.
Adding 1 more class to use would be much easier. Enabling unlimited of them would require completely redo the already existing code (current code is written similarly to your second example) and even toolset GUI. And also completely rework network code as server is sending client update for all 3 classes.
That's why it should be opt in. NWscript functions will still have to be updated no matter if it's 4 or 400. Either way Beamdog should just add a function to NWscript to get an array of all classes (and probably number of classes for a character) that can be iterated through.
I'd argue they should just remove the notion of there being a finite number of classes altogether - the fewer assumptions your code makes, the easier it is to change it. Old, hairy code bases (Legacy Code) tend to break in unexpected ways because there's assumptions spread throughout them.
I will argue. If you allow unlimited number of classes to be taken, you have to test it all. You don't know when the character sheet GUI breaks completely if at 9 or 50 so you will have to make 256times more tests than what would be needed with 4 classes.
Anyway to sum it up, the name of this thread is "The Add the ability to have a fourth class card discussion". I am all for forth class. I don't think more than 4 are needed. But if BeamDog finds out they can do more and it will be easier then ok do it. I don't think thats the case though.
I will argue. If you allow unlimited number of classes to be taken, you have to test it all. You don't know when the character sheet GUI breaks completely if at 9 or 50 so you will have to make 256times more tests than what would be needed with 4 classes.
Then I shall retort, good sir! Your arguement here is hyperbole. You wouldn't need to test all possible permutations. You'd only need to test 1 (lowest value) 255 (highest value) and one or two random values between them to be confident nothing is broken.
Heck, Beamdog probably don't even need to do any testing from a GUI perspective beyond 1-3 classes as they can just push the work of making a GUI for it onto mod makers (this is assuming that they do the GUI modernisation/customisation they talked about).
My whole point is why should it be artificially limited to 4? Really it should be limited by technical/business limitations, not by picking arbitrary numbers like 4. Further restrictions should be entirely up to module authors/persistent world admins.
Anyway to sum it up, the name of this thread is "The Add the ability to have a fourth class card discussion". I am all for forth class. I don't think more than 4 are needed. But if BeamDog finds out they can do more and it will be easier then ok do it. I don't think thats the case though.
Then we will have to agree to disagree on this, I'm afraid. Neither of us have access to the source code as far as I'm aware so we can't really say either way whose opinion is correct. I certainly think changing the number of classes will be a lot of work - I just don't think it's that much more work to go from 4 to 256.
However, on the subject of not needing more than 4, I can see a lot of attractive things from number of classes not being a scarce resource anymore. For starters, Creature Hit Dice from race aren't quite as crippling now. You can also really easily make a Level Adjustment system without unfairly penalising people (give LA races levels in a "Level Adjustment" class that grants no skills, no hitpoints and no BAB).
Not to mention templates with LA are suddenly really easy to implement! You just give players levels in a template class that grants no BAB no LA and no skills but DOES offer class features. Such approaches are extremely unattractive when you've got a very low number of classes available.
--EDIT--
TLDR; think less about Classes/Class Levels and more about Hit Dice/Challenge Rating.
What the heck!? I edited my comment for a grammar fail and then it was deleted! I spent ages writing that!
Right, executive summary time then. Apologies if these come across as rude, I'm writing for brevity.
256 tests needed is hyperbole; you only need to test the cases of 1 class (lowest), 256 classes (highest) and some tests for a few values in between. Also, if Beamdog go through with their GUI update they can just test 1-3 and make it mod authors responsibility.
I think adding 4 classes is a lot of work. I don't think that adding 256 classes is actually much more work than adding 4. We can't say if either of our opinions are correct so we'll have to agree to disagree, Shadooow.
Not having a shortage of classes has following advantages:
Racial Hit Dice suck less. You're already paying for them with dead levels with no class features and further penalising people by letting them have 1 fewer class makes them even more unattractive.
Level Adjustment can be implemented by just giving LA races levels in a "Level Adjustment" class that gives no BAB or Skill points and a d0 for hitpoints. Downsides are that you still get +CON hitpoints for the level up and still get progress towards acquiring feats, but its neat and simple.
Templates can be implemented in the same way and not suck (same drawbacks though). PRC's Lich template class, for example, is really neat but giving up a class slot for it is too painful.
and useless ... the card trello to "have a 4 class" and was stored in the icebox ... I think it will be reconsidered in the near future ... and it goes well
There would only be the need for 40 at the most. That is the number of levels that the game supports. And are we going to give the monsters the same amount of classes? I would like my Owlbear Ninja Pirate Demon (outsider) Kitten.
I should clarify my thinking. I don't think there should actually be 256 classes. Like you say, having more classes than class levels makes no sense. I picked that number because it is convenient for computers to work with and is more than anyone would ever actually need.
No matter what you do, in all the .bics, network code etc. there would be at least a byte used (8 binary digits, 0-255, 256 possible values) to declare how many classes an object has. Given that's the case, why not just say there's a limit of 256? It's easier than having some arbitrary number.
Also, while I missed the boat with NWN first time round and never got into persistant worlds, for some reason I'm under the impression that some of them allow levels above 40; either by some weird scripting work around or some NWX feature or something.
Also, while I missed the boat with NWN first time round and never got into persistant worlds, for some reason I'm under the impression that some of them allow levels above 40; either by some weird scripting work around or some NWX feature or something.
While this is true, the official game does not support levels that high. Only 40 levels max. So there would be no reason to allow more than 40 classes, 1 per level. This is silly because you do not rise in power like you would in 5e, this is 3e. You would literally be a first level character with a lot of hps. You could not be a prestige class either because you would not meet the requirements.
I think 4 classes is good, that would be 10 levels in each class. Maybe 8 at the most.
With this being placed in the ice box I believe even more discussion is needed. If it this is deemed desired enough by the player base I believe Beamdog will respect our desires.
There is a lot of work being done on the game's code and yes adding in refactoring the code to allow more classes will not be easy, it being placed on a todo list would world be great. One way I can personally seeing this done (which would not break backwards compatibility) is a toggle. Make a Boolean with the three class code and if it is false the players can choose the new code and use a new system which supports four or more classes.
I'd argue they should just remove the notion of there being a finite number of classes altogether - the fewer assumptions your code makes, the easier it is to change it. Old, hairy code bases (Legacy Code) tend to break in unexpected ways because there's assumptions spread throughout them.
I will argue. If you allow unlimited number of classes to be taken, you have to test it all. You don't know when the character sheet GUI breaks completely if at 9 or 50 so you will have to make 256times more tests than what would be needed with 4 classes.
Anyway to sum it up, the name of this thread is "The Add the ability to have a fourth class card discussion". I am all for forth class. I don't think more than 4 are needed. But if BeamDog finds out they can do more and it will be easier then ok do it. I don't think thats the case though.
Level adjustment shouldn't have anything to do with classes. In D&D 3rd edition and 3.5 the experience needed for your next level is current ECL * 1000, total experience for next level is (1 + ECL) * ECL * 500. It's simple arithmetic so you don't need to give class levels to find the value. Racial HD on the other hand are essentially weak class levels.
Comments
NPC's could just not have any class limit at all, so builders / scripters can design them as they please.
Semi-related, unhardcoding the level cap as well would probably make quite a few people happy as well. BD shouldn't have to worry about changing the 2das for post-40 progression, custom content creators can be left to implement that.
(Don't want to see BD spending time designing and testing post-40 progression, but I do want to see levelling beyond 40 possible where those servers/modules want to invest the time and energy for it themselves, alongside more than 3 classes, additional types of spellbooks and feats to facilitate for example fun-to-play psionics, etc.)
Trello is there so they don't need to check 500+ pages of suggestions but choose the top voted/requested ones. From these they choose what they do themselves as it fits them or maybe not at all.
I would love to have more than 3 classes, but why stop at 4? pnp don't have such a limit unless your DM is no fun
iirc Icewind Dale 2 and Temple of Elemental Evil had no limit.
Let the Fighter/Weaponmaster/Bard/RDDs come as long as the door is also opened to more unique mixes -- like Wizard/Cleric/Fighter/Shadowdancers. Custom classes expand these possibilities; and, of course, the existence of a fourth class slot expands what the builder-end can do as well -- and should not be underestimated as a "complete waste of Beandog's time", especially when it means that your Great Wyrm may proper have as many Arcane levels and Divine levels as it does levels in its NPC class; all while not sacrificing the ability to potentially have a few levels of either a full BAB class (to maximize its chance to hit) or Monk (to increase APR) to up its CR.
I'm open to this simply because of the potential it invites on the user-end and the developer end. Viewed this way, as elaborate as it may seem; it wouldn't be a "revision", it would -- in fact -- be an enhancement.
1) Its a breaking change. It was pointed out elsewhere that many modules (all that use the PRC for example) look at class slots 1 thru 3 to do character math. For example, if Rogue where in the 4th slot, it would require new custom module code for any sneak attack stacking/progression with other classes in other slots; if a prestige class that advance casting were in use, in the 4th slot it just would not advance casting without new custom module code, etc.
2) I'd prefer the devs focus on other content first.
Speaking as a programmer, having some arbitrary number as a limit for anything just seems inelegant and, worst of all, hacky. There's only two distinctions that matter here in my experience; is this one thing or many things (and if it's one thing it's usually wrong).
Having said that, I'd imagine if NWN is written in C or C++ (judging by NWNScript's syntax I'm guessing it is) it would make a bunch of code more complicated as you'd suddenly have to store things in the heap and pass pointers around instead of just grabbing things off the stack. Not to mention suddenly having to deal with bounds checking where before you could just use the pattern above or pass the classes between functions as seperate parameters.
I can also imagine that "maximum number of classes is a static number" is a deep seated assumption that's rife throughout the whole code base. I can also imagine that it's also an assumption that will cause everything to burst into a towering inferno if that ceases to be the case.
Disclaimers to above opinions:
4 classes are enough. It is significant improvement over default 3 classes already. And the more classes you will enable the more opposers arise. We already have ppls against 4 classes for some reason.
Given that Beamdog have said on their streams multiple times that they intend to clean up any code that they touch (refactor in programming parlance), I can't imagine why they wouldn't just generalise everything and completely remove any assumption as to the number of character classes a character has. It makes everything simpler and less likely to break.
While this may be taken as me invoking a straw man arguement, the way I currently model the code working in my head would be something like this:
//C++ like pseudocode for a function definition void some_function_involving_characters(CharacterClass class1, CharacterClass class2, CharacterClass class 3, ...) { //Have a bunch of code that's copy and pasted 3 times to work with class1,class2 and class3 }...or something like this:
void some_function_involving_characters(Character char) { int i = 1; CharacterClass char_class; while (i <= 3){ char_class = char.getCharacterClass(i); //do stuff with char_class i++; } }I speculate it looks like this not because Bioware are terrible programmers, but because NWN was proceeded by the Infinity Engine, which was DnD 2E. In IE characters generally only had 1 "class" (but classes could be things like Wizard/Cleric/Fighter for Multiclassing). Dual Classing was also a thing for Humans, but given how complicated it is I'd imagine it has a ton of special case code for it.
As I stated before, Beamdog have said on streams that they're going to tidy up the heck out of the NWN code (refactor). Part of refactoring code involves making each function responsible for 1 job (usually breaking them up into multiple smaller functions to do so) and removing assumptions about how the rest of the code behaves. You could rewrite the above examples as something like:
// C++ pseudocode void do_something_with_char_class(CharacterClass char_class) { //do something } void some_function_involving_characters(Character char) { //map is a programming concept where you "map" a list of values onto a function map(do_something_with_char_class, char.getCharacterClasses()); }In this example, there's two functions, each doing one thing (one to iterate over the classes and one to do whatever it is that needs doing to the class) and they make no assumptions about number of classes; it works the same for 2 classes and 200. It's also easier to read because there's no "noise" for iterating over the number of classes and no copy and pasting. Beamdog have been very keen on the point of removing hard coding. Maximum number of classes is hard coding. They should remove it and make it up to the module builders.
There is always a maximum, of course for creatures and NPC's this limit is not so easily defined, but I can't really imagine that you need to allow infinite classes for an NPC or creature, especially considering that feats and skills can be assigned manually, which makes the need for infinite classes almost irrelevant.
For example the classes have to be stored inside character bic file and for monsters in *.utc blueprint.
Toolset would have to be changed to allow unimited multiclass for npcs.
Nwscript functions would have to be rewritten completely.
Adding 1 more class to use would be much easier. Enabling unlimited of them would require completely redo the already existing code (current code is written similarly to your second example) and even toolset GUI. And also completely rework network code as server is sending client update for all 3 classes.
While I would like to see a minimum of 4 class slots, I would really prefer to see no hard limit. If someone wants to play a character whose gimmick is to take a single level in a different class each time they level up, I want that to be possible.
I'd argue they should just remove the notion of there being a finite number of classes altogether - the fewer assumptions your code makes, the easier it is to change it. Old, hairy code bases (Legacy Code) tend to break in unexpected ways because there's assumptions spread throughout them.
Also, I'd argue that just upping the number of classes is itself a huge potential source of bugs. I'd imagine it would be easier because you're thinking that Beamdog could just copy and paste some code and change some 3s to 4s. There's two huge risk factors that come with this - the first is missing some places (so everything falls to bits because some bits expect 3 and others expect 4) and the other is, when updating code in the future, you update a piece of code but forget/miss the second copy and pasted variant.
Given that there's risk involved anyway, why not just do it "properly"? That way you'll only have to retest them once and not have to worry so much about them breaking when you change things in the future. You make a good point here, I hadn't considered these at all. I can't say I have any specialist knowledge in these regards or know anything about them. I know from the streams that the toolset is really scary to work with on Beamdog's end.
I still don't think it changes much - the key problem is the same - Beamdog has to find all the places that have the assumption of 3 classes and change them to 4 classes and then test them. Changing the code to work with any particular number (or infinite/practically infinte) is the easy bit.
In terms of implementing them, I just can't see why there couldn't be a preceding byte in each of these structures to say how many classes there are and have whatever is reading them act accordingly. Doing it this way puts the maximum number of classes at 256. Yes, it's finite, but it's not arbitrary - it's defined because that is the smallest value a modern CPU can read in one instruction. At risk of repeating Bill Gate's infamous "640k of RAM ought to be enough for everybody" quote, I really think that should be more than enough for everybody. That's why it should be opt in. NWscript functions will still have to be updated no matter if it's 4 or 400. Either way Beamdog should just add a function to NWscript to get an array of all classes (and probably number of classes for a character) that can be iterated through.
Anyway to sum it up, the name of this thread is "The Add the ability to have a fourth class card discussion".
I am all for forth class. I don't think more than 4 are needed. But if BeamDog finds out they can do more and it will be easier then ok do it. I don't think thats the case though.
Heck, Beamdog probably don't even need to do any testing from a GUI perspective beyond 1-3 classes as they can just push the work of making a GUI for it onto mod makers (this is assuming that they do the GUI modernisation/customisation they talked about).
My whole point is why should it be artificially limited to 4? Really it should be limited by technical/business limitations, not by picking arbitrary numbers like 4. Further restrictions should be entirely up to module authors/persistent world admins. Then we will have to agree to disagree on this, I'm afraid. Neither of us have access to the source code as far as I'm aware so we can't really say either way whose opinion is correct. I certainly think changing the number of classes will be a lot of work - I just don't think it's that much more work to go from 4 to 256.
However, on the subject of not needing more than 4, I can see a lot of attractive things from number of classes not being a scarce resource anymore. For starters, Creature Hit Dice from race aren't quite as crippling now. You can also really easily make a Level Adjustment system without unfairly penalising people (give LA races levels in a "Level Adjustment" class that grants no skills, no hitpoints and no BAB).
Not to mention templates with LA are suddenly really easy to implement! You just give players levels in a template class that grants no BAB no LA and no skills but DOES offer class features. Such approaches are extremely unattractive when you've got a very low number of classes available.
--EDIT--
TLDR; think less about Classes/Class Levels and more about Hit Dice/Challenge Rating.
Right, executive summary time then. Apologies if these come across as rude, I'm writing for brevity.
256 tests needed is hyperbole; you only need to test the cases of 1 class (lowest), 256 classes (highest) and some tests for a few values in between. Also, if Beamdog go through with their GUI update they can just test 1-3 and make it mod authors responsibility.
I think adding 4 classes is a lot of work. I don't think that adding 256 classes is actually much more work than adding 4. We can't say if either of our opinions are correct so we'll have to agree to disagree, Shadooow.
Not having a shortage of classes has following advantages:
No matter what you do, in all the .bics, network code etc. there would be at least a byte used (8 binary digits, 0-255, 256 possible values) to declare how many classes an object has. Given that's the case, why not just say there's a limit of 256? It's easier than having some arbitrary number.
Also, while I missed the boat with NWN first time round and never got into persistant worlds, for some reason I'm under the impression that some of them allow levels above 40; either by some weird scripting work around or some NWX feature or something.
I think 4 classes is good, that would be 10 levels in each class. Maybe 8 at the most.
There is a lot of work being done on the game's code and yes adding in refactoring the code to allow more classes will not be easy, it being placed on a todo list would world be great. One way I can personally seeing this done (which would not break backwards compatibility) is a toggle. Make a Boolean with the three class code and if it is false the players can choose the new code and use a new system which supports four or more classes.