WorldForge Tool Suite

Discussions

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

Participants: (order of appearance)

Rykard
zzorn
bryce
Grimicus

These meeting notes by zzorn.

Design principles

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

Minimize the size of each tool. The less each tool does, the better.
Make each tool do just one thing, and do it well
Build a prototype as soon as possible. Waste no time getting it up and running.
Choose portability over efficiency.
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
Maximize use of software libraries and reusable code modules. Tho see rule #1 and #2.
Use shell scripting to glue small tools together. This might be done by the framework, in some way
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.
Make every tool a filter. Well, it could be seen as a filter on an XML Atlas Object or similar.

Requirements

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

[Important] Saving content objects to a local, (~~remote/local server~~ <- This is handled from inside the server, it shouldn't be possible to save directly), or remote public content repository.
[Nice] Version control of saved content objects. Local repository creates new version at every save, public repository at every upload. Save diffs instead of whole versions to save space, optionally remove old stuff (older than X months/etc).
Platform independent GUI
Possibility to run some/all tools from a game client
...
..

Diagram

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.

Datatypes

Items
Materials

Commands

Edit. Changes the fields with the given names to the given values
New. Creates a new instance of an archetype (how to specify what archetype? Pass an archetype definition file?)
Delete. Delete the atlas object. (from the content repository?? from where?)
Save. Saves to local content repository, overwriting anything with the same name(ask first??)
Load. Loads the object(s) given as parameters, (or as names on input stream??) from the local content repository.

Tools

Material editor. Allows editing the properties of materials, and possibly previewing material textures. Also allows viewing and mass editing of all materials in the local content repository.
Item editor. Allows editing item properties, and possibly previewing items (using different materials). Also allows viewing and mass editing of all items in the local content repository.

Views

Janus. Should allow UIs with property editor style editors, editing various property types using various bounds, and showing items of some material, using different views?
Some alternative that can be used outside clients, for example GTK or Gnome implementation of Janus.

Tool Suite Framework

Framework for object type editors. View all object types of that category, mass edit, etc.
Framework for object instance editors. For embedding into clients. Edit an instance, often an information object. Mass editing could still be used from admin account perhaps? doues it make sense?
Main UI. For browsing different types of items, mass editing/manipulating, uploading downloading to public repository, and opening different tools.

Content Repository

Stores Atlas objects. Define the interface, create a simple file based one without version control.