WorldForge Tool Suite


These notes are the result of a WF Tool Suite discussion on 2001-10-11.

Participants: (order of appearance)

These meeting notes by zzorn.

Design principles

As suggested by Bryce (Stolen from "The Unix Philosophy" by Mike Gancarz):

  1. Minimize the size of each tool. The less each tool does, the better.
  2. Make each tool do just one thing, and do it well
  3. Build a prototype as soon as possible. Waste no time getting it up and running.
  4. Choose portability over efficiency.
  5. Store numerical data in flat ASCII files. There are tons of tools that we can use to manipulate text, but few for binaries. -- This would be XML Atlas files, most likely
  6. Maximize use of software libraries and reusable code modules. Tho see rule #1 and #2.
  7. Use shell scripting to glue small tools together. This might be done by the framework, in some way
  8. Avoid captive user interface. Don't limit the user to only doing things one way; allow them to operate the tools in a variety of unusual ways.
  9. Make every tool a filter. Well, it could be seen as a filter on an XML Atlas Object or similar.


Requirements of services and functionality that the tool suite should offer to the tools.


High level diagram of the tool suite, by Rykard.

Model-View-Controller architecture

Atlas Data (Model)

Edited objects are stored as atlas objects. The framework provides a wrapper class, that will take any Command class and make it a stand alone command line application, accepting an Atlas input stream and command line parameters or a configuration file, and producing an atlas output stream.

Commands (Business Logic)

Bryce suggested:

Imagine that each of your commands' API were simply to accept a stream of one or more objects in Atlas encoding, and emit perhaps modified Atlas encoded object streams. Using that API, suddenly you can start creating those commands right now, and later on can figure out all sorts of clever ways to hook them together. You might also want to include some kind of standard option specification layer so that you can automatically create the GUI front ends to allow specifying custom options. Sorta like how in UNIX they have a more or less standard convention for specifying commandline options (but more rigorous).

Tool Modules (Controllers)

Similarily to commands, there would be Tool UI Modules, that specify the user interface for editing a particular thing (items, blueprints, paintings, characters, creatures, skills, etc). The Tool Modules call needed commands as response to user actions.

Janus UI library (Views)

We could use Janus for the UI, this way the tools can be run on clients too. We need to add some widgets, though (3D editing widget, capable of displaying different objects, and a view to the game world could be made a widget too, used for map editing..).

Usage (from client or Main UI)

Tools can be invoked from the client, for editing in-game content, or from a Main UI, provided by the framework. The Main UI allows browsing of all objects in the local repository, and browsing all tools.. (it might just follow a document-command paradigm, and allow the user to select an object, and then tell what tools can be used to view or edit it).

Repository operations such as browsing a repository, uploading/downloading between a local and remote public repository, etc, could be in an own tool, and implemented as a number of different commands.

Next steps

The logical place to start is defining the structure of the editable Atlas object types. Items, Materials, and related things are currently best understood, and don't require any complex widgets (only different kind of parameter fields and lists). The Archetype Definition File format should be used for this (see archives).

Here's some lists of things to implement at different levels in the MVC architecture.





Tool Suite Framework

Content Repository