Dime Tasks and Project Plan


Contains the list of features to be implemented for Dime divided up into suitably sized tasks, and with notes of which ones should be implemented in the current iteration. Focus is on features to be implemented in release two (version 0.2.0).

We will work towards release two in many iterations, each about a month long, and each increasing the minor version number (0.1.1, 0.1.2, etc).

Also contains some project metrics.



Version is the version of dime a feature should go in. Version numbers consist of <major_release.release.iteration>.


Priority goes from 0 to 10, where 0 = we don't want it, 3 = extra, could be nice, 5 = optional, 7 = important, 9 = really needed, 10 = fundamentally required. Since the priorities have to be seen always in conjunction with the version the features are planned for, they have a global meaning. To derive the current priority of a feature, look on the set of features the programmer is also working on and the versions they are planned for.


Effort is measured in ideal working days, that is, the number of days it would take if you could concentrate on it 8 hours a day (this is later multiplied by a Load Factor calculated from project metrics to estimate the actual number of days). 4 or 5 is a good number, 1 or 2 might be a bit too small, and 8 or above means that the feature should be split into smaller ones.

Effort should be estimated by the developers actually doing the implementation, if it is estimated by someone else it is suffixed by a question mark. Like the priority the effort is a global and constant measure and not the effort left on the implementation. If a major change on a feature has to be taken after it is done, a new feature should be introduced (to see which part of it is already implemented).


The entries of the table should be sorted by version, then by priority and then unassigned features first. If a task has no version assigned, then it is listed after ones wih assigned versions.


Task Version Priority Effort Developer 1 Developer 2 Progress Description
Iteration 0.1.0 - Completed
... 0.1.0 Done Various unlisted tasks.
LoggingService 0.1.0 4 3 Tim Done Allows logging to a specified file or output stream.
Iteration 0.1.1 - Completed
InputService 0.1.1 8 6 Tim Done Polls SDL input events, sends updates to listeners
Use Cases and UI drafts 0.1.1 6 5 nullstar Acorn completed, mason and other games to be split into separate tasks.

Create a number of usage scenarios and user interface configurations, that different kind of dime users might want. This serves as a guide to what types of components we will need, and what services we need to support them.

The use cases can be simple stories telling what the user does and what happens, and the UI sketches can be drawn in a paint program, or a presentation or spreadsheet program. The UI sketches should have accompanying notes that describe the behaviour and content of various widgets and groups of widgets.

The use cases should be centered on Mason and Acorn play, although some others could be created too (of other types of games, or other applications that Dime would seem suitable for) to give some idea of possible future developement, and perhaps inspiration for new solutions to current components too.

See Task: Designing example interface layouts for Dime. for a more detailed task description.
Iteration 0.1.2 - Completed
ConfigService ? 8.5 2 nullstar Started by derwiath. Currently done but not yet used. Uses varconf for handling the config files. See this discussion about ConfigService for more information.
GuiService 0.1.2 8 7 adamgreg Nikal Nearly Halfway Implementing a simple GUI interface. See this discussion on GUI requirements for more background.
Component and GameView base classes 0.1.2 8 2 Partly done. Not much to do, only Widget *getUi() method and DataModel *getDataModel() methods for Component, and things like getName(). Might have to wait until DataModel and GuiService are ready, or alternatively use some stubs.
MetaServerService 0.1.2 7 4? (Aglanor) Xmp Done Queries metaserver
PlatformService - RectangleRenderer ? 7 5 Winand Done for SDL

RectangleRenderer is a class used to render ractangles that can consist of many sections that are bittmapped (tiled, stretched etc) or have gradients or solid colors. It's used for themed panel, button, and other widget backgrounds. There'll be a BorderRenderer too probably that can be used to render a border around some rectangular area.

There's an in depth discussion about the subject here . There's some example pictures also: background1, background2, background3.

