eTools Patch and Source Code

[ddavison]

I followed the initial Master Tools development religously until I realized that a watched pot never boils... After checking back 3-4 months later, I didn't see a whole lot of tangible progress and I thought I remembered seeing something about staff turnover for the project. I personally think the developer turnover had the largest effect on the end product. After all, you had a fairly nice looking, intuitive product that shipped along with the PHB -- and then you ended up with a cumbersome, clunky application called eTools.

IMO, the dramatic shift in program design could mean one of two things:

1. The initial design, while aesthetically pleasing, didn't scale properly and needed to be scrapped. If this is the case, then the initial programmer didn't do his job right.

2. The initial programmer either left or was replaced and a new lead programmer took over the project. As is often the case, most developers think their vision is better and choose a complete re-write instead of working from the existing structure. If this is the case, then the 2nd lead programmer was insufficient (or maybe they weren't properly motivated).

I am also a full-time developer who has worked under, with, and as a lead to other programmers. Some people can design, implement, and manage while others can only do one of them. For this complex of an application, you really need someone leading the team that can do all three. (S)he doesn't necessarily have to do all three, but they should definitely be capable.

 

[Fast Learner]

That particular change was brought about by user request. Tons of people complained about the UI in the thing that came with the PHB and cried "Make it a basic Windows UI!" Et voila. Personally I liked the previous interface quite a lot. Alas.

 

[ColonelHardisson]

OK, you guys seem to know what you're talking about when it comes to programming. I know nothing about programming, so this isn't an ironic or sarcastic question - I genuinely want to know: Would it have been a prohibitive amount of work for E-Tools to have Templates (Vampire, etc.)? Also, is it at all possible that the patch will add Templates (I doubt it will, just a hunch, but I thought I'd ask)?

 

[Luke]

I genuinely want to know: Would it have been a prohibitive amount of work for E-Tools to have Templates (Vampire, etc.)? Also, is it at all possible that the patch will add Templates (I doubt it will, just a hunch, but I thought I'd ask)?

Now there's one of the big questions.
I'll speak as somebody whose done it (in RolePlayingMaster).

For me, adding a template to a Race is pretty much a case of applying more than one race definition to a creature. It's not *that* hard - at least with the environment I built up as an RPG engine.

I suspect that one of the big issues is that Fluid went for a total data configuration solution, as opposed to a combination of database configuration with scripting.
I suspect that this is an issue because up until you start looking at prestige classes and templates, the rules seem to be reasonably coherent, and capable of being expressed as data (as opposed to script code).
Prestige classes are, by the way, the other big hole.

Certainly there are some clear reasons why Fluid may have opted for a database configuration:
- Its easier for them. Throwing scripting in complicates things siginificantly more than building user interfaces around a database.
- Its easier for users. Joe Average user is more likely to avoid trouble adding database fields through a user interface, than if he tries his hand at a scripting language. That said, I'll wager that Joe Average Pen-and-paper user would be statistically more adept then Joe Average NeverWinterNights players (which also offers scripting).

Certainly, without scripting, I don't think that E-Tools was ever going to live up to (perhaps unfair) expectations:
- E-Tools barely copes with straight, core D&D. If you think it'll handle generic D20 well, you'll be sticking to a very limited subset of whats available.
- The more loose the rules become (prestige classes and templates as an example), the more complex the database structures and relationships you need to evolve to cater for them. You reach a point of diminishing returns, where it becomes more complex than a simple script. I'll bet the qualifying criteria for the LoreMaster prestige class is hard-coded into E-Tools. So, if LoreMaster wasn't part of core D&D, and you tried to enter it as a D20 prestige class, you're stuck.

Will templates be in the patch?

Possibly. Fluid have the ability to hard-code in any of the hard bits, and they've also had time to extend their database configuration structure to cope with a specific set of templates (ie. the core ones).
If templates are in the patch, it'll be a test, to a degree, of how committed the product owner is to the future of E-Tools. A hard-coded solution is easier, but a dead-end to the product's future (since it only handles core D&D). Taking the high road of extending the database structures (which probably creates backwards compatibility work for current E-Tools owners) shows a commitment to opening up capabilities for D20.
To be fair about being dedicated to the product's future, there probably hasn't been enough opportunity to do the fully half correct solution.

What the product really needs is to embrace scripting, and I'll be mega-surprised if they've done that.

Third-party developers (like me) are lucky, in a way, that licensing restrictions virtually force you to implement scripting anyway, for any really decent product.
[Please, don't throw any counter examples at me publicly. Lack of scripting in anything decent implies very serious questions of being genuinely license-compliant. Just because Wizards don't spot it doesn't mean its genuinely, technically, compliant].

 

[ColonelHardisson]

I was wondering about this, because I use Templates a lot. Without them, E-Tools isn't as useful to me as it could or should be. I don't want to complain about it too much, but after playing with E-Tools for a while after buying it, it's been sitting on a shelf. So, I just wondered if there was some deeper, technical reason why the utility of the product was limited the way it is.

 

[Luke]

So, I just wondered if there was some deeper, technical reason why the utility of the product was limited the way it is.

To re-state what I said in a less convoluted way (hopefully):
Standard (non-templated) characters/creatures are relatively simple, since you "simply" contruct a creature froma single race definition.
When you add a template(s), you typically, effectively combine multiple "race" definitions into a single entity from which to build a character/creature. Not only that, but there are often complex interactions between the different "race" definitions, such as when the Race HD is modified.
Without the pleasure and the pain of scripting, the complex interactions are hard to reconcile in a way that makes them work. Essentially, building a creature out of a single race definition is child's play, compared to correctly combining several race definitions in the correct way, and building a creature from that - especially within the confines of a rigid database structure.

ReTake on qualifying for LoreMaster :
If scripting is available, its not *that* hard to come up with some code that will examine the appropriate variables and see if your character qualifies for LoreMaster.
On the other hand, trying to come up with a general purpose database that can achieve the same thing without code, is likely to be *hugely* cumbersome.

 

[smetzger]

Luke - I know that you are a big proponent of scripting + database. This strategy seems to work good for RPM and it is the most flexible.

However, it is possible to do alot without using scripting. Of all the 3e programs released yours is one of the few (and maybe only) that uses scripting.

Fluid could have done everything in the database to cover the 3 core books; it may not have allowed for entry of all splatbooks and 3rd party material. But, they could have done this without hardcoding.

First off I believe that e-tools has failed. I believe it is for a variety of reasons:
1) Fluid is a game and graphics company. They had no prior experience with database programming.
2) WOTC prioritized the wrong things, like sounds and 3d scans and mapping. IMO the character generator should have been the priority with everything else being secondary.
3) The WOTC person in charge of the project changed frequently.
4) Hasbro, sold the video game rights out from under Fluid.

