Difference between revisions of "LavishNav:Implementation Considerations"
Jump to navigation
Jump to search
| Line 27: | Line 27: | ||
* Point to point | * Point to point | ||
* Point to many | * Point to many | ||
| + | * Avoiding dynamic objects | ||
| + | * Travelling salesman (shortest path, requiring a set of points be visited) | ||
== Movement systems (following paths) == | == Movement systems (following paths) == | ||
Revision as of 04:29, 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
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