It is part of the platform independet layer that the GuiService is built on. It should work with both OpenGL and SDL, although an initial implementation could be SDL only. It could have a portable base class and inheriting implementations that do the actual work on OpenGL or SDL.
PlatformService - BorderRenderer 0.1.2 7 3? Uses eight RectangleRendereres to render a border Portable base class and inheriting implementations that do the actual work on OpenGL or SDL.
PlatformService - Core & Factory classes 0.1.2 7 5? Init routines and any needed core classes for the the platform service. Factory for creating *Renderer classes depending on wether OpenGL or SDL is used.
PlatformService - FontRenderer 0.1.2 7 4? Nikal Done, a little polishing needed. Draw fonts with different color, size, etc. Portable base class and inheriting implementations that do the actual work on OpenGL or SDL.
Example Component ? 6 4? For testing and teaching purposes
Theme Format 0.1.2 7 5 zzorn Skyhook Complete

Create theme format DTD and documentation.

There's existing format proposals/drafts by zzorn and Skyhook.
Iteration 0.1.3 - No date yet set for completion
3DGameView - Terrain rendering 0.1.3 9 8? tbp Being worked on, yet to be integrated with rest of Dime Rendering 3D terrain for the 3D game view(s).

See this discussion on 3D game views for more background.

Example Theme(s) 0.1.3 6 6 ? Example themes for testing theme support in ThemeService, PlatformService, and GuiService, to create pretty screen shots and optionally a good default theme.
ServerService 0.1.3 8 5? Xmp Started Keeps list of services and known facts about them, initializes connection
Data Model 0.1.3 8 7 Tim Done
ThemeService - Core classes 0.1.3 6 3? The ThemeService class and any other needed core classes.
ThemeService - Theme 0.1.3 6 3? A Theme class to hold various theme information. Contains a set of ThemeSchemes.
ThemeService - ThemeScheme 0.1.3 6 3? Holds theme details for some named widget type. Will be passed to and used by RectangleRenderer and the other renderer classes.
Platform Service - OpenGL support 0.1.3 Nikal Partially done Add support to render the widgets on an OpenGL drawing surface.
SoundService ? 7 5? nikal Researching Plays sound effects.
MusicService ? 6 5? nikal Researching Plays background music. The music can be in MOD formats or ogg format.

Support for mood based music selection would be nice (if mods are set up in a suitable way, we can do this very quickly with them, by switching tracks, or changing the next track. For ogg, however, we have to wait until a piece is finished before picking another that fits the current mood). (At a later date support for experimental generated music could be implemented, it could react directly to changes in the mood). See Current mood in the game, and what it can be used for for a discussion about a mood system in the client, and some implementation ideas.

The mood is provided from outside this service (perhaps some read only fields in the central data model). It could be sent from the server if the current game / server supports moods, or calculated by the client based on events and some heuristics.

Unscheduled tasks
Design Control Interface protocol ? 7 5 cyanide zzorn

Design an extension to the Atlas protocol, or a protocol on top of it, that is used to communicate what an Avatar can do, what properties it has, what sensory stream(s) it provides, what control interfaces it is using, and metadata for all of those and the control interface itself.

Also create a sensory input stream concept, and device a way to associate sights and other perceptions of the world to one sensory stream.

Present the protocol to the rest of WF for acceptance, rejection, or corrections.

See recent mason bookmark for an in depth description and discussion of this.

3DGameView ? 9 30? tbp Terrain renderer being worked on, yet to be integrated with rest of Dime

A 3D game view. Uses existing libraries or code such as Demeter, Cal3D, and OpenSceneGraph, or some other ones.

Should be broken down into smaller tasks. For example:

  • scene,
  • terrain [separated task],
  • indoor (houses are built from elements),
  • entities (static mesh models),
  • character models (animated, bone based),
  • skybox (clouds, weather, etc),
  • static entities on the terrain (forests, trees, stones, etc.),
  • underground (different from indoor in that the server probably tells about the spaces, instead of listing a set of elements that confine a space fully or partially. But in any case it will not be needed until much later games, so should be left out until then).
