Nightstorm said:
This is coming from someone that knows nothing about programing. But it seems to me that in the year 2002 with the level of computer software we have now that making a program that generates characters should not be that hard to do. Am I missing something?
Quite a few things, actually. Others have mentioned how much the moving target problem slowed e-Tools, so I won't comment on that.
While using the latest tools would have helped considerably, though it would take time to get up to speed with them. An object-oriented, garbage-collected programming language with a strong GUI class library would be best for this kind of job, but programmers at a game-focused company like Fluid are unlikely to be familiar with that kind of programming. It's mostly practiced in C++ inside of major commercial software companies (yes, this means Microsoft), and in Visual Basic (and to a lesser extent C#, VB.NET, and Java) building internal apps at nearly every mid-sized to large company in America.
IMO, the best tools today for C/C++ guys on a Windows platform -- which I'm assuming Fluid's team were -- would be the C# language and Visual Studio.NET. But I'm guessing that they wrote the program in C++ using Visual C++, because it was the language they knew best, and because VS.NET wasn't out when they started the project. Switching tools wouldn't speed them up right away, though, because it takes time to become familiar with a new style of programming, a new language, a new development environment, and to a new major class library. And they'd make a lot of mistakes by trying to write C++ in C#. Note right here that this means the program wouldn't work on Windows 95.
Since I'm one of those boring corprate guys builds internal apps all the time (and I'm really good with VB.NET, which is in most cases just as functional as C#, but easier for someone who's spent the last three years working in Visual Basic like me), I'll bet if I really worked at it, I could make a chargen program that worked for the kind of characters that I play and was useable
for me on
my PC.
But...
I love toolbars and hate menus; I don't know how a UI that I like would play out with other people, and I don't have access to a diverse set of testers. I'm a terrible artist, so many of the toolbar buttons would be mind-bogglingly ugly. Certainly the documentation would suck; I would have wrote the thing, so I know how to do everything with it. I might declare out of hand that you can't build a character with more than three classes, because who the heck does that, anyway? Items that were hard to code in might not be in the program unless I needed them for a character that I was working on. I really don't like half-orcs, so I wouldn't hurry with putting them in. And since rangers got the shaft, and I'm a Wheel of Time nut anyway, the Woodsman goes in... anyway, that's the kind of thing that's covered in the 'for me' part.
Getting install programs to work right can be painful for a lot of reasons. My program might very well look terrible if you weren't using a 19" monitor at 1152 x 864 x 32bit color under Windows 2000. That's what I use; you probably don't. Testing with large fonts, odd resolutions and color depths, every supported OS -- and this includes the non-US English versions, even if you're not translating anything -- is a massive effort for any commercial product. And I'd have to test on computers both much faster and much slower than mine, and those with considerably less memory. Which is the 'on my PC' part of the equation.
Anyway, dealing with both the 'for me' and the 'on my PC' problem are only parially dealt with even by the latest development tools, you still need good design and testing to deal with that. Which is why it takes a lot longer to develop a commercial product than a roughly equivalent one-off program that you'd write for yourself or some specific client.