Competition Domains

The competition was run with a series of domains, divided into three broad collections: transportation related domains, space-applications related domains and a collection of odds-and-ends. The first collection contained the domains called Depots, DriverLog and ZenoTravel, the second contained Satellite and Rovers and the third contained FreeCell, Settlers and UMTranslog-2. Apart from the third set, in each case a domain was represented by several variants, including STRIPS, numeric, simple-timed, timed and, in some cases, more complex problems (usually combining time and numbers in more interesting ways).

Simple-timed problems used durative actions in which durations were fixed for all instances of an action schema, being given as domain constants. Timed versions were more complex, since the durations could depend on problem-specific data. Only in more complex versions could the values on which these durations depended be fluents, since this requires of a planner the capability for managing both durative actions and numeric-valued fluents.

Variants of the domains changed the nature of the problems very significantly, so each domain variant can be seen as a separate domain in its own right. The following sections detail the domains we used in all their variations.

The Archive

The entire archive of domains and. problem sets used in the competition, together with the generators used to produce the problems, are available here. This archive is 17Mb. Generator executables are compiled for Linux (C++ source is also supplied). The domains are organised in a hierarchy of sub-directories. Within each domain variant sub-directory can be found the typed domain description and problem sets for automatic and for hand-coded planners. The untyped problems are identical sets, but without types.

A much smaller archive, containing scripts that allow the problems to be regenerated using the generators is available here. To use this, unpack it (gunzip and untar) and then, in IPC3, run the script "buildall" which will automatically invoke the makefiles to build the generators from source and then construct all the problem sets. This archive is only 150Kb, but requires you to have a C++ compiler, make and, to run the scripts, bash.

If you would like to get hold of the problem files in some other form, please contact us.


This domain was devised in order to see what would happen if two previously well-researched domains were joined together. These were the logistics and blocks domains. They are combined to form a domain in which trucks can transport crates around and then the crates must be stacked onto pallets at their destinations. The stacking is achieved using hoists, so the stacking problem is like a blocks-world problem with hands. Trucks can behave like "tables", since the pallets on which crates are stacked are limited.


This domain involves driving trucks around delivering packages between locations. The complication is that the trucks require drivers who must walk between trucks in order to drive them. The paths for walking and the roads for driving form different maps on the locations.


The final transportation domain involves transporting people around in planes, using different modes of movement: fast and slow. The key to this domain is that, where the expressive power of the numeric tracks is used, the fast movement consumes fuel faster than slow movement, making the search for a good quality plan (one using less fuel) much harder.


The first of the domains inspired by space-applications is a first step towards the "Ambitious Spacecraft" described by David Smith at AIPS'00. It involves planning and scheduling a collection of observation tasks between multiple satellites, each equipped in slightly different ways.


Inspired by planetary rovers problems, this domain requires that a collection of rovers navigate a planet surface, finding samples and communicating them back to a lander.


In order to confirm that STRIPS planning is still advancing, we chose this domain from IPC2. It is the familiar solitaire game found on many computers, involving moving cards from an initial tableau, constrained by tight restrictions, to achieve a final suit-sorted collection of stacks.


This one was for the numeric track and proved to be a very tough resource management domain. Several interesting issues in encoding arise as well as the subsequent problem of planning with the domain. In particular, resources can be combined to construct vehicles of various kinds. Since these vehicles are not available initially, this is an example of a problem in which new objects are created. PDDL does not conveniently support this concept at present, so it is necessary to name "potential" vehicles at the outset, which can be realised through construction. A very high degree of redundant symmetry exists between these "potential" vehicles, since it does not matter which vehicle names are actually used for the vehicles that are realised in a plan. Planners that begin by grounding all actions can be swamped by the large numbers of potential actions involving these potential vehicles, which could be realised as one of several different types of actual vehicles.

Plan quality is judged by a linear combination of labour use, pollution creation and resource consumption. There is scope for constructing very hard metrics that involve maximising housing construction subject to an increasing pollution penalty (say), to ensure that optimal plan quality is bounded.


This is a numeric domain, but was only used for the hand-coding planners in the competition. It is a large domain with 23 types of objects, 38 predicates, 24 functions and 38 action schemas. Plan quality was measured by plan length (both allowing for concurrent activity and also simply counting steps). More complex metrics would be possible.

Thanks go to Dan Wu for her great efforts in encoding this domain and writing the automatic problem generator for it.