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

Reply to thread

Message: <blockquote data-quote="Celebrim" data-source="post: 5907485" data-attributes="member: 4937">What you guys are trying to create is essentially an ad hoc reporting tool.You've got tables/views and a means of creating them, you've got means of creating 'has a' and 'is a' relationships between the tables, and you seem to be moving toward some sort of simple scripting language for formating the data (in to for example paragraphs and sentences).First, don't enter tables row entries in terms of the number needed to be rolled in order to get that result.  Rather, enter table row entires in terms of their weighted likelihood.  The numbers needed to select a result are computed from the weights.  How they are stored is a performance issue that hopefully your developer is good enough to think through, but from an interface level, its much easier to manipulate weights than number ranges.Second, organize your interface in such a way that it tends to loosely enforce naming conventions.  That makes sure that the database of table assets is searchable.  In other words, don't have an interface that encourages the name BOBSEVILMONSTERS be entered into a single textbox in the interface.  Rather, encourage naming conventions by having the table creating interface have multiple textboxes for entering things like 'creator', 'category', 'subcategory1', 'subcategory2' etc.  That way, you'll tend to have the community adopt a common naming convention (or at least, a somewhat more organized one).  Also, I haven't seen it discussed yet, but it would be a good idea to be able to force selection from a table.  Say you've decided that all hobgoblins carry broadswords rather than random weapons you'll want to be able to do something like <my_weapons>[1] or <my_weapons>{'broadsword'}.  A row in the table is a parent (the identity of the table), the row name, it's weight, and then a generator description in your scripting language (which can reference other tables which in turn have rows with their own generator description).  Obviously, you'll need a sanity checker at the time the row is saved to make sure that you have a strict tree and not a grid (that can produce infinite loops).  My biggest worry as a developer at this stage is the potential resources this thing will consume.  Ad hoc reporting is extremely resource intensive.  I'd be thinking about making this thing have a thick client with only intermittant connection to a hub repository.   I wouldn't want to do this with a simple web client/server interface unless the customer (EnWorld in this case) was willing to accept the potential server hit.   That also deals with the issue of John changing his table definition in a way that is breaking - ei, John decides to reference a table which unbeknown to him causes someone elses table to be recursive or John decides to delete a table other people depend on.  The thick client is relying on local copies, and the user doesn't have to accept John's update unless he wants to.   Of course, that is a different architecture that Morrus seems to be wanting to do, in that it would involve a downloadable client and some sort of API, rather than just extending the bulletin board system.</blockquote>

Verification