sbj42 / wally-fov Goto Github PK

The algorithm should work just as well for player locations that are "in between" tile centers. For instance, a player at (1.25, 4) would be 25% of the way from (1, 4) to (2, 4). Their field of view could be computed as if they were at (1, 4), except that the shadow angles would be different.

This could be used for smooth transitions as the player moves from one tile to another.

Let's add support for maps whose coordinates span an arbitrary rectangle. So you could have a map on, for example, (-20,-20)-(20,20) or (10000, 5000)-(10030, 5030). Basically we just need to use a Rectangle in FieldOfViewMap instead of a Size.

A possible interface would be:

const map = new FieldOfViewMap(-100, -50, 100, 100); // (x, y, w, h)
// map now ranges from (-100, -50) to (-1, 49)
map.addBody(-10, -30);

This shouldn't hurt performance, but it would help users avoid needing to map their own coordinates into a (0,0)-origin map space. See discussion in #1

Adding a wall at the very edge of the map fails. For instance:

const fovMap = new FieldOfViewMap(2, 2);
fovMap.addWall(0, 0, geom.Direction.NORTH);
fovMap.getWall(0, 0, geom.Direction.NORTH); // <-- returns false

addWall() is avoiding putting an opposing wall out of bounds, but in doing so it fails to put the requested in-bounds wall.

Walls on the edge of the map aren't of much use to the field-of-view algorithm, but in case someone relies on FieldOfViewMap to save wall positions, it should still remember them.

Hi there. I know I'm the first to star your library, but I tried it out a bit last night in my project as a FoV calculation algorithm and found a modest bug:

Right now I've got a sample level stitched together from prefabs. I started from one room with 0, 0 as its upper left corner, and then just added new ones outside of it until I was happy with the level (this is a roguelike project I'm working on and haven't gotten world generation done yet).

The algorithm ran fine for awhile in my first room, but I found as soon as I went north and it needed to do calculations with the player's position being 4, -1 or whatever, the application would just hang indefinitely in WallyFOV code.

My fix was somewhat simple - in defining things to WallyFOV, I give it a small chunk of my world - a square equal to (ViewRadius * 2) + 1 in size, and I have the upper left corner of that square always be 0, 0, then I just offset tile addresses coming into and out of WallyFOV so that I can work around the negative positioning bug.

This is unlikely to be a problem for me again, but it was a modestly severe bug to encounter and might be worth fixing or failing with an error message instead of hanging.

On another note, I'm loving the library and appreciate the work you put into this as well as your two posts on the matter. This lets me shortcut some of the boring aspects of the project I'm not that interested in and get closer to the artificial intelligence aspects that are very appealing as well as just to get the thing closer to an actual prototype.

FieldOfViewMap.getBody(x, y) should return a boolean, but instead it returns a number. This doesn't affect regular JavaScript usage, but would be annoying with TypeScript.

The return statement needs !== 0.