GSoC Sensor handling redesign: Difference between revisions
| Line 2: | Line 2: | ||
== Why == | == Why == | ||
Game designers have indicated a more generic sensor system would be | Game designers have indicated that a more generic sensor system would be beneficial and a number of desired features have, over time, been mentioned. | ||
== Background == | == Background == | ||
Revision as of 22:15, 11 March 2010
GSoC idea: Sensor handling redesign / simplification
Why
Game designers have indicated that a more generic sensor system would be beneficial and a number of desired features have, over time, been mentioned.
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 amount of code per functionality, and eventually add additional features wich would be then available for all types.
Preferably this all 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
- Being able to program in 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.
