Procedural Generation | Computer Graphics | Math

A few months ago, I developed a custom, flexible data structure designed to handle the challenges presented by the project in terms of data storage and transfer. I refer to these structures as GDS, or generic data structures. I have been improving on the capabilities of the GDS system since its inception. Among the many important features of the GDS is it's ability to store other GDSs within itself. A GDS may, this way, be nested up to ten times within another. In other words, you can have a data structure within a data structure within a data structure within a data structure, and so on, which is extremely handy for keeping data organized yet easy to transfer and work with at the same time. I can basically store an entire heirarchicaly organized pool of data in a single variable. Best of all, each GDS can be written and read from a file just as a single, large string would.

These structures, however, can get quite massive (especially the main structure that mGen uses to pass between modules - this structure usually has hundreds of sections and up to four nested levels).

Today I created a small tool called the "GDS Inspector" to facilitate the process of examining GDS blocks when debugging. The problem arose while working on GGrewve. I needed to inspect the dictionary block because I was having problems. Opening the block in notepad, however, was very messy because of the way GDS stores data (which is flexible and rather efficient, but not at all notepad-friendly). The program I wrote displays all the data in a given GDS block in a manner much more conducive to analysis - a treeview. A treeview is basically a hiearchy. One can see the nested levels of GDS storage and click on each entry to view the data held therein. This greatly facilitated the debugging process, not to mention I had a great deal of fun looking at how complex the main data structure actually is (notepad doesn't really do it justice).