eTools Patch and Source Code

[Luke]

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?

No problem.

For what its worth, I agree that it shouldn't have been released without templates.
The templates and the prestige classes are huge gaps, that are hard to explain.
I recall well over a year ago, one of the very first (and last) public posts by a Fluid programmer was about how cool it was that they had weapon size adjustments coded in - as an example of how complete their rules adherence was, and I thought "pretty cool". I also recall that at about that time they admitted that they saw and copied somebody's fan spreadsheet, or something, where there were different columns for the same treasure table (minor, major,...). An alarm bell went off in my head then, since this should have been obvious from the core books themselves...
To risk being unfair, I did wonder if the team as a whole were as proficient with 3rd edition material as we were led to believe.

Really, you shouldn't need to depend on programmers being domain experts (3rd edition rules masters in this case). WotC should have defined what they wanted clearly enough in their requirements, so that QA prevented things like this happening.
On the other hand, it was a *lot* cheaper to throw the core books Fluid's way, and say "Here. See what you can do with this...".
I suspect that the initial vision (full intenet game with maps, graphics and sound) made it just too difficult (expensive) to properly define *requirements*. Well defined requirements are absolutely fundamental to successful software developement.

I further suspect that it was hoped that the overall sexiness of the maps/sound etc would create a very forgiving attitude to full rules adherence.
Once the sexy bits got chopped out...

 

[Hollywood]

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.

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.

"Hard-coding" and "scripting" without context are bad terms. "Scripting" is not any different than "hard-coding" EXCEPT that the "code" is available to the end-user, sometimes but not always, to be changed outside of closed system and is either interpreted at run-time or pre-compiled. "Hard-coding" is "code" that the user can not change, modify and recompile.

With an open-source effort there becomes ZERO difference between "hard-coding" and "scripting" because everything is open.

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.

Just because someone, gamer or not, can "code", does NOT mean they can engineer a quality piece of software. It takes a lot more than knowing a little bit of Java, or reading a few tutorials, to build a quality software product.

The, as you noted, the subject must be understood and "experts" on the subject matter should be available to the technical people. Design goals must be laid out, both short term and long term, and absolutely NO scope-creep should be allowed until the first revision is finished... you may scale back features, but not add them. Technical architects must take said design goals and put together a solid architecture that will meet said design goals, both short and long term. Only then should the design and development of the software commence.

3rd party developers can get around some of that, especially in the case where there is a lone or very small [2 or 3] set of core persons working on the software, as they are more able to come to understandings quickly than a bulkier organization such as WotC. Even then, software can easily be turned into nothing more than spaghetti code. Taking short-cuts for a consultant, such as Fluid, when dealing with a large client such as WotC will only lead to failure of the product.

Want to know if your favorite tool's developer is engineering the software rather than just "coding" it? Ask the developer about the BSAs [not so important to 3rd party developers], design and architectural documents, interface mockups and user feasibility tests, UML and database diagrams, etc. They don't have 'em? Then they are doing nothing more than shootin' from the hip. Period.

1) Fluid is a game and graphics company. They had no prior experience with database programming.

Technically any data storage system can be called a database. As a software, game or otherwise, is meant to manipulate data, yes they did have prior experience. As for relational database experience, unless you've seen their resumes, you really don't know for sure. Database "programming" really is not all that hard at its base level. It rises in complexity based on the complexity of the data needing to be stored. 3rd edition data is fairly complex, but its not exceedingly complex nor is there a very large volume of it. Good engineers can come up with very good database designs even if their actual database experience isn't all that much.

 

[Hollywood]

Originally posted by Luke I suspect that the initial vision (full intenet game with maps, graphics and sound) made it just too difficult (expensive) to properly define *requirements*. Well defined requirements are absolutely fundamental to successful software developement.

Bioware managed it. However, they went through an engineering process that covered several years and determined exactly what they could and couldn't do, i.e. only the basic portions of the Core Rules are available.

 