I think most of the blame falls on WOTC. They are the ones who selected Fluid for the job and they are the ones who mismanaged the project. WOTC doesn't have much excuse for this. They have managed other projects like this (CD Core Rules I & II). Although Core Rules I was pretty bad, Core Rules II was usable.

IMO the only thing that was done correctly was using a standard database instead of a custom one.

How can WOTC fix this? I think the best thing for WOTC to do is to:
1) Deliver the long awaited patch
2) Release clearer software wording for d20 software.

Also, if WOTC wanted to be agressive in addressing this issue they could:
1) Release the source code for e-tools.
2) Keep an up to date list of OGL and d20 software links on their web site.

I don't think that WOTC needs to produce any more D&D software. The 3rd party D&D software industry is really rich with decent software. If they just encourage this industry a little bit everything will be fine.

 

[Arnix]

As a gamer who is a programmer (not a programmer who picked up gaming), I think that the approach to e-tools was wrong.

They hired a group of non-gamers to write the code. If you look at the successful 3rd party software out there, you will see that the majority of them are written by gamers who can code, not programmers who read some gaming books to figure out how the rules worked. Only a true gamer can pick up on the subtle intricacies that are in 3rd Ed. The group needs to be at the very least, lead by a true gamer, who can fully explain whats going on and make sure that its done right. If thats not done, you end up with a piece of software written for fanatics, by people who don't know truly understand their target audience.

