GSoC Sensor handling redesign: Difference between revisions
From Spring
Jump to navigationJump to search
No edit summary |
|||
| (9 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
== Why == | == 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. | |||
== | == What == | ||
Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some | Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some sensors can be jammed, some cannot. Some respect terrain, and some are always circular in coverage. | ||
A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems, to reduce amount of code | A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems into a streamlined codebase, to reduce amount of code in each implementation, and it should add additional features which would be then available for all types, while improving efficiency where possible. | ||
Preferably this all should also be faster | Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot be a faster system with the same features. | ||
== 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 | ||
| Line 19: | Line 19: | ||
Estimated: hard | Estimated: hard | ||
== Technical details == | |||
* 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 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 multiple different types of radar in one game (possibly current seismic sensors system could be a type of radar too, internally). | ||
| Line 27: | Line 28: | ||
* There should be support for creating false positives and false negatives using Lua. | * There should be support for creating false positives and false negatives using Lua. | ||
[[Category:GSoC]] | |||
[ | |||
Latest revision as of 18:55, 2 March 2012
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.
What
Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some sensors can be jammed, some cannot. Some respect terrain, and some are always circular in coverage.
A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems into a streamlined codebase, to reduce amount of code in each implementation, and it should add additional features which would be then available for all types, while improving efficiency where possible.
Preferably this all should also be faster than the current system or a compelling argument/experiment should be made that shows there cannot 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
Technical details
- 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.