[Fast Learner]

On database vs. scripting: I started design work on a character creation program about 18 months ago and saw the issues with templates and prestige classes you were talking about and concluded that a "pure" database app wasn't feasible without a ton of hard-coding. I came up with a reasonable hybrid system that was database-based where some fields contained, effectively, scripty-bits. While feasible (and I'm confident that it would have worked out nicely), it was clearly a ton of work so I passed. In retrospect, especially with the issues surrounding compliance, I'm really glad I did.

With an open-source effort there becomes ZERO difference between "hard-coding" and "scripting" because everything is open.

This is incorrect. In a pre-compiled scripting system you don't have to complile the freaking application you're about to use, something that's a huge difference for everyone except technical geeks like ourselves. Re-compiling because you want to add, say, some prestige class from some new book is an absurd requirement, imo. In addition if the open source code is written in, say, C or C++ then it would be extremely easy for WOTC to argue that your code wasn't human readable, as opposed to a fairly simple scripting language. There's a BIG difference between "hard-coding" and "scripting" in an open-source effort.

Want to know if your favorite tool's developer is engineering the software rather than just "coding" it? Ask the developer about the BSAs [not so important to 3rd party developers], design and architectural documents, interface mockups and user feasibility tests, UML and database diagrams, etc. They don't have 'em? Then they are doing nothing more than shootin' from the hip. Period.

I agree with all of that, with the possible exception of UML (there are other use-case type systems you can use quite effectively). But that's just a nitpick.

 

[Hollywood]

Originally posted by Fast Learner This is incorrect. In a pre-compiled scripting system you don't have to complile the freaking application you're about to use, something that's a huge difference for everyone except technical geeks like ourselves. Re-compiling because you want to add, say, some prestige class from some new book is an absurd requirement, imo. In addition if the open source code is written in, say, C or C++ then it would be extremely easy for WOTC to argue that your code wasn't human readable, as opposed to a fairly simple scripting language. There's a BIG difference between "hard-coding" and "scripting" in an open-source effort.

Well, scripting systems don't necessarily need to be pre-compiled. Usually they are faster that way, but may not be as flexible. The client-side java/vbscript in browsers or ASP/PHP are examples of interpreted scripting [for benefit of non-technical people ] whereas JSP [its similiar to ASP/PHP but with Java as the scripting language which is superior to Java/VBScript of course] is pre-compiled.

And yes, you are quite right... usually scripting means you only have to make changes and run or compile the new script. But if a system is designed well, it may be very easy to add or change code to it. At the distilled essense there isn't really a difference. About the only difference is technical ability.

And WoTC can argue itself blue as long as it wants. But name me a language, scripting or not, that is human readable by someone without any technical ability at all [i.e. lawyers?]. COBOL and PASCAL come to mind as the top contenders for having a syntax thats closest to English grammar. C, C++, Java, JavaScript all share a very similiar syntax which isn't close to English. PHP is in a world of its own as is VB/VBScript. Etc, etc. And if you start using custom scripting languages [why? there are plenty of good ones to choose from] or say something odd like rules based scripting, it still incomprehensible to those without technical ability.

Bottom-line is basically that the "rules" have to be in human readable form. That could mean having the scripting source or that could mean the actual program souce available. The latter is the way one open-source character generator could have passed compliance.

But the other falacy of all of this is that no-one can copyright rules, only the specific explanation of those rules. So anyone can express the D&D 3rd rules in whatever format they choose, as long as they do not use any WotC content whatsoever. Same thing applies to algorithms... they can't be copyrighted, only specific implementations of them.

However, the catch IRT the SRD is that if you use any of the information in it, you are bound by the legal agreement that came with it that basically says you can't use explain, in any implementation, the character creation or leveling up process.

I agree with all of that, with the possible exception of UML (there are other use-case type systems you can use quite effectively). But that's just a nitpick.

