Document id


Task-list for \greedworld prototype


Matevz Tadel

Document history

21.06.2008 — First version.

22.10.2008 — Update for the developments in solar-system integration.

19.01.2009 — Update for the developments in gravitational field and Dynamico movement (for both Crawlers and Flyers).

14.12.2009 — Describe briefely Spiritio classes under Unit movement on terrain.


Current implementation of \greedworld in \gled is at the stage of a medium-level, limited-scope, technology demo. While it was somehow possible to drag it all this way up single-handedly, it is impossible to continue the development without active engagement of several people. In particular, the core features of the existing framework need to be expanded and most of the higher-level features require further development. So, ideally, a developer would take over one of these features (or more) and at the same time partake in the design and extension of the underlaying framework.

In this document, focus is set on tasks related to rendering, world creation, world mechanics and user interaction — in short, to game-oriented aspects of \greedworld. Server-client data-separation and data-exchange are not on the table yet: \gled provides mechanisms for that and it's up to me to provide the first prototype. Nevertheless, some of the tasks described here require the server-client architecture to be specified and will thus also help in its clarification.

First, one posssible vision of the prototype is presented in a relatively short and dry manner. Its purpose is not to be a definitive guide, it's rather an attempt at helping the reader to get a feel for what could be achieved and to form his own vision, maybe entirely different from the presented one.

Next section is a catalogue of game/engine components, their current status and their possible extensions, described as ideas or as tasks, if the things seem relatively obvious. If you have another idea, or a specific interest in one of the fields described in \greed manifesto, you are more than welcome to come forward with it.

All of the described tasks require basic knowledge of C++, some understaning of the \root system and wilingness to learn \gled. The documentation for \gled is somewhat rudimentary (an implementation paper and a quick-start guide). But, for a one-developer project, writing documentation somewhat defies the purpose. If you want to get on-board in a specific area, I'll be glad to provide guidence and write the most sorely missing docs as my first priority. GNU/linux is currently the only supported platform. Windows and MacOSX support is planned.

A vision of \greedworld prototype

[ Read \greed manifesto, in particular description of \greed-words in section 2. ]

The \greedworld prototype is a minimal implementation of ideas presented in \greed manifesto. Focus is set on getting the things going, on building the base the will make the full, persistent \greed universe a more likely possibility.

This document will, I hope, serve as a basis for first discussions about how to really structure the prototype elements and how to get it done reasonably fast. Therefore, I will try to describe it as plainly as possible, defining a couple of terms that I found useful while thinking about \greedworld.

Anyway ... I'm beginning to realize that describing a game prototype requires some discipline. The problem is that one is at the same time trying to explain what happens within the game code and, simultaneously, how the game is seen by the user, how elements of the game are mapped via the user-interface, or, simply, how the games looks and feels. I will try to take the middle road, describing the game as a rule based system.

General description

On the highest level there is a set of solar systems. Each solar system is driven by a set of computers organized in a hierarhic server-client system. Travel between solar systems is possible but not common.

Solar systems are further populated with planets, moons, asteroids, comets and all that. Their surfaces will not be overly compex or structured, unless somebody walks in with an incredibly scalable terrain engine. Realistic solar-systems tend to be mostly empty - it seems reasonable to consider also less conventional celestial arrangements. The same holds also for movement and distribution of solar systems (Henon-Heiles potential with repulsive core).

Large colonization mother-ships are being flinged from Earth into these solar systems (say, by using Higgs-field inudced worm-holes or teleporters). Control and communication link between Earth and the ship remains open and a user can exercise control over the mother-ship, its sub-systems and units that it has on board.

  1. Energy generators, propulsion systems with basic hyperdrive capabilites.

  2. Basic resource processing, resource routing and fabrication stations.

  3. Some planetary landers / transporters.

  4. Some exploration vessels and vehicles.

  5. Some land / space construction units.

With this starting-kit a player engages in exploration of surrounding space to discover natural resources that are distributed throughout space but normally clustered near solar and planetary bodies. They represent the intrinsic value of some region of space and determine its strategic importance. A resource is anything that can be converted into something useful, e.g., hydrogen, carbon, oxygen, water, methane, silicon, uranium, various ores, bio-matter, etc. When location of the resources is known, player sends out construction units to build resource acquisition infrastructure.

  1. Resource extraction units, like mining bots, scoopers and harvesters, operate in some resource-rich region and perform the first stage of separation of resources from the environment.

  2. Resource processing plants process and purify raw resources and convert them into juiceware — a common term for raw materials, chemicals and fuels. Each plant can handle several inputs and outputs at the same time but is limited with the combined throughput.

  3. Resource depots. Can be part of a processing plant, a separate unit or part of a larger unit, like mother-ship. Each depot has certain capacity.

