BZWorkbench Progress

Let me say this: This was the best summer I have ever had.  I got to spend ALL of it doing what I love–programming, and getting paid for it to boot .  I got to enhance my knowledge of the C++ language, flesh out my fledgling OO-programming skills from the previous school-year, learn how to use a scenegraph API, learn how to (truly) use a widget set (I don’t really count Swing as a true widget set, even though I know how to use it), develop the largest single application I have ever created (~20,000 SLoC and counting, for whatever that’s worth), and work with the outstanding development team and community of one of the longest-standing 3D games ever made.  August 31st can come and go; I’ll still be working on BZWB simply because developing it has been such a pleasure.

That said, here’s what is stable and complete enough to actually USE in BZWB:

• BZW 1.7.x support (boxes, pyramids, teleporters, water level, options, world size)
• 3D object manipulation
• Object plug-in system
• .bzw import and export (even for unsupported data)
• basic editor features (cut, copy, paste, duplicate, delete, new, open, save, save as, etc.)
• object transformations (shift, shear, spin, scale)
• material references
• simple materials (texture, addtexture, ambient, diffuse, specular, emission, shininess)
• Cones (mostly to test and implement BZW 2.o features; other BZW 2.0 objects can be easily added).

Here’s what I’m going to focus on until the end of GSoC:

• define/group (the code back-end is mostly there; rendering is what’s needed most)
• teleporter links (the code back-end is already there, as well as most of the geometry code.  They just don’t render.)
• better material support (won’t get completely done, but commonly used keys like resetmat, notextures, notexcolor, notexalpha, color [i.e. keywords for color] might.  More esoteric keys like spheremap, occluder, etc. have textual support, but not rendering support).
• physics drivers (after getting materials to work, this will be CAKE).
• improved 3D cursor rendering
• material creation/configuration dialogs (already started)
• zone (haven’t started; don’t know what to expect just yet)

Here’s what probably won’t get done by August 31st:

• texturematrix and dynamicColor (they can be parsed and saved, but not properly handled and rendered)
• full physics driver configuration dialog box (we’ll see how it goes; maybe I’ll get to it)
• arc, sphere, tetra, weapon, meshbox, meshpyr, mesh (there’s a reason I’m putting these off; keep reading)
• infinite undo/redo logs (possible to add; it’ll just take a while)
• tank ruler (not as important as the aforementioned features; easily added, however)

I’ve talked this over with my mentor, and we both agree: it is more important that I focus on the editor itself right now rather than object support.  Mainly, configuration systems, usability, and more esoteric BZW objects that cannot be directly rendered or have no atomic manifestation (material, dynamicColor, phydrv, texturematrix, define, group, zone).  As such, one of the features I’ve been working on as of late is a good source-level plug-in system.  BZWB’s data model infrastructure has a mini-API to register and unregister object support.

To support an object, all that the model needs are these:

• the object’s header
• the object’s hierarchy (if it contains sub-objects)
• the object’s footer (usually this is “end”)
• a static initializer, which in implementation is a pointer to a method that takes a reference to a string (if the string has any data, it will be the object’s BZW representation) as it’s sole argument and returns a pointer to a new DataEntry (usually by calling the object’s constructor).
• a static configuration dialog generator, which in implementation is a pointer to a method that takes a pointer to a DataEntry (the object in question) and returns a pointer to a new ConfigurationDialog (the base class for all configuration dialogs in BZWB).  The pointer to the new ConfigurationDialog is, in implementation, passed to an instance of the Master Configuration Dialog, and is activated when the user clicks “More…”

Every object in BZWB has thus far been implemented as a plug-in, and in the main() method an appropriate call to Model::registerObject() is made to add support for the said object BEFORE anything else is done (this is because before the Model class can begin loading and exporting worlds, it needs to know how to parse objects).  In the near future, I’ll create a file in the root directory (plugins.cxx, or something) where all the registration happens, so object developers can easily add support for any objects of theirs.

To implement an object, you need to create a class that ultimately extends DataEntry.  However, all objects that are rendered and support transformation keywords (position, size, rotation, spin, shift, shear, scale) out of the box need to extend a different class:  bz2object.  The whole point of me working on materials, physics drivers, defines/groups, water levels, etc. instead of spheres, arcs, tetras, meshes, etc. was because the former classes do NOT extend bz2object and are handled completely differently (and are often dependent on knowing the internals of BZWB), whereas the latter objects can easily be created by 3rd party developers, with little knowledge of the internals of BZWB.  And after the 31st, it will be permissible for other developers to start contributing code to my project.  My hopes are that once the 31st has passed, BZW 2.0 object support will become available faster than I myself could have implemented it because others will be able to help me.  THAT is why I’m focusing on the editor-specific features–THOSE features I can implement faster than others, and these last few days would be better spent on improving editor features rather than object features.

Make no mistake, BZWB will become the ultimate BZFlag world editor.  It will just take more time than allotted by GSoC, but I have every intention of continuing work on the project after GSoC ends.  Believe me, I LOVE working with the BZFlag community on this