Google Summer of Code 2010: Difference between revisions
Brain damage (talk | contribs) Limited play area |
Brain damage (talk | contribs) Sensor handling redesign / simplification |
||
| Line 6: | Line 6: | ||
[[GSoC_Limited_play_area]] | [[GSoC_Limited_play_area]] | ||
== Sensor handling redesign / simplification == | |||
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.<br/> | |||
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.<br/> | |||
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.<br/> | |||
[[GSoC_Sensor_handling_redesign]] | |||
Work in progress Google Summer of Code 2010 ideas page. | Work in progress Google Summer of Code 2010 ideas page. | ||
Revision as of 19:19, 11 March 2010
Limited play area
Current spring map formats have an harcoded rectangle geometry, also they provide very limited support for defining aestetics of the surrounding environment outside the play area.
The new system should allow the map to restrict the playable area to a subset of the global area, possibly adding support for multiple shapes and/or non rectangular shape restrictions.
The restriction shapes should be readable and changeable mid-game trough the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.
Sensor handling redesign / simplification
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.
Work in progress Google Summer of Code 2010 ideas page.