Yeah, first one that came to mind. Heck even flow charts are better than nothing!

 

[Vpenman]

...
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.

"Usable." Talk about damming with faint praise.

Speaking very broadly -- that is not making any specific reference to or inference about E-Tools, Fluid, or WotC -- I believe smetzger is generally correct about where responsibility for published software lies.

When a publisher releases software, that publisher has generally: selected the programmers who developed it, evaluated that program's progress on an on-going basis and decided that project should continue to be funded and developed with those programmers, and finally decided that project is done and ready for publication. These are the publisher's decisions. They are not the software developers' decisions.

Getting a little more on topic regarding the subject of this thread -- it will be the publisher who decides when that patch is ready for release. Both the patch and the product are the publisher's responsibility. It can say "no" at any time.

I completely disagree with smetgzer's database view. Only people who have access to Access and understand how to use it (a distinct minority) can really take advantage of the E-Tools database. I believe the decision made in the Core Rules programs to create a custom database that everyone could use to create, import, and export custom data was far more useful to the vast majority of customers.

While I am at it, I also believe it was a mistake to us XML for printing. It was also a mistake to not include the necessary I.E. and ODBC upgrades on the CD.

I'll stop there.

Victor

 

[Hollywood]

Originally posted by Vpenman Getting a little more on topic regarding the subject of this thread -- it will be the publisher who decides when that patch is ready for release. Both the patch and the product are the publisher's responsibility. It can say "no" at any time.

True. They can also say "release whatever you have now, we don't want to wait, we don't care if its done, or how many bugs it has".

I completely disagree with smetgzer's database view. Only people who have access to Access and understand how to use it (a distinct minority) can really take advantage of the E-Tools database. I believe the decision made in the Core Rules programs to create a custom database that everyone could use to create, import, and export custom data was far more useful to the vast majority of customers.

Not really. Use of an Access database means that there are quite a few, more than you probably think, that can get into the guts of it. What was lacking, perhaps, was easy front-end tools to allow end-users to easily insert new custom data into the program regardless of what was used on the back-end to store the data. Most end-users simply don't care and shouldn't. Besides, there are plenty of good books on the Access database and how to use it out there and it doesn't take too much time or effort to learn... and learning is always a good thing.

Good idea, bad execution.

While I am at it, I also believe it was a mistake to us XML for printing.

Again, good idea, bad execution. Dumping the character out to an XML data format allow end-users to construct any type of output they want via XSL using non-proprietary technology/solutions. However, the reliance on a piece of technology from Microsoft, their XML/XSL object, that was tied to the whole issue of IE embedded in the OS should have raised red-flags. Plenty of other XML transformation objects that could have been used instead.

It was also a mistake to not include the necessary I.E. and ODBC upgrades on the CD.

Poor execution again. Poor QA too.

 

[Vpenman]

...
Not really. Use of an Access database means that there are quite a few, more than you probably think, that can get into the guts of it. What was lacking, perhaps, was easy front-end tools to allow end-users to easily insert new custom data into the program regardless of what was used on the back-end to store the data. Most end-users simply don't care and shouldn't. Besides, there are plenty of good books on the Access database and how to use it out there and it doesn't take too much time or effort to learn... and learning is always a good thing.

...

Boy, do I disagree some more. I hope I am not being too argumentative here. I recognize some very goods points are being raised. I just happen to disagree with some of them.

Speaking very broadly, from a product point of view, what should have been delivered was a product that generated a profit for the company. That profit should have been generated both through sales of the actual product and through an increase in the popularity of 3rd Edition D&D. This popularity would have been generated by allowing people who simply enjoy role-playing without the need to get into the guts of the system to quickly and easily generate, operate, and maintain characters.

Instead, what was delivered was a very expensive, late, product with limited use to people who are not very computer savvy.

I appreciate there will be some disagreement on that last point, but I invite you to read through the posts on this thread, note how many people identify themselves as programmers, and the very technical nature of much of this discussion.

