[Pogamut-list] understanding geometry, visible/hidden navpoint filtering

[cazub]

Re: understanding geometry, visible/hidden navpoint filtering

Author: cazub

Hey guys , i always had trouble with the isVisible functions,  I had that heatmap + visibility map thing i created. Visibility map is closer to jcothran's idea. I created it with brute force by respawning a specialized bot to every navpoint then exiting and serializing the visibilities to a file. The only problem was the visibility values were always wrong. Come to think of it i made an entirley new map object to use if anybody wants it. Basically just stored each navpoints 3d location, visibility (how many nodes could see this node) , visible nodes (what nodes it could see from this node) , Kill and Frag value (for heat maps) , and finally an interestValue. 

The interest value was based on my activation function. So for a camping bot i'd want to weight visibility as the main attribute and look for the lowest visibility, highest kill value and lowest frag value. Something like  intrestValue = ((2.0)*Visibility) + KillsAtThisPoint - FragsAtThisPoint. 

Creating that visibility matrix with raycasting would be great but i never had time to do it. Just used the non working isVisible(). But if anybody wants help making one of those data structures or needs to know how to use them i can help probably.  



> =Understanding geometry
> 
> Was experimenting some with 'camping' behavior - initially just manually setting a known location/orientation for the bot to go to and wait until seeing an enemy.
> 
> I'd like for the bot to be able to 'understand' the map geometry the same way a human player would and be able to use walls/corners for cover/attack, but bots are really very stupid and live in 'navland' (kind of like 'flatland' for bots).
> 
> The only initial approach that comes to mind for making the bot more geometry aware is to have a bot do an intensive raytracing-based learning approach to abstract out map features of interest to database table(s) (sqlitebot).  The raytracing tutorial mentions distinguishing a 'wall' from a 'hill' for instance, which might be the kind of geometry locational attributes logged for later tactical use.
> 
> So going with the raytracing map learning option, I was thinking of just have the bot essentially do a 360 degree scan of his surrounding from each of the map navpoints to try and start logging features of interest.  It seems like a very brute-force type of approach and I could imagine shortcuts using just the map geometry files themselves, but don't really have knowledge/hooks into that at this time.
> 
> =Visible/hidden navpoint filtering
> 
> Another function of interest(may already exist in some way ?) would be to have a filter function that would let a bot pick a navpoint or path that is outside of his or an enemy's current view.  In an evasive maneuver a bot should probably pick a strafeToLocation which is outside of his enemy's current view or in a flanking maneuver a bot would want to pick a navpoint behind his enemy with a navpoint path(shortest hidden path option?) that is also outside of his enemy's current view.
> 
> I haven't looked into the safeRunToLocation or astar pathing routines yet and I'm hoping that it won't be too difficult to effect or modify those functions to remove navpoints from consideration that are within an enemy(s) view(or possible predicted view).  Also hoping the computation won't be prohibitively slow.
> 
> Thanks
> Jeremy