First of all some concepts:
- - a 'space' can be either a grid cell or a single pixel; the same rules apply to any space but what constitutes a 'space' depends on the grid type and whether 'snap to grid' is on or not. If snap to grid is on, a 'space' is one grid cell (square or hex). If snap to grid is off a space is one pixel.
- a 'light source' is a point from which light is defined to issue. I suggest it could be either the centre or a corner of a figure or object base.
- an 'observer' is a figure that gives its owner visibility of the game map.
- a 'line of sight' is traced from an observer, a 'line of light' is traced from a light source. Lines of light determine whether a space is 'lit' or not - lines of sight determine whether an observer can see a space or not.
- 'light' can be full or dim; a space is either 'lit', 'dimly lit' or 'unlit'.
- a 'block' is a vector line that does not let lines of sight or lines of light pass. Optionally, a block might also apply to figures - i.e. figures may not move accross the line. A block goes from one space corner to another; in the case of spaces that are pixels, which corner is irrelevant...
Instead of assigning cells that are masked, the GM draws out the blocks for a particular map. If snap to grid is engaged, the blocks can run only from one cell corner to another (adjacent?) cell corner. Without snap to grid they just run from any one pixel to another. Individual blocks may be removed/deleted to allow for doors opening, etc.
As an additional enhancement (not essential but nice), objects could be defined as 'opaque' - this just means they have blocks defined for within them.
Rules are now applied for lines of light as follows:
- If a space has at least half of its corners touched by a line of light at full light range, it is fully lit.
If a space has any one corner touched by a line of light at full strength it is dimly lit.
If a space has at least half its corners touched by a line of light at dim strength it is dimly lit.
All other spaces are unlit.
Similar (but simpler) rules are now applied to lines of sight:
- Any space that has at least one corner touched by a valid line of sight is visible to the observer with the applicable light level.
Any other space is not visible to the observer.
Lines of light and lines of sight obviously have to be separately assessed for each observer, which will increase processing load, but I suggest that the determination only need be done when a light source or a relevant observer (i.e. an observer 'owned' by the local client) moves.
Mixing observers with low-light (light range multiplying) vision or 'darkvision' and normal vision on the same client will be tricky - probably all light ranges would have to multiplied, regardless of which observer has line of sight (which is what happens now with light sources, in effect) - but for single figure clients it would work fine. A figure with 'darkvision' calculates line of sight as normal, but treats all spaces within the darkvision range as 'lit' regardless of their actual status.
Not knowing how the current coding works I have no real idea how much of a change this would entail, but this is functionally how I think it should work. Comments?