GSoC Sensor handling redesign - Revision history

Abma at 17:55, 2 March 2012

2012-03-02T17:55:07Z

← Older revision		Revision as of 18:55, 2 March 2012
Line 28:		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.

	~~== Possible Mentor(s) ==~~		[[Category:GSoC]]

	~~{{GSoC2010_bottom}}~~

Koshi: backlink and category via template

2010-03-13T17:19:16Z

backlink and category via template

← Older revision		Revision as of 18:19, 13 March 2010
Line 30:		Line 30:
	== Possible Mentor(s) ==		== Possible Mentor(s) ==

	~~[[Google_Summer_of_Code_2010]]~~		{{GSoC2010_bottom}}

Tobi: Protected "GSoC Sensor handling redesign": protecting during application period [edit=sysop:move=sysop] (expires 22:00, 10 April 2010 (UTC))

2010-03-12T16:07:25Z

Protected "GSoC Sensor handling redesign": protecting during application period [edit=sysop:move=sysop] (expires 22:00, 10 April 2010 (UTC))

← Older revision	Revision as of 17:07, 12 March 2010
(No difference)

Tobi: /* Possible Mentor(s) */ removed forumlink

2010-03-12T15:45:17Z

Possible Mentor(s): removed forumlink

← Older revision		Revision as of 16:45, 12 March 2010
Line 29:		Line 29:

	== Possible Mentor(s) ==		== Possible Mentor(s) ==

	~~[http://www.example.com FORUMLINK]~~

	[[Google_Summer_of_Code_2010]]		[[Google_Summer_of_Code_2010]]

Brain damage: /* What */

2010-03-12T15:20:57Z

What

← Older revision		Revision as of 16:20, 12 March 2010
Line 5:		Line 5:

	== What ==		== What ==
	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.		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 ~~the~~ amount of code ~~per functionality~~ and ~~eventually~~ add additional features which would then ~~become~~ available for all types.		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 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.		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 ==

Brain damage at 15:12, 12 March 2010

2010-03-12T15:12:48Z

← Older revision		Revision as of 16:12, 12 March 2010
Line 4:		Line 4:
	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.		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~~ ==		== What ==
	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.		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.

Line 19:		Line 19:
	Estimated: hard		Estimated: hard

	* A new sensor system should integrate the current LOS, Radar, Sonar, Seismic systems to reduce amount of code per functionality.		== 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).

Brain damage: standardizing requirements format

2010-03-12T15:02:49Z

standardizing requirements format

← Older revision		Revision as of 16:02, 12 March 2010
Line 12:		Line 12:

	== Required skills ==		== Required skills ==
	* ~~Being able to program in~~ C++		* Knowledge of C++
	* Bachelor level algorithmics knowledge		* Bachelor level algorithmics knowledge
	* Bachelor level software engineering knowledge		* Bachelor level software engineering knowledge

Brain damage: /* Why */

2010-03-12T14:57:57Z

Why

← Older revision		Revision as of 15:57, 12 March 2010
Line 2:		Line 2:

	== Why ==		== 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~~.		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 ==		== Background ==

Koshi: /* Background */

2010-03-11T21:16:45Z

Background

← Older revision		Revision as of 22:16, 11 March 2010
Line 7:		Line 7:
	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.		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.		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 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.		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 ==		== Required skills ==

Koshi: /* Why */

2010-03-11T21:15:04Z

Why

← Older revision		Revision as of 22:15, 11 March 2010
Line 2:		Line 2:

	== Why ==		== Why ==
	Game designers have indicated a more generic sensor system would be ~~desired,~~ and a number of desired features have, over time, been mentioned.		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 ==