(Pardon spelling, I forgot how to spell when I got a compiler)

 

[Luke]

However, it is possible to do alot without using scripting. Of all the 3e programs released yours is one of the few (and maybe only) that uses scripting.
True. But without scripting you skate on very thin ice with license compliance - as the license is interpreted by Wizards (not a popular interpretation with developers - and especially difficult without scripting). I could say more, but that would likely head this thread down a path I don't want to go.

Fluid could have done everything in the database to cover the 3 core books; it may not have allowed for entry of all splatbooks and 3rd party material. But, they could have done this without hardcoding.
You mean no hard-coding, *and* no scripting. As a single example, I'd be interested in you taking a look at the mathematical expression on qualifying for the LoreMaster class, and tell me how you come up with a purely data-driven solution.
After that, cast your net wider, to generic D20. Look at the popularity of PCGen when it had all that other D20 material. People are *not* happy at currently being mostly restricted to the core material.
It reasonably true, though, that software primarily producing static statblocks has less need of scripting than software also offering in-game mechanics automation. When you want your stuff to be openly extendable, and do the right things in a changing in-game environment, scripting quickly stops being an optional extra.
Taking examples from RPM:
- The Power attack and Weapon finesse feats are not just little text entries on a statblock output. These feats are scripted to allow you an interface to adjust the points you assign to them, and the attacks, damage and AC are all adjusted to your choices.
- Barabarian rage is not just a piece of text on the statblock. You get an option to turn it on, and when you do, all your stats change, filtering right down to the effects on attack and damage.
- Your monk doesn't just get a statblock printout for her monk attack. She has an *option* to take the extra attack for a penaly (Flurry of Blows), and also, and *option* on whether or not to use the Monk BAB (not a straightforward choice if multi-classed).

So, depending on how much you want to do, things get rapidly more complex and demanding of a scripted environment.

True, Fluid can hard-code, rather than script, since they don't need to obey the same license requirements, but without providing the scripting service, they make it extremely difficult for people to put in D20 expansion stuff.

I think most of the blame falls on WOTC. They are the ones who selected Fluid for the job and they are the ones who mismanaged the project. WOTC doesn't have much excuse for this.
Perhaps. Its worth remembering that there was initially a secret "internet gaming" drive behind the whole project. Maps, graphics and sound made a lot of sense from that perspective. An Infogrames/Hasbro deal cut up that initial concept, and very probably did more damage to the project than anything else.
From a commerical management perspective, considering the absolutely extreme changes to the requirements, the project was probably on a bit of a death march from that point on.

 

[ColonelHardisson]

To re-state what I said in a less convoluted way (hopefully):
Standard (non-templated) characters/creatures are relatively simple, since you "simply" contruct a creature froma single race definition.
When you add a template(s), you typically, effectively combine multiple "race" definitions into a single entity from which to build a character/creature. Not only that, but there are often complex interactions between the different "race" definitions, such as when the Race HD is modified.
Without the pleasure and the pain of scripting, the complex interactions are hard to reconcile in a way that makes them work. Essentially, building a creature out of a single race definition is child's play, compared to correctly combining several race definitions in the correct way, and building a creature from that - especially within the confines of a rigid database structure.

ReTake on qualifying for LoreMaster :
If scripting is available, its not *that* hard to come up with some code that will examine the appropriate variables and see if your character qualifies for LoreMaster.
On the other hand, trying to come up with a general purpose database that can achieve the same thing without code, is likely to be *hugely* cumbersome.

I appreciate the effort you're making to explain this to me, and I apologize for my lack of knowledge in the area to really understand. Let me ask this: I don't think E-Tools should have been released without Templates, since they're a fairly major part of the rules; am I unreasonable in thinking this?