GSoC Sensor handling redesign: Difference between revisions
Brain damage (talk | contribs) |
Brain damage (talk | contribs) standardizing requirements format |
||
| Line 12: | Line 12: | ||
== Required skills == | == Required skills == | ||
* | * Knowledge of C++ | ||
* Bachelor level algorithmics knowledge | * Bachelor level algorithmics knowledge | ||
* Bachelor level software engineering knowledge | * Bachelor level software engineering knowledge | ||
Revision as of 16:02, 12 March 2010
GSoC idea: Sensor handling redesign / simplification
Why
The Spring Engine is currently capable of significant real-world applications in the area of simulation of certain types of events or situations; a better sensor system could greatly improve Spring's applicability to an even wider range of projects.
Background
Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular.
A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce the amount of code per functionality and eventually add additional features which would then become available for all types.
Preferably all this should also be faster then the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.
Required skills
- Knowledge of C++
- Bachelor level algorithmics knowledge
- Bachelor level software engineering knowledge
Difficulty
Estimated: hard
- A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems to reduce amount of code per functionality.
- It should be possible to specify different behaviours for sensors of either type: is it based on e.g. simple 2d or 3d distance check or terrain raycast (i.e. LOS).
- It should be possible to use multiple different types of radar in one game (possibly current seismic sensors system could be a type of radar too, internally).
- It should be possible to use "reversed LOS" for the sensor (instead of sight distance, detection distance is used - like cloak now).
- There should be a generic mechanism for jamming (removing coverage of an area) and stealth (only this unit is not detectable using this sensor) for each type of sensor.
- There should be support for Lua defined areas that block sensors operating in that area, hide units in that area for certain sensors, or block the rays of terrain-raycasting sensors.
- There should be support for creating false positives and false negatives using Lua.