See this discussion on 3D game views for more background.

MapService ? 8 8? Wrappers for Coal? Provides terrain height and terrain type information. Might also list visible static entities on the map, such as trees and stones.
Interface Layout file format / object structure ? 8 4? Define a file format that describes the layout of components and scripts with visible ui:s, and the connections from them to other visible or invisible component or script instances, and the central data model. Look at using the persistance service for loading and saving, and just defining the object structure that is fed to the persistence service when saving an interface layout.
Interface Layout loading and saving ? 8 6? Create a service that can load interface layout files into a specific part of the UI (a panel or so?), or replacing the whole current UI. It creates component and script instances, sets up connections, etc. Similarily, it should be able to take the whole (or a part??) of the current UI, and write it into a interface layout format. It could perhaps use the persistence service for saving/loading the data.
Identify needed Components ? 8 6?

Based on the use cases and UI drafts, identify a set of components, and create tasks in this list for them. A component should be generic and configurable enough to be used for many different purposes, but also self contained, easy to use, and have good defaults. More complex structures can be built with scripts or interface layouts.

Components use the basic widgets provided by the GuiService to build their UI:s, if they have one. Some components could be specialized at some non-visible tasks, that need to be accessible from scripts (and thus can't be placed in services), and don't make sense to access through the central data model.

Start with a small basic set of components that can be used to implement a simple interface for playing Acorn, for example, and then add more components later based on feedback from the usage of the previous ones.

Main dime application updates ? 7 2? Make sure it compiles, add test code for creating test components.
Service & Service startup ? 7 3? Clean up and do refactoring on the Service classes, make sure the client initializes the services on startup, and log / print startup status messages for services.
DebugGameView 0.1.1 6 3 AlistairD ? text based
IsoGameView ? 6 6? AlistairD 2D isometric
Update the Test Service ? 6 2? For testing and teaching purposes. Tidy up, add test for any new service interfaces.
EntityService ? 6 5? Handles Eris instances
MediaService ? 6 7? Lee Starting Muse implemented as separate library, MediaService wraps it.
InputService - Joystick Support ? 5 4? Add reading of joystic input to the input service.
PersistenceService ? 5 6? It is not currently clear if we need this. Config service might be used in many cases instead of it. Stores large amounts of structured data persistently for services. See this discussion about PersistenceService for more information
AtlasService ? 3 5? Listening to various atlas messages?
MoriaGameView ? 3 5? AlistairD Moria like


This is a list of the iterations, their planned and actual lengths, the effort planned and actually done in them, and a load factor calculated from these values.
Iteration Plan. End Date Act. End Date Plan. Length Act. Length Plan. tasks Act. tasks Plan. Effort Act. Effort Plan. max effort for a person Est. len. persons Load Factor
0.1.0 - 2002-02-16 - - - ? - ? - - ~5 4 (estimated)
0.1.1 2002-03-16 2002-03-17 28 29 7 2 32 11 7 28 days 8
0.1.2 2002-04-17 27 18 81 10 9
0.1.3 Not set.
(Effort measured in ideal work days.)

Change History

Date Author Change
2002-07-05 Xmp Another update.
2002-05-25 Xmp Updated things as a result of the 0.1.2 release. Moved several tasks to the 0.1.3 revision because of the reality of the matter.
2002-03-17 zzorn Updated things as a result of iteration planning for 0.1.2
2002-02-16 zzorn Calculated features to be implemented for iteration 0.1.1
2002-03-15 zzorn Added RectangleRenderer
2002-02-16 zzorn Added updates from project meeting
2002-02-13 AlistairD Tinkered with priority and effort for his areas, corrected ErisService's description.
2002-02-12 Tim Fixed priority and effort to a global meaning.
2002-02-12 zzorn Changed priority and effort to numerical bounded estimates.
2002-02-11 zzorn first version