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

Reply to thread

Message: <blockquote data-quote="thpr" data-source="post: 3720992" data-attributes="member: 48911">Databases are fast, primarily because they index their contents.  (Note that such an index requires additional memory).  Thus, while there could be improvements in speed, I'm not sure how much it would help on a 256MB memory system.  Perhaps someday we will find out, but there are other challenges with PCGen we need to address first.There are open-source databases we could use; Apache Derby is one example among many.Whether it's "easy" to build a program around a database is up for debate.  The data structure is only one aspect among many in building a character generator program.  Building a generator for the SRD is easy - that can be developed in a matter of months, as many people have demonstrated.  Programming one that can handle the nuances of the additional materials published by the rest of the OGL and closed content is a project that takes years (something also demonstrated by those who have tried or are trying)It's not impossible.  It's just not my day job, because it won't pay the bills.  The economics of a character generator have been discussed before here on enWorld, so I won't re-hash that, but the point is that it won't happen in a typical commercial development environment. It will happen when it's a basement project, or filler for a consultant, or something along that line.In particular to PCGen, we are an open source project, so we're running on volunteer time on evenings and weekends (or days for some of the team that works nights).  There are limits to how much we can achieve in any given period of time.  The other problem we face at PCGen is one of installed base.  Not that I really want to make the comparison, but a similar problem regularly bites Microsoft, as they do their best to maintain backwards compatibility.Recognize that a large portion of the value in a character generator is the data - witness the anger vented when WotC terminated the CMP license.  You can also find posts by various individuals referring to their concern over their home-brew data and future compatibility with PCGen (as we have talked about the changes to take place in PCGen 6.0).The point is, we are making great effort in PCGen to maintain backwards compatibility with the existing data, because we recognize that the data has significant value (due to invested time).  Part of this is because we have regularly received complaints from users when we did not maintain compatibility.  There are consequences to this decision to maintain compatibility, and to a degree, it does slow our evolution.While we could start a new program from scratch - built around a database, perhaps - that is the endless struggle in an open-source project.  There is a pull to enhance the base function (where many users will be) set against adding tweaks for homebrews and strange closed content (power users).  PCGen spent a period of time heavily focused on adding support for additional rules, and I will admit it is a challenge to continue to support these exceptions while we move forward as fast as we can.The problem with performance in PCGen - contrary to the claims of some people who are not part of the project and therefore are not in a position to know - is not Java.  There were design decisions made early in PCGen that continue to impact performance as it was scaled to increased volumes and complexity of data.  We are currently working on rewriting the core of the program to resolve those issues and be much faster, while maintaining backward compatibility.We're honestly working on it... and trust me, when there really is a significant improvement to demonstrate, I won't be quiet about it.TP.--Tom ParkerPCGen Architecture Silverback</blockquote>

Verification