Spring - User contributions [en]

GSoC Reconnect Host change

2010-03-12T15:28:21Z

Brain damage: /* What */

= GSoC idea: Reconnect / Host change during a match =

== Why ==
Network links can sometimes be unreliable, being able to overcome temporary issues will improve play experience.

== What ==
Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted. A system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

== Required skills ==
* Knowledge of C++
* General networking knowledge
* Understanding Spring's networking model

== Difficulty ==
Estimated: medium to hard

== Technical details ==

* During a drop-out clients can be at diverging points in simulation time (game frame), so any solution would have to determine a common point and bring all players to that to ensure sync.
* During a server switch extra measures need to be implemented to prevent cheating.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC New rendering system

2010-03-12T15:27:47Z

Brain damage: /* What */

= GSoC idea: New Rendering System =

== Why ==
Spring rendering engine includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

== What ==
Under this proposal, the rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

== Required skills ==
* Knowledge of C++
* Knowledge of OpenGL 2.0 API
* Knowledge of GLSL

== Difficulty ==
Estimated: medium

== Technical details ==

* Refactor C++ code and classes
* Create new GLSL shaders and integrate some from Lua scripts
* Add threading to renderer
* Remove all direct OpenGL calls from synced (sim) code.
* Push more work onto GPU and use DMA transfers (VBOs) while retaining OpenGL 1.4 code path for intel chipsets
* Reduce/refactor the amount of code paths used for rendering different world objects and model types.
* Use more class overriding for new rendering code (instead of branching)
* OpenGL ES 2.0 compatibility should be aimed at where possible.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

Google Summer of Code 2010

2010-03-12T15:26:40Z

Brain damage: /* More AI interfaces */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: '''medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey.
Current Spring map formats have a hardcoded rectangle boundary geometry; they also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map's developer 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

'''Details:''' [[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''hard'''

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.

