Difference between revisions of "LavishNav:Implementation Considerations"
Jump to navigation
Jump to search
| Line 19: | Line 19: | ||
* Translating collision data into navigation data | * Translating collision data into navigation data | ||
** Dealing with false positives and false negatives | ** Dealing with false positives and false negatives | ||
| + | * Uni-directional vs bi-directional | ||
== Alternate costs == | == Alternate costs == | ||
Revision as of 04:30, 20 December 2006
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 -- "waypoints"
- Fixed grids
- Free-form navigational meshes
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