Processing plants are connected to their inputs and outputs via matter transfer links - quantum devices allowing cheap teleportative streaming of homogeneous media at short distances.

Juiceware is consumed for further construction and for fabrication of derived goods.

  1. Infrastructure — mines, processing plants, factories, teleportation/routing stations, orbital stations — built by construction units.

  2. Techware — engines, vehicles, space-ships, equipment and devices — built in fabrication plants.

Construction and fabrication will in principle require blueprints (but let us drop this from the prototype).

Construction units and fabrication plants are connected with processing plants and depots via matter and energy transfer links.

The acquired resources, raw-materials and goods can be used for support or extension of existing infrastructure or for further exploration and colonization.

In \greed manifesto there is a lot of talk about simulation of human population and the role of NPC specialists in R&D activities of a colony. I decided to completely drop this aspect from the prototype: there are no humans on the other side, it is just technology, automatons and robots. All R&D activities are assumed to take place in the real world and the results are sent to the colonies via their communication links.

Juiceware, where it comes from and where it goes

  1. Hydrogen

    Sources: scooping of stars and gas-giants, electrolysis of water, bio-production.

    Consumers: fusion reactors.

  2. Uranium

    Sources: mining of planets, moons, and asteroids.

    Consumers: fission reactors.

  3. Metal

    Sources: mining.

    Consumers: building units for all construction, fabrication plants for production of most techware.

  4. Rare metal

    Sources: mining.

    Consumers: fabrication plants for production of fancier stuff, like electronic equipment and quantum devices.

  5. Super-heavy elements

    Sources: processing plant equipped with a low-energy particle accelerator, requires also uranium and rare metal.

    Consumers: operation of gravity-manipulation devices and hyper-drive engines.

  6. Energy

    Sources: fusion plant (requires hydrogen), fission plant (requires uranium).

    Consumers: everything that does something.

Resource and juicware processing

Processing plants take as input natural resources and juiceware and produce juicware as output.

Juiceware quantities are determined by mass and by volume (gasses) or by density (liquids and solids).

  1. Resource extraction units and buildings:

    1. Maximum extraction speed per juice.

    2. Maximum output bandwith.

    3. Range of extraction per juice.

  2. Processing plants:

    1. Number of input/output matter transfer links, their spatial range and bandwidth.

    2. Capacity of internal depots.

    3. Maximum output bandwidth for each juice.

  3. Depots:

    1. Capacity per juice type.

Each matter transfer link connects a processing plant with one unit or depot and allows transfer of a single resource or juice.

User controls:

  1. connections to acquisition units and depots

  2. ongoing process and their priorities

Fabrication plants

Products of fabrication are actual objects, determined by number, mass and volume.

Fabrication plant characteristics:

  1. Juiceware input bandwidth — determines production speed.

  2. Number of production lines.

  3. Installed/available blueprints.

User controls production-lines, assigning the active blueprint to each of them.

Comm device

Quantum communication device — q-comm device — is a fictitious interface between a user and its units. Initially, a single q-comm device is available, integrated with the mother ship, allowing control over all units and facilities.

Additional q-comm devices can be built and assigned to any number of units. The q-comm link access can then be granted to another user, thus allowing unit-sharing, delegation of tasks and cooperation.

This should be relatively expensive, maybe even requiring a monthly research credits fee.


Stuff that moves around and does something.

Characteristics of all units

  1. maximum speed / acceleration

  2. range and bandwidth of matter / energy transfer links

  3. internal storage / depots

  4. shield / health status, or something like this

  5. some sort of weapon

Unit separation by task

  1. exploration units — detection range per juice

  2. resource-extraction units — discussed under Resource and juicware processing.

  3. transport units — nothing special, but have large depot capacity

  4. construction units — construction speed

  5. military units — additional weapons, shields

Unit sepratation by medium where they operate

  1. land units — max terrain tilt

  2. space units — propulsion system, warp capability

