travel path calculation

For AI and campaign script related discussions and questions
Chojun
Regular
Regular
Posts: 518
Joined: 25 Nov 2006, 17:49

Re: travel path calculation

Post by Chojun »

Agreed - WZ doesn't need larger maps. Ground units are slow enough as they are, and to make them travel larger distances would only serve to increase game lengths which is already a problem.

Larger maps would also only serve to increase the use of mass VTOL swarms as well.

WZ is supposed to be a game that encourages a wide array of tactics and strategies (but doesn't - irony), and doing things to work against that (like making maps bigger) isn't a good idea.
User avatar
NoQ
Special
Special
Posts: 6226
Joined: 24 Dec 2009, 11:35
Location: /var/zone

Re: travel path calculation

Post by NoQ »

but doesn't - irony
I think it does. When i stopped playing tasteless maps with tasteless rules, i found a much wider array of different tactics and strategies :)

I'm going offtopic though, sorry :oops:
User avatar
Goth Zagog-Thou
Regular
Regular
Posts: 1582
Joined: 06 Jan 2007, 08:08
Location: Delta Base

Re: travel path calculation

Post by Goth Zagog-Thou »

Yep .. chalk it up to one (more) feature in Warzone that I want that will probably never happen... like having all tilesets available to a single map at all times...

I really need to finish Cam 4 and bury my head into the source code for a year.. ;)
User avatar
Project
Trained
Trained
Posts: 32
Joined: 21 Oct 2010, 19:32

Re: travel path calculation

Post by Project »

Having a function like getTravelDistance() for real-world droid movement would make AI scripts way more reliable. Maybe adding pathfinding mechanics similar to droidCanReach() could do the trick.
Last edited by pastdue on 22 Jan 2025, 03:22, edited 1 time in total.
Reason: Remove advertisement
wanjia1
Trained
Trained
Posts: 63
Joined: 01 Nov 2023, 06:05

Re: travel path calculation

Post by wanjia1 »

Optimized pure javascript pathfind (uniform cost, 4 neighbors)
getTravelDistance.js
Have option for hover or structure blockage
Have cache for searched positions

previous version 1: 800k tiles/s, was miscalculated as 200k tiles/s
previous version 2: 1.1M tiles/s
previous version 3: 1.1M~1.5M tiles/s
previous version 4: 1.2M~1.6M tiles/s, 1.9M tiles/s when don't consider structure
Search rate (wheeled, consider structure) on 3 GHz CPU:
1.2M tiles/s (obstacle>3%)
1.6M tiles/s (obstacle<3%, or >100 calls/s)
1.9M tiles/s (obstacle<0.5%, or >1000 calls/s)
Search rate (wheeled, don't consider structure) on 3 GHz CPU:
2.1M tiles/s (obstacle>3%)
2.6M tiles/s (obstacle<3%, or >100 calls/s)

Search rate on "Sk-FishNets", base to base pathfind:
210 rounds/s (wheeled, consider structure)
192 rounds/s (hover, consider structure)
385 rounds/s (wheeled, don't consider structure)
303 rounds/s (hover, don't consider structure)

Travel distance and max time (wheeled, consider structure, if not cached):
10 tiles, 0.15ms
18 tiles, 0.4ms
26 tiles, 1.1ms
74 tiles, 10ms
142 tiles, 50ms

It will return wrong value / undefined, or throw a error if position outside map!
All of positions can be float (floored before inner calculation)
bugfix(v4): use cache when pathfind to unreachable tiles (850ms -> 60ms per 100000 call)
optimize(v5): faster Floodfill.pathTo (425k tiles/s -> 2.1M tiles/s)

Simple method, Not cached:

Code: Select all

getTravelDistance(x,y,x2,y2,"wheeled01",true)//0.85~1.1ms
Cached method:

Code: Select all

var a=new Floodfill(x,y,false,true)
a.distTo(x2,y2)//Need search, 0.85~1.1ms
a.distTo(x3,y3)//Cached, 0.2~0.3us
Get travel path:

Code: Select all

var a=new Floodfill(x,y,false,true)
a.pathTo(x2,y2)//Need search, 0.9~1.2ms
a.pathTo(x3,y3)//Cached, 10~12us
Screenshots (marked by hackMarkTiles):
getTravelDistance.jpg
getTravelDistance2.jpg
You do not have the required permissions to view the files attached to this post.