Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="Jay Lofstead" data-source="post: 403551" data-attributes="member: 7199">I fully expect that the person working on the models and integrating them into the digitial environment was the same person (remember that there has been a public statement that there is now _one_ programmer for E-Tools-- they had precious few before the latest incarnation of the team).Fluid may or may not be a good software company, that I don't wish to debate.  Once thing for certain is that they are a very small software company (very little staff).  I agree that if it were a larger company with a lot of staff (like a big name game developer), they would have had separate teams for each piece of the puzzle.  The limited staff keeps things pretty well sequential rather than parallel.  Having worked in software development both on large parallel development teams and in small to single person groups, I completely understand and have experienced the differences.  Before I knew any of the details of the history, just by working with the software, I guessed that it was one or maybe two programmers for about 6 months.  It turns out it was one programmer for 9 months.The pieces of the history that have been published over the months shows that Fluid was intent on ultimately building an online gaming engine (based on a verbal agreement with Wizards).  Once Hasbro sold those rights out from under Fluid, Fluid had to start over (that was the cool part of the project which means that is where the programmers started--as a professional software engineer, I can say this from all of my personal experience and that of all the people I know).  Being that Wizards had not legally contracted with Fluid for the online gaming engine (or anything resembling that), Hasbro could sell those rights without any fear of repercussions from Fluid.  Verbal gentleman's agreements don't hold up in court very well since they are verbal contracts at best.  Verbal contracts are only enforceable for a year from the agreement date in the US.  This all happened more than a year from the start of the project making any hope of a change in licensing "back" to Fluid pointless.  Most of the programming staff left when the rights were sold (my impression is it went from maybe three people down to the one that is there now).  By Scott at Fluid's own admission, in nine months, they started from scratch and built the character maintenance tool with one programmer.  The other threads of failure that doomed this project from early on (besides a lack of a formal contract) were ever changing priorities, the whims of what the programmers wanted to work on next, and complete lack of real project management across the two companies.In my opinion, the fact that a full-featured character/monster/npc maintenance program was not delivered by the time of the third core rule book, they had missed their market window.  That is why we have so many other tools that have been written.  To be honest, it either should have been included in one of the books, or released at the same time.  There was never any real planning on how to handle the electronic and print versions of the materials.  If they had a real plan for the tools, they would have had made sure to get the level of functionality they needed in order to support their publications and have had release schedules with some fixed interval between them (say 30 days after print, the electronic copy is available for purchase and download).My base expectations for the program was an engine capable of hosting the d20 rules with a build of data for everything in the core books (and really all of the Wizards published products as well).  Other features were nice-to-haves, but not a core need.  I know that I can draw maps on paper as fast or faster than I can on a computer.  However, having something manage all of the numbers for me for character/monster/npc creation and maintenance, I can't begin to be as fast as a computer aid (properly written, of course).  Meeting that base level of productivity improvement was the basic need.  Anything beyond that is taking a passable tool into a great tool.  From a legal perspective, one can argue they just barely did make the passable tool.  From a spirit of the idea perspective, they are a LONG way off.</blockquote>

Verification