Control of units

  1. Direct control — manipulate unit directly, giving it commands where to go and what to do. For some units, like space-ships and tanks, this could also mean operating the engines and control systems in first-person view.

  2. Task control — manipulate some semi-intelligent control agent that further steers the unit. The agent is typically given a task and region on which this task should be pursued. One agent can control several units.


Mega-units can encompass processing plants, fabrication plants and depots. Other units and techware can be stationed inside. Usually that would be a space-station, a large space-ship (like mother-ship) or a military installation.

Buildings and units within a mega-unit are simulated independently.

Each mega-unit has a hull, an arbitrary mesh defining the extent of the unit. Either side of the hull can be used for placement of buildings and smaller units can be placed there to crawl about.

Central energy bus is embedded in the hull and structure of a mega-unit. Energy-bus is a fictitous device that allows free energy transfer between hosted facilities and units. So, one could imagine, that fusion and fission reactors are connected as energy producers in the center of the structure and processing plants, fabrication plants, warp engines and shield devices are connected as consumers.

Research and development

As said earlier, this aspect of the game will not make it into the prototype. But this would be the gist of any persistent world, so let us investigate the possibilities just a little. In short, the role of R&D is to improve existing processes and blueprints as well as to invent new technologies and products. Let us introduce four categories of such activities:

  1. Basic research - leads to discovery of new scineces and technologies including fusion among previously unrelated sciences and technologies.

  2. Applicative research - improvement of existing technologies and creation of conceptual designs.

  3. Engineering research - using technologies to produce or improve blueprints, thus improving the overall capabilities of techware.

  4. Engineering practice - using blueprints to build techware as well as to upgrade and fix existing one.

Points 3. and 4. from the above list could be trivially simulated with research credit spending by the player, without the need of introducing humans into the other side of the game.

Conclusion of prototype vision

Well, this degraded a little, but I really prefer to write code than English text about non-existing code. The intention here was to structure the problem space and say how the prototype could function and be at least somewhat engaging. Feel free to fill the gaps to your liking and to expand the proto-ideas described here. And let me know ...

Current status of code and possible tasks

The topics in this section deal with subsystems and components of the game engine and with algorithms for world creation. Some of these issues overlap or depend on one another. Also, the descriptions are relatively terse — I can provide more details if somebody is interested.

See [Tadel-GledIHSCM] — this is an overview / implementation paper about \gled.

\gled crash course