'''Details:''' [[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: '''medium to hard'''

The Spring engine has its roots in an older Real-Time Strategy title, where only two resources were incorporated into the game design.
The current resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

'''Details:''' [[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''hard'''

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look and feel from the game itself and require focus switch from the game itself to operate.

A new lobby should be implemented with customization and control in mind, using Lua scripting and reusing Spring codebase when possible.
It should be running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

'''Details:''' [[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all 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.

'''Details:''' [[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''medium'''

The Spring engine's AI interface supports bindings for multiple languages, currently C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Details:''' [[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''medium'''

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

'''Details:''' [[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''medium to hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted.
A system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Details:''' [[GSoC_Reconnect_Host_change]]

GSoC More AI interfaces

2010-03-12T15:26:29Z

Brain damage: /* What */

= GSoC idea: More AI interfaces =

== Why ==
The Spring engine is already a popular engine for academic projects to study Artificial Intelligence. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about AI research.

== What ==
The Spring engine's AI interface supports bindings for multiple languages, currently C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

== Required skills ==
* Understanding of the Spring AI interface
* Knowledge of C
* Understanding of the target language/virtual machine

== Difficulty ==
Estimated: medium

== Technical details ==

The current C AI interface has been structured so it acts as a bridge between the engine and the various AI language wrappers, since automatic wrapper generators have been tried in the past and found infeasible, manual creation is necessary.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Ingame lobby

2010-03-12T15:25:12Z

Brain damage: /* What */

= GSoC idea: Basic ingame lobby =

== Why ==
All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look and feel from the game itself and require focus switch from the game itself to operate.

== What ==
A new lobby should be implemented with customization and control in mind, using Lua scripting and reusing Spring codebase when possible. It should be running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

== Required skills ==
* Knowledge of C++
* Knowledge of Lua
* Knowledge of Lua API/C bindings
* Knowledge of basic OpenGL programming

== Difficulty ==
Estimated: hard

== Technical details ==

* ensure Spring can clean up properly
* ensure Spring can change mod during program runtime (requires that some singletons be converted to Spring's *handler pattern)
* The lobby API should reuse/be identical to spring's LuaUI where possible ( GL calls, access to game infos )
* to prevent Spring <-> lobby crash propagations they should run as separate processes, with lobby overlaying on top of Spring's UI, the only exception could be made for start screen.
* create a new Lua context or initalize current context earlier in the code and rewrite Spring's start interface using Lua scripting.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Ingame lobby

2010-03-12T15:24:43Z

Brain damage: /* Why */

= GSoC idea: Basic ingame lobby =

== Why ==
All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look and feel from the game itself and require focus switch from the game itself to operate.

== What ==
All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable, lobby should be implemented with customization and control in mind, possibly integrated with spring codebase and/or running as a separate process overlaying the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

== Required skills ==
* Knowledge of C++
* Knowledge of Lua
* Knowledge of Lua API/C bindings
* Knowledge of basic OpenGL programming

== Difficulty ==
Estimated: hard

== Technical details ==

* ensure Spring can clean up properly
* ensure Spring can change mod during program runtime (requires that some singletons be converted to Spring's *handler pattern)
* The lobby API should reuse/be identical to spring's LuaUI where possible ( GL calls, access to game infos )
* to prevent Spring <-> lobby crash propagations they should run as separate processes, with lobby overlaying on top of Spring's UI, the only exception could be made for start screen.
* create a new Lua context or initalize current context earlier in the code and rewrite Spring's start interface using Lua scripting.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Engine resource abstraction

2010-03-12T15:23:31Z

Brain damage: /* What */

= GSoC idea: Engine level abstraction of resources =

== Why ==
Current hardcoded resource system generates defects and can produce effects which are hard to workaround for game designers which aren't willing to use it.

== What ==
The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system and new calls will have to be added to modify its state.

== Required skills ==
* Knowledge of C++
* Knowledge of Lua/C API bindings

== Difficulty ==
Estimated: medium to hard

== Technical details ==

* The new system should completely supersede the current
* Sync check should be adapted to hash the new resource system
* Hardcoded assumptions such as cost-based targeting should be removed completely

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Engine resource abstraction

2010-03-12T15:23:08Z

Brain damage: /* Why */

= GSoC idea: Engine level abstraction of resources =

== Why ==
Current hardcoded resource system generates defects and can produce effects which are hard to workaround for game designers which aren't willing to use it.

== What ==
The Spring engine has its roots in being a Total Annihilation clone. While this intent has been dropped quite some time ago, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system and new calls will have to be added to modify its state.

== Required skills ==
* Knowledge of C++
* Knowledge of Lua/C API bindings

== Difficulty ==
Estimated: medium to hard

== Technical details ==

* The new system should completely supersede the current
* Sync check should be adapted to hash the new resource system
* Hardcoded assumptions such as cost-based targeting should be removed completely

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Sensor handling redesign

2010-03-12T15:20:57Z

Brain damage: /* What */

= 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.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Reconnect Host change

2010-03-12T15:19:18Z

Brain damage:

= GSoC idea: Reconnect / Host change during a match =

== Why ==
Network links can sometimes be unreliable, being able to overcome temporary issues will improve play experience.

== What ==
Spring's network model implies the existance of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

== Required skills ==
* Knowledge of C++
* General networking knowledge
* Understanding Spring's networking model

== Difficulty ==
Estimated: medium to hard

== Technical details ==

* During a drop-out clients can be at diverging points in simulation time (game frame), so any solution would have to determine a common point and bring all players to that to ensure sync.
* During a server switch extra measures need to be implemented to prevent cheating.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC New rendering system

2010-03-12T15:18:22Z

Brain damage:

= GSoC idea: New Rendering System =

== Why ==
Spring rendering engine includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

== What ==
The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either through direct loading or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

== Required skills ==
* Knowledge of C++
* Knowledge of OpenGL 2.0 API
* Knowledge of GLSL

== Difficulty ==
Estimated: medium

== Technical details ==

* Refactor C++ code and classes
* Create new GLSL shaders and integrate some from Lua scripts
* Add threading to renderer
* Remove all direct OpenGL calls from synced (sim) code.
* Push more work onto GPU and use DMA transfers (VBOs) while retaining OpenGL 1.4 code path for intel chipsets
* Reduce/refactor the amount of code paths used for rendering different world objects and model types.
* Use more class overriding for new rendering code (instead of branching)
* OpenGL ES 2.0 compatibility should be aimed at where possible.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC More AI interfaces

2010-03-12T15:17:49Z

Brain damage:

= GSoC idea: More AI interfaces =

== Why ==
The Spring engine is already a popular engine for academic projects to study Artificial Intelligence. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about AI research.

== What ==
The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

== Required skills ==
* Understanding of the Spring AI interface
* Knowledge of C
* Understanding of the target language/virtual machine

== Difficulty ==
Estimated: medium

== Technical details ==

The current C AI interface has been structured so it acts as a bridge between the engine and the various AI language wrappers, since automatic wrapper generators have been tried in the past and found infeasible, manual creation is necessary.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Smarter pathfinder

2010-03-12T15:17:02Z

Brain damage:

= GSoC idea: Smarter pathfinder =

== Why ==
Current pathfinder is rather inflexible and inefficient.

== What ==
Spring's pathfinder uses a 2d grid and is somewhat limited in functionality. A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

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 ==
* Knowledge of graphs and pathfinding (particularly navigation graphs)
* Knowledge of C++
* Knowledge of Lua API/C bindings

== Difficulty ==
Estimated: hard

== Technical details ==

The pathfinder is one of the better encapsulated subsystems in spring; generally, there will only be minor changes required in the rest of the engine, if any. There's a lot of algorithmic work to do under the hood, though:
* Cooperative pathfinding exists in a very scant form and could be greatly improved
* Navigation mesh could be introduced for better paths and faster searches - at the cost of generating the mesh and updating it online due to terrain modification

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Ingame lobby

2010-03-12T15:15:52Z

Brain damage:

= GSoC idea: Basic ingame lobby =

== Why ==
External lobby programs are powerful but confusing. There's a need for a simple lobby client that works in-game and to launch spring.

== What ==
All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable, lobby should be implemented with customization and control in mind, possibly integrated with spring codebase and/or running as a separate process overlaying the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

== Required skills ==
* Knowledge of C++
* Knowledge of Lua
* Knowledge of Lua API/C bindings
* Knowledge of basic OpenGL programming

== Difficulty ==
Estimated: hard

== Technical details ==

* ensure Spring can clean up properly
* ensure Spring can change mod during program runtime (requires that some singletons be converted to Spring's *handler pattern)
* The lobby API should reuse/be identical to spring's LuaUI where possible ( GL calls, access to game infos )
* to prevent Spring <-> lobby crash propagations they should run as separate processes, with lobby overlaying on top of Spring's UI, the only exception could be made for start screen.
* create a new Lua context or initalize current context earlier in the code and rewrite Spring's start interface using Lua scripting.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Engine resource abstraction

2010-03-12T15:13:33Z

Brain damage:

= GSoC idea: Engine level abstraction of resources =

== Why ==
So game designers can reuse engine resource system and avoid all weird behaviours caused by the hardcoded assumptions all over the place.

== What ==
The Spring engine has its roots in being a Total Annihilation clone. While this intent has been dropped quite some time ago, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system and new calls will have to be added to modify its state.

== Required skills ==
* Knowledge of C++
* Knowledge of Lua/C API bindings

== Difficulty ==
Estimated: medium to hard

== Technical details ==

* The new system should completely supersede the current
* Sync check should be adapted to hash the new resource system
* Hardcoded assumptions such as cost-based targeting should be removed completely

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Sensor handling redesign

2010-03-12T15:12:48Z

Brain damage:

= 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, 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

== 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.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Limited play area

2010-03-12T15:12:01Z

Brain damage: /* Technical Details */

= GSoC idea: Limited play area =

== Why ==
Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

== What ==
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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

== Required skills ==
* Knowledge of C++ a
* Knowledge of Lua/C API bindings

== Difficulty ==
Estimated: medium

== Technical details ==

Most of the current code is based on the assumption that the map's top left is always at (0, 0) and bottom right at (width, height). The most difficult part will be identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing).

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Limited play area

2010-03-12T15:10:58Z

Brain damage: Background -> what, splitted difficulty from technical details

= GSoC idea: Limited play area =

== Why ==
Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

== What ==
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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

== Required skills ==
* Knowledge of C++ a
* Knowledge of Lua/C API bindings

== Difficulty ==
Estimated: medium

== Technical Details ==

Most of the current code is based on the assumption that the map's top left is always at (0, 0) and bottom right at (width, height). The most difficult part will be identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing).

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Reconnect Host change

2010-03-12T15:09:23Z

Brain damage: standardizing requirements format

= GSoC idea: Reconnect / Host change during a match =

== Why ==
Network links can sometimes be unreliable, being able to overcome temporary issues will improve play experience.
== Background ==
Spring's network model implies the existance of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

== Required skills ==
* Knowledge of C++
* General networking knowledge
* Understanding Spring's networking model

== Difficulty ==
Estimated: medium to hard

* During a drop-out clients can be at diverging points in simulation time (game frame), so any solution would have to determine a common point and bring all players to that to ensure sync.
* During a server switch extra measures need to be implemented to prevent cheating.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC New rendering system

2010-03-12T15:08:38Z

Brain damage: standardizing requirements format

= GSoC idea: New Rendering System =

== Why ==
Spring rendering engine includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

== Background ==
The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either through direct loading or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

== Required skills ==
* Knowledge of C++
* Knowledge of OpenGL 2.0 API
* Knowledge of GLSL

== Difficulty ==
Estimated: medium

* Refactor C++ code and classes
* Create new GLSL shaders and integrate some from Lua scripts
* Add threading to renderer
* Remove all direct OpenGL calls from synced (sim) code.
* Push more work onto GPU and use DMA transfers (VBOs) while retaining OpenGL 1.4 code path for intel chipsets
* Reduce/refactor the amount of code paths used for rendering different world objects and model types.
* Use more class overriding for new rendering code (instead of branching)
* OpenGL ES 2.0 compatibility should be aimed at where possible.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC More AI interfaces

2010-03-12T15:06:52Z

Brain damage: standardizing requirements format

= GSoC idea: More AI interfaces =

== Why ==
The Spring engine is already a popular engine for academic projects to study Artificial Intelligence. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about AI research.

== Background ==
The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

== Required skills ==
* Understanding of the Spring AI interface
* Knowledge of C
* Understanding of the target language/virtual machine

== Difficulty ==
Estimated: medium

The current C AI interface has been structured so it acts as a bridge between the engine and the various AI language wrappers, since automatic wrapper generators have been tried in the past and found infeasible, manual creation is necessary.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Smarter pathfinder

2010-03-12T15:06:09Z

Brain damage: standardizing requirements format

= GSoC idea: Smarter pathfinder =

== Why ==
Current pathfinder is rather inflexible and inefficient.

== Background ==
Spring's pathfinder uses a 2d grid and is somewhat limited in functionality. A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

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 ==
* Knowledge of graphs and pathfinding (particularly navigation graphs)
* Knowledge of C++
* Knowledge of Lua API/C bindings

== Difficulty ==
Estimated: hard

The pathfinder is one of the better encapsulated subsystems in spring; generally, there will only be minor changes required in the rest of the engine, if any. There's a lot of algorithmic work to do under the hood, though:
* Cooperative pathfinding exists in a very scant form and could be greatly improved
* Navigation mesh could be introduced for better paths and faster searches - at the cost of generating the mesh and updating it online due to terrain modification

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Ingame lobby

2010-03-12T15:05:12Z

Brain damage: standardizing requirements format

= GSoC idea: Basic ingame lobby =

== Why ==
External lobby programs are powerful but confusing. There's a need for a simple lobby client that works in-game and to launch spring.

== Background ==
All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable, lobby should be implemented with customization and control in mind, possibly integrated with spring codebase and/or running as a separate process overlaying the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

== Required skills ==
* Knowledge of C++
* Knowledge of Lua
* Knowledge of Lua API/C bindings
* Knowledge of basic OpenGL programming

== Difficulty ==
Estimated: hard

* ensure Spring can clean up properly
* ensure Spring can change mod during program runtime (requires that some singletons be converted to Spring's *handler pattern)
* The lobby API should reuse/be identical to spring's LuaUI where possible ( GL calls, access to game infos )
* to prevent Spring <-> lobby crash propagations they should run as separate processes, with lobby overlaying on top of Spring's UI
* create a new Lua context or initalize current context earlier in the code during Spring init and script start interface using Lua.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Engine resource abstraction

2010-03-12T15:04:02Z

Brain damage: standardized requirements

= GSoC idea: Engine level abstraction of resources =

== Why ==
So game designers can reuse engine resource system and avoid all weird behaviours caused by the hardcoded assumptions all over the place.

== Background ==
The Spring engine has its roots in being a Total Annihilation clone. While this intent has been dropped quite some time ago, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system and new calls will have to be added to modify its state.

== Required skills ==
* Knowledge of C++
* Knowledge of Lua/C API bindings

== Difficulty ==
Estimated: medium to hard

* The new system should completely supersede the current
* Sync check should be adapted to hash the new resource system
* Hardcoded assumptions such as cost-based targeting should be removed completely

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Sensor handling redesign

2010-03-12T15:02:49Z

Brain damage: standardizing requirements format

= 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.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Limited play area

2010-03-12T15:02:20Z

Brain damage: standardizing requirements format

= GSoC idea: Limited play area =

== Why ==
Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

== Background ==
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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

== Required skills ==
* Knowledge of C++ a
* Knowledge of Lua/C API bindings

== Difficulty ==
Estimated: medium

Most of the current code is based on the assumption that the map's top left is always at (0, 0) and bottom right at (width, height). The most difficult part will be identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing).

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Limited play area

2010-03-12T15:01:13Z

Brain damage: /* Why */

= GSoC idea: Limited play area =

== Why ==
Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

== Background ==
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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

== Required skills ==
* C++ and Lua/C api

== Difficulty ==
Estimated: medium

Most of the current code is based on the assumption that the map's top left is always at (0, 0) and bottom right at (width, height). The most difficult part will be identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing).

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC Limited play area

2010-03-12T15:01:05Z

Brain damage: /* Background */

= GSoC idea: Limited play area =

== Why ==
So the mappers can define which part of the map is designed for gameplay and which for the looks.

== Background ==
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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

== Required skills ==
* C++ and Lua/C api

== Difficulty ==
Estimated: medium

Most of the current code is based on the assumption that the map's top left is always at (0, 0) and bottom right at (width, height). The most difficult part will be identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing).

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC New rendering system

2010-03-12T14:59:54Z

Brain damage:

= GSoC idea: New Rendering System =

== Why ==
Spring rendering engine includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

== Background ==
The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either through direct loading or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

== Required skills ==
* Knowledge of C++
* Knowledge of OpenGL 2.0 API and GLSL
* Understanding Spring's sync system

== Difficulty ==
Estimated: medium

* Refactor C++ code and classes
* Create new GLSL shaders and integrate some from Lua scripts
* Add threading to renderer
* Remove all direct OpenGL calls from synced (sim) code.
* Push more work onto GPU and use DMA transfers (VBOs) while retaining OpenGL 1.4 code path for intel chipsets
* Reduce/refactor the amount of code paths used for rendering different world objects and model types.
* Use more class overriding for new rendering code (instead of branching)
* OpenGL ES 2.0 compatibility should be aimed at where possible.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

Google Summer of Code 2010

2010-03-12T14:59:20Z

Brain damage: /* New Rendering System */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: '''medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey.
Current Spring map formats have a hardcoded rectangle boundary geometry; they also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map's developer 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

'''Details:''' [[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''hard'''

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.

'''Details:''' [[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: '''medium to hard'''

The Spring engine has its roots in an older Real-Time Strategy title, where only two resources were incorporated into the game design.
The current resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

'''Details:''' [[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''hard'''

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look and feel from the game itself and require focus switch from the game itself to operate.

A new lobby should be implemented with customization and control in mind, using Lua scripting and reusing Spring codebase when possible.
It should be running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

'''Details:''' [[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all 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.

'''Details:''' [[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''medium'''

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Details:''' [[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''medium'''

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

'''Details:''' [[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''medium to hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted.
A system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Details:''' [[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T14:59:13Z

Brain damage: /* New Rendering System */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: '''medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey.
Current Spring map formats have a hardcoded rectangle boundary geometry; they also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map's developer 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

'''Details:''' [[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''hard'''

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.

'''Details:''' [[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: '''medium to hard'''

The Spring engine has its roots in an older Real-Time Strategy title, where only two resources were incorporated into the game design.
The current resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

'''Details:''' [[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''hard'''

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look and feel from the game itself and require focus switch from the game itself to operate.

A new lobby should be implemented with customization and control in mind, using Lua scripting and reusing Spring codebase when possible.
It should be running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

'''Details:''' [[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all 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.

'''Details:''' [[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''medium'''

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Details:''' [[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''medium'''

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).
'''Details:''' [[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''medium to hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted.
A system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Details:''' [[GSoC_Reconnect_Host_change]]

GSoC Sensor handling redesign

2010-03-12T14:57:57Z

Brain damage: /* Why */

= 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 ==
* 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.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

Google Summer of Code 2010

2010-03-12T14:57:18Z

Brain damage: /* Limited play area */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: '''medium'''

Spring uses a finite-world model, where the scene has distinct bounds that all actors must obey.
Current Spring map formats have a hardcoded rectangle boundary geometry; they also provide very limited support for defining aesthetics of the surrounding environment outside the play area.

The new system should allow the map's developer 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

'''Details:''' [[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''hard'''

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.

'''Details:''' [[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: '''medium to hard'''

The Spring engine has its roots in an older Real-Time Strategy title, where only two resources were incorporated into the game design.
The current resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

'''Details:''' [[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''hard'''

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look and feel from the game itself and require focus switch from the game itself to operate.

A new lobby should be implemented with customization and control in mind, using Lua scripting and reusing Spring codebase when possible.
It should be running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

'''Details:''' [[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all 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.

'''Details:''' [[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''medium'''

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Details:''' [[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''medium'''

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

'''Details:''' [[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''medium to hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted.
A system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Details:''' [[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T14:54:25Z

Brain damage: /* Sensor handling redesign / simplification */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: '''medium'''

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

'''Details:''' [[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''hard'''

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.

'''Details:''' [[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: '''medium to hard'''

The Spring engine has its roots in an older Real-Time Strategy title, where only two resources were incorporated into the game design.
The current resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

'''Details:''' [[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''hard'''

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look and feel from the game itself and require focus switch from the game itself to operate.

A new lobby should be implemented with customization and control in mind, using Lua scripting and reusing Spring codebase when possible.
It should be running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

'''Details:''' [[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all 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.

'''Details:''' [[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''medium'''

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Details:''' [[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''medium'''

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

'''Details:''' [[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''medium to hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted.
A system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Details:''' [[GSoC_Reconnect_Host_change]]

GSoC Limited play area

2010-03-12T14:50:49Z

Brain damage: removed grep reference

= GSoC idea: Limited play area =

== Why ==
So the mappers can define which part of the map is designed for gameplay and which for the looks.

== Background ==
Current spring map formats have a harcoded rectangle geometry. They also provide very limited support for defining aesthetics 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

== Required skills ==
* C++ and Lua/C api

== Difficulty ==
Estimated: medium

Most of the current code is based on the assumption that the map's top left is always at (0, 0) and bottom right at (width, height). The most difficult part will be identifying all places that check for point-in-map condition and determining whether they should be converted to the new limited map area or left as-is (e.g. for drawing).

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

Google Summer of Code 2010

2010-03-12T14:49:53Z

Brain damage: more argh imports

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: '''medium'''

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

'''Details:''' [[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''hard'''

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. 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 which would be then available for all types.

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.

'''Details:''' [[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: '''medium to hard'''

The Spring engine has its roots in an older Real-Time Strategy title, where only two resources were incorporated into the game design.
The current resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

'''Details:''' [[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''hard'''

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look and feel from the game itself and require focus switch from the game itself to operate.

A new lobby should be implemented with customization and control in mind, using Lua scripting and reusing Spring codebase when possible.
It should be running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

'''Details:''' [[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all 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.

'''Details:''' [[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''medium'''

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Details:''' [[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''medium'''

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

'''Details:''' [[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''medium to hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted.
A system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Details:''' [[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T14:46:53Z

Brain damage: /* Basic ingame lobby */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: '''medium'''

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

'''Details:''' [[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''hard'''

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. 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 which would be then available for all types.

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.

'''Details:''' [[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: '''medium to hard'''

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

'''Details:''' [[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''hard'''

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look and feel from the game itself and require focus switch from the game itself to operate.

A new lobby should be implemented with customization and control in mind, using Lua scripting and reusing Spring codebase when possible.
It should be running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

'''Details:''' [[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all 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.

'''Details:''' [[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''medium'''

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Details:''' [[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''medium'''

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

'''Details:''' [[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''medium to hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted.
A system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Details:''' [[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T14:41:52Z

Brain damage: /* Reconnect / Host change during a match */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: '''medium'''

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

'''Details:''' [[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''hard'''

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. 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 which would be then available for all types.

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.

'''Details:''' [[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: '''medium to hard'''

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

'''Details:''' [[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''hard'''

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

'''Details:''' [[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all 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.

'''Details:''' [[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''medium'''

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Details:''' [[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''medium'''

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

'''Details:''' [[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''medium to hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can be interrupted.
A system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Details:''' [[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T14:39:25Z

Brain damage:

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: '''medium'''

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

'''Details:''' [[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''hard'''

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. 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 which would be then available for all types.

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.

'''Details:''' [[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: '''medium to hard'''

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

'''Details:''' [[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''hard'''

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

'''Details:''' [[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all 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.

'''Details:''' [[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''medium'''

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Details:''' [[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''medium'''

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

'''Details:''' [[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''medium to hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Details:''' [[GSoC_Reconnect_Host_change]]

GSoC New rendering system

2010-03-12T14:38:51Z

Brain damage: /* Background */

= GSoC idea: New Rendering System =

== Why ==
Spring rendering engine includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

== Background ==
The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either through direct loading or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

OpenGL ES 2.0 compatibility should be aimed at where possible.

== Required skills ==
* Knowledge of C++
* Knowledge of OpenGL 2.0 API and GLSL
* Understanding Spring's sync system

== Difficulty ==
Estimated: medium

* Refactor C++ code and classes
* Create new GLSL shaders and integrate some from Lua scripts
* Add threading to renderer
* Remove all direct OpenGL calls from synced (sim) code.
* Push more work onto GPU and use DMA transfers (VBOs) while retaining OpenGL 1.4 code path for intel chipsets
* Reduce/refactor the amount of code paths used for rendering different world objects and model types.
* Use more class overriding for new rendering code (instead of branching)

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC New rendering system

2010-03-12T14:38:08Z

Brain damage: /* Why */

= GSoC idea: New Rendering System =

== Why ==
Spring rendering engine includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.

== Background ==
The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either through direct loading or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

OpenGL ES 2.0 compatibility should be aimed at where possible.

== Required skills ==
* Knowledge of C++
* Knowledge of OpenGL 2.0 API and GLSL
* Understanding Spring's sync system

== Difficulty ==
Estimated: medium

* Refactor C++ code and classes
* Create new GLSL shaders and integrate some from Lua scripts
* Add threading to renderer
* Remove all direct OpenGL calls from synced (sim) code.
* Push more work onto GPU and use DMA transfers (VBOs) while retaining OpenGL 1.4 code path for intel chipsets
* Reduce/refactor the amount of code paths used for rendering different world objects and model types.
* Use more class overriding for new rendering code (instead of branching)

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

Google Summer of Code 2010

2010-03-12T14:35:15Z

Brain damage: /* New Rendering System */

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: '''medium'''

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

'''Details:''' [[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''hard'''

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. 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 which would be then available for all types.

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.

'''Details:''' [[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: '''medium to hard'''

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

'''Details:''' [[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''hard'''

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

'''Details:''' [[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all 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.

'''Details:''' [[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''medium'''

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Details:''' [[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''medium'''

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than more modern approaches.

Under this proposal, the rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

'''Details:''' [[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''medium to hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Details:''' [[GSoC_Reconnect_Host_change]]

GSoC More AI interfaces

2010-03-12T14:31:19Z

Brain damage: A.I. vs AI consistency

= GSoC idea: More AI interfaces =

== Why ==
The Spring engine is already a popular engine for academic projects to study Artificial Intelligence. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about AI research.

== Background ==
The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

== Required skills ==
* Understanding of the Spring AI interface
* knowledge of C
* Understanding of the target language/virtual machine

== Difficulty ==
Estimated: medium

The current C AI interface has been structured so it acts as a bridge between the engine and the various AI language wrappers, since automatic wrapper generators have been tried in the past and found infeasible, manual creation is necessary.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC More AI interfaces

2010-03-12T14:30:55Z

Brain damage: Imported some of Argh's edits to why

= GSoC idea: More AI interfaces =

== Why ==
The Spring engine is already a popular engine for academic projects to study Artificial Intelligence. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I. research.

== Background ==
The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

== Required skills ==
* Understanding of the Spring AI interface
* knowledge of C
* Understanding of the target language/virtual machine

== Difficulty ==
Estimated: medium

The current C AI interface has been structured so it acts as a bridge between the engine and the various AI language wrappers, since automatic wrapper generators have been tried in the past and found infeasible, manual creation is necessary.

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

Google Summer of Code 2010

2010-03-12T14:28:16Z

Brain damage: re-applied some of Argh's formatting edits, THIS IS A SHORT SUMMARY PAGE, NOT FULL DESCRIPTION

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: '''medium'''

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

'''Details:''' [[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: '''hard'''

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. 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 which would be then available for all types.

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.

'''Details:''' [[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: '''medium to hard'''

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

'''Details:''' [[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: '''hard'''

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

'''Details:''' [[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: '''hard'''

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all 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.

'''Details:''' [[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: '''medium'''

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

'''Details:''' [[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: '''medium'''

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than shader usage.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

'''Details:''' [[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: '''medium to hard'''

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

'''Details:''' [[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-12T14:22:34Z

Brain damage: Reverted edits by Argh (Talk); changed back to last version by Babbles

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

Current Spring map formats have a hardcoded rectangle geometry; also they provide very limited support for defining aesthetics 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 through the engine's Lua API. Proper handling of units which are suddenly off-map needs to be implemented.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic, some can be jammed, some cannot. 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 which would be then available for all types.

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.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has its roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be flexible enough to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in mind, possibly integrated with Spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones (for pathfinder-aware tunnels/teleporting/etc.).

Preferably this should all 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.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: medium

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower and less flexible than shader usage.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardised model formats (backwards compatibility with current available formats is mandatory either through direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.).

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existence of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-11T23:25:57Z

Brain damage:

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

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.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

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 than the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has it's roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in the mind, possibly integrated with spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

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.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: medium

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existance of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

Google Summer of Code 2010

2010-03-11T23:25:31Z

Brain damage: Only current listed tasks will be submitted to GSoC

[[Image:GSOC.png]]

= Project proposals =

This is the list of project ideas for students willing to work on the Spring engine during the Google Summer of Code 2010. If you wish, you may read our [[Google_Summer_of_Code_2010_student_application|student application]].

== Limited play area ==

Estimated difficulty: medium

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.

[[GSoC_Limited_play_area]]

== Sensor handling redesign / simplification ==

Estimated difficulty: hard

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 than the current system, or a compelling argument/experiment should be made that shows there can not be a faster system with the same features.

[[GSoC_Sensor_handling_redesign]]

== Engine level abstraction of resources ==

Estimated difficulty: medium to hard

The Spring engine has it's roots in being a Total Annihilation clone; even if such intent has been dropped since quite some time, the TA resource system is largely present in the codebase being hardcoded in a lot of critical places.

The old system needs to be replaced, the new one should be enough flexible to reproduce everything that the old system did and be able to imitate the behaviour of most common RTS game titles.

The engine's Lua API to fetch resources will have to be adapted to the new system, and new calls will have to be added to edit it.

[[GSoC_Engine_resource_abstraction]]

== Basic ingame lobby ==

Estimated difficulty: hard

All existing Spring interfaces (lobbies) are either difficult to customize for game developers or have a different look 'n feel from the game itself and require focus switch from the game itself to operate.

A new, Lua scriptable lobby should be implemented with customization and control in the mind, possibly integrated with spring codebase and/or running as a separate process overlaying to the game's UI.

Optionally, the engine's start screen should be replaced and integrated with it.

[[GSoC_Ingame_lobby]]

== Smarter pathfinder ==

Estimated difficulty: hard

Spring's pathfinder uses a 2d grid and is somewhat limited in functionality.
A partial/full rewrite should be introduced to add support for navigating using more than 8 primary directions and selectively ignore certain unit types for performance reasons.

Spring's Lua API should be extended to allow game developers to push new nodes/links and be able to alter or delete existing ones. (for pathfinder-aware tunnels/teleporting/etc.)

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.

[[GSoC_Smarter_pathfinder]]

== More AI interfaces ==

Estimated difficulty: medium

The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.

Bindings for more languages and/or virtual machines should be added to allow broader AI developing audience (for example: Ruby, Perl, JavaScript, Python, D, Go, Mono, LLVM, Parrot).

[[GSoC_More_AI_interfaces]]

== New Rendering System ==

Estimated difficulty: medium

The Spring rendering engine uses a lot of FFP (fixed function pipeline) OpenGL functions. This model is becoming deprecated and is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

OpenGL ES 2.0 compatibility should be aimed at where possible.

[[GSoC_New_rendering_system]]

== Reconnect / Host change during a match ==

Estimated difficulty: medium to hard

Spring's network model implies the existance of a server to host a battle. For various reasons the network link between host and clients can die, so a system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.

[[GSoC_Reconnect_Host_change]]

GSoC Reconnect Host change

2010-03-11T21:55:25Z

Brain damage: New page: = GSoC idea: Reconnect / Host change during a match = == Why == Network links can sometimes be unreliable, being able to overcome temporary issues will improve play experience. == Backgr...

= GSoC idea: Reconnect / Host change during a match =

== Why ==
Network links can sometimes be unreliable, being able to overcome temporary issues will improve play experience.
== Background ==
Spring's network model implies the existance of a server to host a battle, because of various reasons, the network link between host and clients can die, a system should be designed to allow manual and/or automatic switch game host (possibly using an existing player after testing load handling capabilities), and manual and/or automatic reconnection from client side if host remains the same.

== Required skills ==
* C++
* General networking knowledge
* Boost::asio sockets
* Understanding Spring's networking

== Difficulty ==
Estimated: medium to hard

* During a drop-out, all clients can have different frame amount, it needs to determine a common point and bring all players to that to ensure sync
* During a server switch, particular measures should be adopted to prevent cheating

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]

GSoC New rendering system

2010-03-11T21:46:28Z

Brain damage:

= GSoC idea: New Rendering System =

== Why ==
Rendering will be faster and more extensible, making it easier to bring in new features and players. It should help prevent Spring's visuals become 'dated' compared to commercial games running DX11 or OpenGL 3.1. It may eliminate some long-standing rendering bugs.

== Background ==
The Spring rendering engine uses a lot FFP (fixed function pipeline) OpenGL functions, this model is becoming deprecated, it is generally slower than shader usage and less flexible.

The rendering code should get a complete overhaul using modern graphic programming techniques such as shaders, implement load support for more standardized model formats (backwards compatibility with current available formats is mandatory either trough direct load or automatic conversion to the new types) and eventually introduce some graphic enhancing features (bump mapping, normal mapping, multitexturing, etc.)

OpenGL ES 2.0 compatibility should be aimed at where possible.

== Required skills ==
* Knowledge of C++
* Knowledge of OpenGL 2.0 API and GLSL
* Understanding Spring's sync system

== Difficulty ==
Estimated: below medium

* Refactor C++ code and classes
* Create new GLSL shaders and integrate some from Lua scripts
* Add threading to renderer
* Remove all direct OpenGL calls from synced (sim) code.
* Push more work onto GPU and use DMA transfers (VBOs)
* Reduce/refactor the amount of code paths used for rendering different world objects and model types.
* Use more class overriding for new rendering code (instead of branching)

== Possible Mentor(s) ==

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

[[Google_Summer_of_Code_2010]]