jKılavuz

Pure Java

jKılavuz is written in pure Java. It does not use native libraries. Note 1.5 is the minimum JRE version for jKılavuz.

Small runtime footprint

The runtime jar is only ~120 kb.

No dependence on any 3D engine

jKılavuz runtime doesn't depend on any 3D engine. It uses only 2 classes from jPCT which is hidden by the API. To avoid classpath confusion, two runtime jars are supplied: one for jPCT and the other for non-jPCT users. As coordinates can be converted between any coordinate systems, you can use jKılavuz with any 3D engine. Note the default StepChecker implementation uses jPCT's collision detection system but it's only used during -offline- data generation step.

Automatic data generation

To collect pathfind data, jKılavuz flood fills over surface starting from a set of points on the ground. This way a kind of 2d grid in 3d space is created which can take us up or down slopes, across bridges and over and under overpasses. The process also takes care of jumping over obstacles and gaps. As a nice side effect flood filling also spots the locations on the map where the units aren't supposed to go.

Very compact runtime pathfind data

Flood fill process generates a massive amount of data which is necessary to properly represent your terrain. But later on this data is collapsed into a very compact form. For example the runtime pathfind data for the Quake level in demo is about ~200KB uncompressed.

Automatic sector and portal creation

Once the flood fill is completed, the created grid is analyzed and sectors and portals are created. A sector is rectangular region which is freely traversable: that is a unit can go in any direction in a sector. The process is fully automatized although users can intervene for special purposes. During sectorization several tricks are used to form nicely shaped sectors: i.e. to avoid long and thin sectors.

Fast A* based path finding

Path finding is performed between sectors and hence can be considered as a hierarchical approach. This makes it quite fast and efficient even for very large maps. Although hierarchical approaches can not always guarantee optimality you will find the results quite sufficient.

Arbitrary geometry support

Almost all kind of geometry is supported. Multi floor buildings, bridges, tunnels etc are automatically supported. There are a few problematic geometries but they do not actually break flood filling. Troubles may only arise finding out the sector your unit is in. If you on your own keep track of sectors your unit is in then you are safe with all kind of geometry.

Flood fill process is pluggable

The FloodFill class only organizes the flood fill process. Actual reachability checks is delegated to an interface called StepChecker. FloodFill decides which direction to check and also makes sure values are in proper range. jKılavuz provides a default implementation of StepChecker depending on jPCT's collision detection system but one can easily plug his own collision detection engine.

No special exporters or pre-processing

No need to place markers where the unit can fall down, jump up etc. For the default jPCT based StepChecker implementation you can load your terrains in 3DS, OBJ and ASC formats. jPCT also provides necessary methods to create geometry in runtime which means you can even write your own loader. If you supply your own StepChecker implementation load the terrain with whatever tool you prefer. Of course either way you need a way to define your starting points.

Custom portals

Custom portals can be defined for elevators, teleporters etc. During path execution the runtime uses factory interfaces to create relevant path segments for such portals. This way one can plug in actions like going somehere and calling the elevator by pressing a button.

A clean and uniform PathIterator interface

jKılavuz defines an interface called PathIterator which can iterate over paths over time. It is suitable for both fixed and delta time approaches. jKılavuz can create both linear and curved paths. Paths can be merged and customized in certain ways. Users can still create their own executable paths by using Lego like path segments.

Feedback to animation system

The PathIterator provides a minimalist information about the animation the unit should perform. The idea here is to keep the animation and movement synchronized. Other way it would be hard to decide animation solely depending on the position on the path. This approach also allows inserting proper animation for custom portals: opening a door for example.