search

Chris3606 / GoRogue

.NET Standard roguelike library in C#. Features many algorithms and data structures pertinent to roguelike/2D game developers, specifically designed to be minimally intrusive upon the developer's architecture.
MIT License
494 stars 31 forks source link

Implement multiple-FOV system #83

Open Chris3606 opened 5 years ago

Chris3606 commented 5 years ago

Currently, with respect to FOV/LOS/SenseMapping, the options are:

  1. Create FOV instance. This allocates an array of doubles the size of the map under the hood, and is suited for very traditional FOV use cases. In the event of multiple FOV's, one could create multiple FOV instances and calculate all of them, however if those sources are very limited in radius compared to the size of the map, this results in significant over-allocation.
  2. Create SenseMap instance, add SenseSource instances to it. This allows for situations where you have multiple sources (sounds, light sources, etc), but as far as accessing the results is concerned. Athough it solves the over-allocation problem, it is designed for the case where you only care about the aggregate value for a location, as it collates them all together and caches the result when Calculate is called. This makes it difficult to use for things like multiple FOVs, where you want to be able to access and recalculate the results individually in some cases.

A third option such as FOVManager should be created, that takes modified (subclassed) SenseSources in, and allows them all to be accessed individually, from the source or the FOV Manager, and also allows the manual collation calculations. This would be suited to the case where individual source values need to be distinguished, and that distinction (and ability to potentially calculate them all at different times) is more important than the caching of the aggregated result.

Chris3606 commented 5 years ago

Issue here is documentation -- when to use FOV, when to use SenseMap, and when to use FOVManager. Another option is to completely replace the current FOV system with this -- which could be done in 2.0, depending on degree of intuitiveness, and relative performance of SenseMap vs FOV.

Since automatic aggregation would be unnecessary, the performance difference is probably minimal, though would take testing.

In addition the current SenseMap system chokes on radius values greater than the map size (as far as amount of memory allocated goes) -- this woudl have to be repaired to properly support infinite radiuses.

Another concern is the time spent re-allocating the SenseMap array, in the case that the radius very frequently changes. All of this would require investigation/testing.

Chris3606 commented 5 years ago

Yet another option -- use viewports to do this with current FOV system. While this would take some documentation, this is the option I lean toward. This would require implementation of UnboundedViewport<T> (see cross-referenced issue below) to function.

Chris3606 commented 4 years ago

Moved to 3.x as this will likely require some breaking changes to implement efficiently.