LavishNav:Implementation Considerations
Contents
Under construction
This article is kind of a stub, I'm working on filling it in. There's some bullet points for an overview of what will be described. The information here will NOT be application (e.g. game) specific, but may use examples based on a particular game.
Linear paths
Also known as a series of waypoints, this type of data defines a fixed path, rather than a dynamic navigation set. In terms of LavishNav, a path is defined as a series of connected regions. LavishNav provides the lnavpath LavishScript object type for this type of system, and are usually dynamically generated by selecting the shortest path from region A to region B. This does, however, represent the simplest form of navigation, and can of course be stored in LavishNav.
- Representing a linear path
- universe
- Start region
- Additional regions
- Finish region
For a linear path to work, each region must be connected from start to finish. A pure linear path is uni-directional, but may of course be bi-directional.
A roads can be considered a linear path, at least when it contains no forks. If the road contains a fork, multiple linear paths (consisting of the original road and the additional road or roads) are connected as a whole to form a mesh.
Fixed grids
Free-form meshes
All points valid
World layout
- Translating world layout into LavishNav universes
- Overlapping coordinate systems
- Layered navigation
2-D vs 3-D
Real-time Mapping
- Recording movement
- Data density
- Translating collision data into navigation data
- Dealing with false positives and false negatives
- Uni-directional vs bi-directional
Alternate costs
- Time versus distance
- Tolls, level/item/etc restrictions
Finding valid paths
- Point to point
- Point to many
- Avoiding dynamic objects
- Travelling salesman (shortest path, requiring a set of points be visited)
Movement systems (following paths)
- Real-time validation of navigation data
- Getting un-stuck
- Movement axes