Joshua Randall said:
I'm with you,
barsoomcore. I just want to be able to add skills and feats and have the math come out correct. PCGen can't even do that consistently. (No, really: it can't.)
A challenge for you programmers: build a character generator (or tracker) using only the subset of the SRD 3.5 that appears in the PH; i.e., not including any PrC's or monsters-as-characters or whatnot. Now, can your generator make mathematically perfect, complex PCs with a dozen different weapon feats, and have the BAB come out correct? When you can do that, you can sell me your product.
I tried that, back in 3.0. I needed a way to create characters and manage them during the game, and I wanted all the boring stuff to be made by the software. C++, heavily object-oriented, worked on Linux. Every game object (class, feat, monster, stat, whatever) had its own class, and lots of inheritance was involved (eg, Item -> Weapon -> Ranged Weapon -> Light Crossbow). Every object could send or receive messages, and the effect of a user action would cascade through the character to change everything that needs to be changed.
I could click on Barbarian Rage and the code for the Rage would be called, which would tell Constitution "go up by two". Constitution would shout out "I went up by two!", HP would hear it and adjust itself, and so on. Very easy to debug, too; just trace the messages.
Advantage: I could create a half-fiend vampiric ogre ranger/barbarian dual-wielding a bastard sword and a +2 keen dagger, with Weapon Finesse, raging, and read the correct attacks and damage for each attack on the screen. Then terminate the rage and read the new correct attacks and damage, including the fatigue effect. Then terminate the fatigue and read the right stuff again. Then unequip the weapons and read the claw/bite attacks. It even did monks with shuriken, and you know the infernal way shuriken work in 3.0. Pretty good I think. I had all the PHB and a bunch of monsters and templates before I got tired of it (minus the actual effects of spells, though the infrastructure was there).
Big disadvantage: can't add stuff without recompiling. Adding something trivial such as a weapon with no special rules, or a feat with no mechanical effects, is as easy as copying/pasting a single line in a source file and changing the name - the logic would be inherited by parent classes. But complex stuff, eh, you must know C++ and the program's message architecture.
What can I say - back then, I was already good at coding but I hadn't done much software engineering. The message-based architecture was a good idea, as was the inheritance, but lots of other details I'm a bit ashamed of (reason for which I won't release the program). The possibility of adding code to any aspect of any game object means ultimate flexibility - but being
forced to do it is bad, not counting the fact that integrating different versions would be a problem.
Maybe a hybrid approach would work better: define game objects in simple, limited XML, with the option to also give them an actual class. Simple stuff like "it's a melee weapon dealing 1d8 piercing damage" can be in the XML (the Weapon base class will interpret this), complex stuff like "you can forfeit an attack to gain a +2 dodge bonus to AC" goes in the code. The class could be stored in a DLL; the program would read the class name, load the code, and start communicating with it via the well-defined message system. This way, you could make "packages" for a book, containing an XML file and a DLL; users would simply download them and plop them in the program dir, and the new stuff would be available in the program and even interact correctly with other packages written by other people (as correctly as the books themselves do anyway... which sometimes isn't much). Any user would be able to add simple stuff, while developers and other "power users" willing to write a bit of C++ and read the message specifications could make the complex, active things. Other programs could just read the XML and make what they want with the data it contains, or link to the DLLs and start swapping messages. Saving/loading could be conceptually similar, too.
Anyway, I won't make this. I estimate around one year of hard work to fully define the message system and XML, build the program, make the PHB package, and test them. I don't have that kind of free time any more. Out of academic interest, what do you professionals think about this architecture?
Just kidding.