I don't agree that learning is always a good thing. If learning is required to use a commercial product, then that lack of learning is, or should be, a barrier to sales of that product. I can see a benefit from more people acquiring facility with foreign languages. However, if acquiring a facility with a foreign language is necessary to use a product, than that product will not sell as well as if that facility was not required (unless the product is supposed to teach foreign language).

I believe that most people who play D&D would not agree that acquiring a facility with Access "doesn't take too much time or effort to learn".

Instead of being a product that virtually any D&D player with a Windows system can use to make play easier and fun, we have instead a toy for the technophiles among us. By technophiles I mean people who have much greater understanding of software applications than is generally the case and "toy" and "phile" pretty much go together. People, to be more specific, like many who post on this thread.

Based on a number of years in software development where I have communicated with literally tens-of-thousands of users, including thousands who used the Core Rules CD products, I will state unequivocally that the number of users who should attempt to directly modify an Access database is very small. I put that number at well under 10 percent.

To be clear, I am not saying the percentage of E-Tool purchasers who can use Access is under 10 percent. I am saying that for people who would have purchased a D&D utility designed for use by normal users that number would be less than 10 percent. I believe it would be less than one percent.

I mean, look at it. It doesn't even have an autoinstall. When was the last time you went into a retail store and purchased Windows software that didn't have an autoinstall? Look at the downloads people are expected to do just to get a printout. Do you have any idea how uncommon it is for most computer users to download software upgrades? Within the past couple of weeks, there was a study out that reported less than ten percent of U.S. homes have high speed internet access.

Do you know how long it takes to download upgrades over a modem? Do you know how few software users ever even visit a message board like this?

I'll say one thing for using Access instead of creating a custom database, it's a lot easier on the programmer. However, why anyone would use XML instead of the normal Windows print drivers is a mystery to me. As far as I can tell, it has the disadvantage of Access (harder on the users) without the advantage of making the programming easier.

If you have software that requires knowledge of Access, downloading browser upgrades, or visiting message boards to get product support, then you have software that is not right for the majority of computer users.

D&D is not a game designed just for programmers and power users. There was an opportunity with this software to not only make a direct profit, but to also expand the popularity of the gaming system.

Victor

 

[Hollywood]

Originally posted by Vpenman Instead, what was delivered was a very expensive, late, product with limited use to people who are not very computer savvy.

I don't disagree with you here. I'm in the opinion that they did not deliver said product.

..but I invite you to read through the posts on this thread, note how many people identify themselves as programmers...

With the proliferation of computers and the access to webpage scripting, Java and its free compilers, and other such free or very cheap compilers for different languages, its fairly easy for anyone to become a "coder" or "programmer". But there is a huge difference, not to diminish anyone, between knowing how to use an IF or FOR statement or create a CLASS in Java or even how to write a SQL statement to access data in any relational database and how to properly, through disciplined engineering, create a viable piece of software.

I don't agree that learning is always a good thing. If learning is required to use a commercial product, then that lack of learning is, or should be, a barrier to sales of that product.

Um, I can think of a lot of products on the market that require learning to use very well. Word, Access, Excel, Lotus Notes, HR programs such as PeopleSoft, etc.

