A high-performance, zero-allocation Java pathfinding library designed for extreme concurrency and low latency in demanding environments like Minecraft servers.
Pathetic is a Java pathfinding library engineered for extreme performance and scalability in high-concurrency environments like game servers. It solves the problem of slow, memory-intensive pathfinding by using zero-allocation data structures and optimized algorithms, enabling thousands of concurrent paths with minimal latency. The library is designed to outperform traditional Java pathfinding solutions by orders of magnitude.
Java developers building real-time applications requiring efficient pathfinding, such as Minecraft server modders, game developers, and anyone needing high-performance spatial navigation in concurrent systems.
Developers choose Pathetic for its unmatched speed and memory efficiency in high-load scenarios, leveraging hand-rolled primitives and compact encoding to eliminate GC pressure and reduce latency dramatically compared to conventional libraries.
The Java pathfinder that ended the era of “good enough”
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Uses hand-rolled primitive binary heaps and compact coordinate encoding to eliminate object allocations, drastically reducing GC pressure and improving cache locality, as benchmarks show 4.5x faster performance for 1k nodes.
Implements Bloom filters for O(1) closed-set lookups, accelerating node checking compared to traditional O(n) approaches and handling thousands of concurrent requests efficiently.
Runs multiple heuristics like Manhattan and Octile in parallel, allowing choice between linear accuracy or squared speed for optimal pathfinding in real-time scenarios.
Fully asynchronous and concurrent architecture avoids main-thread stalls, enabling seamless handling of high-load pathfinding without performance degradation.
Requires manual setup via lambdas for pathfinding logic (e.g., walking, swimming), which can be error-prone and overwhelming for developers seeking simplicity.
Focuses on A* with specific optimizations, lacking built-in alternatives like Dijkstra or Jump Point Search, which may restrict flexibility for diverse use cases.
The performance-focused codebase leads to frequent breaking changes and minimal backward compatibility, as seen with deprecated FibonacciHeap code in an 'archaeology' branch.