This should help with relating the tasks to existing code.

  1. \gled is, essentially, an object management framework. Classes of these objects can be divided, by the role they play in \gled, into the following categories:

    1. Glasses — classes of objects that can be shared throughout a \gled cluster and execute \gled method-invocation requests (MIR, \gled's RPC). They can be put into containers and be pointed to by other objects via links (glass-members that serve as smart-pointers).

      Base-class for all glasses is ZGlass. Instances of glasses are called lenses.

      Dictionaries are generated for glasses, so you can call their methods via the interpreter and run CINT macros for their creation and configuraton.

    2. Stones — classes of serializable objects with dictionaries (if you know ROOT: stones are derived from TObject) and usually serve as data containers. They can be glass data-members or appear as arguments in glass member-functions.

    3. Views — classes of objects that represent a lens in some way, their abstract base class is A_View. There are two main sub-types of views:

      1. Classes using FLTK widgets — browsers and containers are handwritten, object-view elements are auto-generated.

      2. GL-rendering classes — handwritten, optional (classes can use base-class renderers).

  2. \gled modules are called libsets. Each libset is composed of three shared libraries: base (Glasses/, Stones/, dictionaries + any other stuff central to libset functionality), GUI (Views/) and GL renderers (Rnr/GL/). Base classes of \gled and the implementation of \gled itself is in libset GledCore. \greedworld demo is mostly implemented in libset Var1 and requires the following libsets: Geom1 (geometric primitive classes), GTS (interface to GNU Triangulated Surfaces library), Numerica (interface to numerical algorithms) and Audio1 (interface to OpenAL, not yet used). All libsets require GledCore.

Class names are given in the following notation:


That's also where they are in the source-tree (usually, sometimes several classes share the same file).



\gled has a relatively flexible high-level rendering infrastructure. Initial goal was to support both OpenGL and POVRay rendering but so far only GL sub-infrastructure has been implemented. Object hierarchy is mapped automatically into a parallel structure of object renderers. Rendering classes have to be written manually. Arbitrary state-objects can be attached into the renderer graph — rendering classes can query this state and act accordingly. This gives the rendering process a very large degree of flexibility and configurability. Object picking is implemented via GL-selection. Overlay rendering and overlay event-handling is supported.

However, \gled's renderer-graph is not a scene-graph. Nodes do not have any bounding-box information and the renderer graph is blindly traversed during each draw-operation.

One option out of this is to import an external scene-graph/rendering library into the \gled rendering pipeline. Thus \gled would offer the high-level rendering support and low-level rendering of the game objects would be performed by an optimized scene-graph library.


  1. Add bounding-box information into \gled classes and use it during rendering to perform view-frustum culling and, on request, LOD calculations. See [Moller-OVFCA].

  2. Consinder existing scene-graph and rendering engines (like SauerBratten, G3D, OpenSceneGraph, Ogre3D, Blender) and open-source projects (like Celestia, TA-Spring and FlightGear). Try to answer the following questions:

    What do they have that we need?

    Can we use their code? How hard would it be? Can it be snateched out or needs to be integrated into \gled or into \greedworld client?

    Shall we try to join forces with them in some aspect or another?



Terrain is represented as a triangle mesh. The functionality of terrain code is spread over several classes.


  1. Should we use some other mesh representation? I recently read [Eberly-3DGED] that using per vertex grouping makes more sense lately. But then again, I kind of like flat shading.

  2. Usage of VBOs and shaders for terrain/mesh rendering. Now GL-1.4 stuff is used.

  3. Import from other formats. Which? I have code for MD2, Total Anihillation and 3DS (no textures).

  4. Implement gravitational potentials for all supported parametric surfaces.

    19.1.2009 Done ... ParaSurfs can fill GravData stone that includes the derivatives in 'up' and transverse direction. Dynamico can deduce safe time and safe distance. See:

      virtual void update_grav_safeties(Float_t vl, Float_t vt);

    in Dynamico.

  5. Implement field-on-mesh optimized for fields that are mostly zero (e.g., as gaussian-blobs at specified vertices).

  6. Consider recursive terrain subdivision — this is a big one and there are several issues.

End of terrain

In principle, we could roughly get by with what we already have. But if somebody is into such stuff, miracles can be done.

Unit movement on terrain


Crawlers (objects of glass Crawler) slide over terrain with given forward velocity, angular velocity around unit's up-vector and levitation height above the terrain (like hovercrafts). At each time step the triangle below the center of the unit's mesh is found and unit's up direction is aligned with the triangle's normal. There is no check for edges/corners of the dyno penetrating the terrain so this happens on transitions between triangles that have significantly different normal vectors.

Collision with statos (static objects, buildings) is implemented in

 static bool Dynamico::handle_collision(Dynamico*, Statico*, ...)

The unit is bounced-off if it is still getting closer to the center of the stato, otherwise it is deflected.

Dyno-dyno collision is done in

  static bool Dynamico::handle_collision(Dynamico*, Dynamico*, ...)

If the units are coming closer, they are elastically scattered with conservation of energy and momentum in horizontal plane. If they are going apart, they are just displaced to avoid further contact.


  1. Implement some kind of unit health status and decrease it when the unit collides. Show health-bar for units. Draw special effects like smoke, fire, explosions, etc.

  2. Improve terrain contact implementation, use several points of contact.

  3. Use proper rigid-body mechanics for unit movement with forces and torques allowing lateral sliding of a unit on a steep terrain and jumping off elevated terrain edges. I was thinking of using geometric algebra for this task.

    This is somewhat done - velocity and angular velocity vectors are available so at least lateral slides would be trivial to implement.

  4. Collision prediction and collision evasion.

  5. Path finding.

  6. Unit steering in "go to somewhere" mode.

  7. Unit steering in "first person" or "drive" mode.

    14.12.2009 — This is somewhat done for Crawler's. See glasses Spiritio and CrawlerSpiritio and their GL renderers. The observer/commander camera movement is fed from TringuObserverSpiritio. The Spiritio classes combine unit control steering, key-handling and overlay/mouse interaction.

  8. Steering of a unit group in march, patrol, guard and attack modes.

Resource distribution and representation


In the demo we generate "energy" and "metal" fields that serve no other purpose than to colorize the terrain. A set of random gaussian blobs is generated and the fields are initialized by the sum of blob contributions.


  1. Consider abundance of individual resources and their distribution patterns. Prepare algorithms for random resource distribution that can be used in different circumstances, preferably steerable with a comprehensive set of parameters.

  2. Are mesh-fields really suitable? Use some sparse representation instead.

  3. Do some sort of balancing so that we know reasonable generation parameters for planets, moons and asteroids.

  4. Rendering of resources. Now a selected resource abundance is mapped to terrain color. Can we use (multi-)texturing or shaders for the job? Anyway ... if resources are sparse, the resource-rich regions are better defined and have few overlaps.

Entities for resource processing and enity production


There is nothing, well, there are buildings and we know how to animate their matter transfer links (tubes in the demo). And there are dynos that can crawl about.


  1. Implement units or devices for resource discovery and resource acquisition.

  2. Implement resource processing plants and depots.

  3. Implement fabrication plants.

Space representation - solar/galactic maps


Var1/Glasses/SolarSystem implements solar-system time propagation. The generation parameters are tweaked so as to make the solar-system unrealistically small, with large planets. The intention is to make inter-planetary travel much shorter and to make the planet-movement relevant in travel calculation. Planet-planet collisions are not handled.

See <demos/Var1/solar_system.C> script.

Some other relevant points:

  1. GledCore/Glasses/ZNode — a node in hierarchic object graph, holding grouping and geometry data.

  2. Numerica/Glasses/ODECrawler — an implementation of ODE integrator. It is used by the solar-system.

  3. ROOT has a limited interface to GSL (in package math/mathmore). But this is not used (yet) in \gled.


  1. Consider node hierarchy for describing a solar system with planets, moons and asteroids. Make it all move in time.

    The SolarSystem class runs in global coordinate system. The ZNodes should be attached to these points to allow for higher precision tracking of objects in local coordinate systems.

  2. Implement a "map view" for a solar system.

  3. Implement interface for trajectory plotting and calculation.

Semi-automatic generation of solar-systems


There is some basic stuff for generation of random terrains and planets.

The creation of planets (CosmicBall glass) is purely random and has few parameters (min/max orbit radius, eccentricity, inclination; min-max planet radius/mass).


  1. Prepare algorithms and parameters for generation of solar systems. It should be possible to regenrate whole solar-system from a relatively few parameters and random seeds.

  2. Try playing with non-realistic solar systems.

  3. Consolidate terrain generation algorithms.

  4. Support recursive / fractal sub-triangulation down to basic level.

Unit movement through space / air


A little done. Flyers in the demo follow the gravitational potential, keeping the energy intact. 'Up' direction is maintained when GravData is updated. This doesn't work too well in the regions where gravity is close to zero and can thus change direction significantly over a small distance (e.g.: center of a sphere or torus).

Space travel is not touched.

Atmosphere density is not available.


  1. Implement dynamics for movement of space units with engine trust and gravity. Prepare flight stabilization scheme that can handle sudden changes in direction of gravity (this is relevant for "small worlds").

  2. Think how to present this data to users. Think about spacepship controls in command-mode and in 1st-person-mode.

  3. Fake some kind of anti-grav unit and warp engine.

  4. Implement algorithms for entering into specific orbits.

  5. Think about landing / docking procedures.

User interaction layer


There are some GL-widgets: buttons, menus (using button hierarchy), valuators and list-views. Implemented using overlay event-handling.

In FLTK we have detailed object views and object browsers.


  1. Design the interaction hierarchy. Determine which parts of UI should be done with FLTK and which with GL. How to achieve interoperability between different elements?

  2. Implement controls and detailed views for specific unit and building types (processing plants, fabrication plants, exploration units).

  3. Think about switching between different views (1st person unit view, detailed entity view, planetary map, etc). How many views can there be in parallel? Blame deficiencies on the q-comm device throughput.


As you see, the number and extent of tasks in the list looks somewhat forbidding. It is obvious that the \greedworld prototype will not include all of these things, at least not in their full scope. People who join the project, their interests and capacity, will determine the direction of the actual development and the accent of the final outcome.



Eberly D.H., 3D Game Engine Design, 2nd edition.


Assarsson U. and Moller T., Optimized ViewFrustum Culling Algorithms, 1999, search web.


Tadel M., \gled — an Implementation of a Hierarchic Server—Client Model,


Terdiman P., OPCODE — Optimized Collision Detection library.