However, I believe what your point is, that unlike eTools [or some similiar 3rd party software] is that for the most part you can pick up the above mentioned software packages and at the very least write a letter or put enter some data in a spreadsheet without reading through a massive manual. To become proficient with the tool [and thankfully I've never had any reason to become proficient with Word or Excel outside of whitepapers. ] you will need to learn more a bout the tool.

I believe that most people who play D&D would not agree that acquiring a facility with Access "doesn't take too much time or effort to learn".

Learning how to use Access takes far less time than learning a foreign language, as Access like other similiar products, provides an interface that helps protect the "newbie" from the actual language. Databases like say MySQL don't.

The point I was trying to make, was not necessarily is disagreement with yours. You were stating that you wished eTools was more like CoreRules which allowed you, through a somewhat well designed [my interpretation. ] interface, to easily add new custom data to the program. eTools does not really come close, unless you know how to utilize Access [or other databases]. What I am saying is that, no matter how poorly designed/developed eTools is, that utilizing a database that has a high usage in the computer industry as the back-end datastore does allow some enterprising folks, as it has, to create tools or ways to put custom data where eTools fails to allow you to do so. The failure, for what I preceive you were saying, is with eTools interface/program, and not the back-end, i.e. Access.

Instead of being a product that virtually any D&D player with a Windows system can use to make play easier and fun, we have instead a toy for the technophiles among us. By technophiles I mean people who have much greater understanding of software applications than is generally the case and "toy" and "phile" pretty much go together. People, to be more specific, like many who post on this thread.

Yes, again thats the failure of eTools, not of the choice [for good or ill mind you] of Access as a data repository.

I mean, look at it. It doesn't even have an autoinstall. When was the last time you went into a retail store and purchased Windows software that didn't have an autoinstall?

Personally I detest "auto-install". But eh, in reality thats simply a small .ini file on the cd they didn't put together. Nonetheless, yes I agree. I'm not defending eTools at all.

Do you have any idea how uncommon it is for most computer users to download software upgrades?

Yup, and thats why there are so many people with computers, since most PCs run Windows of some sort, are hacked because they don't keep up with the virus updates and Windows updates. Nonetheless, most people who play computer games, even on a somewhat regular basis, are going to be likely to realize the need to check for updates.

But again, this is totally the failing of the eTools software and its implementation, not necessarily the technology [of which both Access and XML are] used to build it.

Do you know how long it takes to download upgrades over a modem? Do you know how few software users ever even visit a message board like this?

Yup... I remember surfing the internet, Gopher, Talk, et al. way back on a 2400 baud modem running on my MicroChannel IBM 286. Or in dorm room's with 8086s and green and amber screens.

I'll say one thing for using Access instead of creating a custom database, it's a lot easier on the programmer.

Of course. Not writing your own file system or relational database but rather using proven components will allow you to concentrate on more important aspects of developing said software. No reason to invent the wheel again.

However, why anyone would use XML instead of the normal Windows print drivers is a mystery to me. As far as I can tell, it has the disadvantage of Access (harder on the users) without the advantage of making the programming easier.

Well with XML, a "technophile user" can create new output formats. He can always post those where other people can get to them. There are other uses such as exporting and importing into other programs, etc. As long as the solution allows the average user to use the software without problems and like with eTools save and print out a character, then utilizing a technology that allows other more advanced users to expand upon the basics is a good thing. Have to say though eTools seems to have been a bust at this.

If you have software that requires knowledge of Access, downloading browser upgrades, or visiting message boards to get product support, then you have software that is not right for the majority of computer users.

Depends on the software of course. But in this day and age, you should keep your software up-to-date [even on a 56k modem]. It'll save you a lot of trouble going foward.

D&D is not a game designed just for programmers and power users.

I don't disagree. Actually, it wasn't really designed with software development in mind, no matter what WotC may claim.

 

[Fast Learner]

I'll politely disagree with your thoughts on Access, vpenman. Using Access is far better than a custom database. Where eTools fell down is in providing easy tools to manipulate that Access database. If you have two tools, one that uses Access and one that uses a proprietary database, and neither tool has an interface for modifying the database, I'd much, much rather have the Access one so that at least someone outside of the original development team and some hardcore hackers can modify it. Because Fluid uses Access, the day eTools was released we had a publically-available tool for modifying the database, a very simple utility for doing so was released within another day or so, and within a week an uneducated (no knowledge of Access) user could add splatbook material to eTools.

Certainly eTools should have been designed to allow easy modifcation by users, but lacking that, Access is much better than nothing.

On the subject of making users download browser upgrades: amen, that was a terrible, inexcusable QA mistake.