BZWorkbench Progress

FEATURES AND DEVELOPMENT SPECIFICS

(subject to revision as deemed necessary)

Priority 1 features will definitely be implemented by the end of GSoC.
Priority 2 features will likely be implemented by the end of GSoC.
Priority 3 features might be implemented by the end of GSoC if there’s time.

BZWorkbench Editor-Specific Features

Priority 1

• BZWorkbench shall provide methods to load and save .bzw 2.0 files.
• BZWorkbench shall save it’s configuration on a per-project
  basis; the editor’s configuration for a particular map shall be stored
  in comments inside the .bzw file.
• BZWorkbench shall be comprised mainly of a 3D scene, with some toolbars at the top and/or bottom.
• BZWorkbench shall prompt the user to save unsaved changes upon exiting.

Priority 2

• BZWorkbench shall have a plug-in manager that can
  dynamically load binary plugins. The format of the plugins is
  still TBD, but BZWorkbench will ship with an SDK to faciliate their
  development.
• BZWorkbench will automate the creation of certain object
  features, such as the performance optimization fields under the
  “drawinfo” field in mesh objects.
• BZWorkbench will save ALL steps taken to complete the
  world in an infinitely long (as long as memory permits) undo log.
  The undo log shall be saved separately of the .bzw file to keep
  the size of the .bzw file down.

Priority 3

• If time permits, BZWorkbench will automate the creation of “inside” and “outside” points in meshes.
• BZWorkbench, if time permits, will have a Tip of the Day dialog.

BZWorkbench Configuration Dialogs

(see http://www.u.arizona.edu/~jnelson/bzworkbench.html for details)

Priority 1

• The project shall use FLTK 1.1.7 for its widget set and non-3D UIs.
• Each UI will be developed in its own class. The code
  for each UI shall be kept in a folder of the same name. For
  example, class WorldOptionsDialog will have a WorldOptionsDialog.h and
  a WorldOptionsDialog.cpp file in a WorldOptionsDialog folder in the
  source heirarchy.
• Each dialog-oriented UI will be an extension of a custom
  base class: Fl_Dialog. Fl_Dialog is an extension of
  Fl_Window, but its constructor takes flags that can be OR-ed together
  that can add OK and CANCEL buttons in a specific Fl_Group container at
  the bottom of the dialog. The callback of the OK button will be
  dialog-specific, but should at least read the data from the widgets and
  store it in private members of its class. The CANCEL button
  simply schedules the Fl_Dialog for deletion.
• Each UI should store local copies of data from its
  widgets, which will be synchronized with a centralized, internal data
  model of the world.
• The Global Menu shall be accessed by right-clicking on the
  main window, or by using a key combo in the case of one-button Mac
  mouses.
• All configuration UIs shall be accessible directly or indirectly from the Global Menu.
• The Master Configuration Dialog shall control traits common to all objects.
• All objects will be modifiable via the Master Configuration Dialog.
• Objects such as arcs, tetrahedrons, spheres, teleporters,
  bases, world weapons, meshes, etc. will have object-specific
  configuration dialogs, each of which shall contain widget combinations
  to allow modification of every specific feature defined by the BZW 2.0
  standard.
• The layout of each dialog will conform as best as possible to the UI mock-ups found at the aforementioned link.

BZWorkbench 3D Scene

(see http://www.u.arizona.edu/~jnelson/bzworkbench.html for details)

Priority 1

• The 3D scene shall graphically display all types of information stored in BZW 2.0 format.
• The 3D scene shall have a ground plane (the X-Y plane),
  divided up by a grid. If a water level is specified, it will be
  rendered above the ground plane and will be translucent for convenience.
• Objects, when placed, start out on the ground plane and are centered on a grid point.
• Selected objects shall be shaded green to indicate that they are selected.
• When selected, objects can be dragged along the global axes, rotated along the global axes, and scaled along the global axes.
• Multiple objects and groups can be selected at one time.
• Selections can be manipulated as though they were individual objects.
• Grouped objects shall be enclosed in a purple circular perimeter.
• Zones shall be enclosed in a yellow rectangular perimeter.
• Physics drivers shall be rendered as a small, rotating black box just above the applicable object that reads “PHYS DRVR.”
• The camera will be controlled like a trackball.
• A scale model of a BZFlag tank will be available as a gauge for map development.
• The user can hide objects to prevent occlusion of their
  work. Hidden objects will appear translucent, and can only be
  selected by double-clicking (as opposed to single-clicking for visible
  objects) to avoid inadvertant selection.
• The translucency of hidden objects can be adjusted.
• Objects that move and rotate shall do so if the user wishes it.
• Dynamic objects, like texture matrices, will appear to be dynamic if the user wishes it.

Priority 2

• BZWorkbench will support the importation of meshes from mesh files, such as .ac3d, .3ds, .obj, etc.
• BZWorkbench shall implement methods to save selections for future use.
• World weapons can fire if desired, and will show a bounding sphere of their range.
• Rendering optimizations can be controlled, but will be activated by default.
• The 3D scene will respond in real time to changes made in the UI.
• The world dimensions can be changed at any time.
• The entire world can be scaled and resized on the fly if need be.
• Movement of objects outside the map can be made to resize the world to accomodate them (optional).
• Objects can be graphically rotated around local axes as opposed to global axes.
• Meshes can be edited dynamically (if time permits)

Priority 3

• BZWorkbench will attempt to define inside and outside
  points for meshes, but they will be editable if the user desires to
  modify them.
• Inside/outside points can be modified.

BZWorkbench Development Specifics

Priority 1

• The entire user interface serves as a front-end to an internal, abstract data model.
• The 3D scene will be powered by a data broker–each unique
  mesh and texture will only exist in memory once, and each object in the
  scene will merely reference them.
• The 3D scene’s data broker serves as a front-end to the
  main data model, and is responsible for memory allocations specific to
  the 3D scene.
• The 3D scene will react in real-time to changes in the data model.
• The data model will have methods to read and write itself to storage in BZW 2.0 format.
• The data model will be able to provide a common interface for loading textures, meshes, and BZW objects, regardless of format.
• The data model can be queried and modified by the UI and the 3D scene via a common interface.
• The data model, in turn, is held by the program’s
  controller class, which is a subclass of Fl_Window that manages the
  data model’s memory, manages threads and message passing, manages
  start-up and shut-down sequences, etc.
• Think Model-View-Controller design paradigm.
• Both sets of UIs will pass their data to the data model as
  soon as the modification by the user is complete (i.e. the user clicks
  “OK”, or releases the selection in the 3D scene).
• The abstract data model and the UIs shall be developed in parallel such that there will always be a working product.

Priority 2

• Unit testing will be used to debug non-trivial algorithms. UnitTest++ will be the test suite of choice

DEVELOPMENT TIMELINE

(tentative)

• July 15th:
  By this point, the editor will be the world’s best BZFlag box-only editor. All the necessary 2D UIs will be in place for that to happen, and enough of the 3D UI should be done to allow users to make good box-only worlds. Once this is done, adding UIs and other objects should be easy because the infrastructure will be in place.
• August 31st: BZWorkbench 1.0 will be released. All priority 1 features will be implemented. I will probably work on additional features after GSoC completes, simply because I’ve had so much fun working with the BZFlag community

All materials subject to change without notice