Google Summer of Code 2010: Difference between revisions
Brain damage (talk | contribs) |
added estimated difficulties |
||
| Line 1: | Line 1: | ||
== Limited play area == | == 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.<br/> | 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.<br/> | ||
| Line 9: | Line 11: | ||
== Sensor handling redesign / simplification == | == 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.<br/> | Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, Seismic. Some can be jammed, some can not. Some respect terrain, and some are always circular.<br/> | ||
| Line 18: | Line 22: | ||
== Engine level abstraction of resources == | == Engine level abstraction of resources == | ||
Estimated difficulty: medium | |||
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.<br/> | 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.<br/> | ||
| Line 27: | Line 33: | ||
== Basic ingame lobby == | == 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.<br/> | 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.<br/> | ||
| Line 36: | Line 44: | ||
== Smarter pathfinder == | == Smarter pathfinder == | ||
Estimated difficulty: hard | |||
Spring's pathfinder uses a 2d grid and is somewhat limited in functionality. | Spring's pathfinder uses a 2d grid and is somewhat limited in functionality. | ||
| Line 44: | Line 54: | ||
[[GSoC_Smarter_pathfinder]] | [[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.<br/> | The Spring engine's AI interface supports bindings for multiple languages, currently legacy C++, C and java are supported.<br/> | ||
| Line 54: | Line 65: | ||
== New Rendering System == | == New Rendering System == | ||
Estimated difficulty: below medium | |||
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 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 ) | |||
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.) | |||
[[GSoC_New_rendering_system]] | [[GSoC_New_rendering_system]] | ||
Revision as of 21:12, 11 March 2010
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.
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 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.
Engine level abstraction of resources
Estimated difficulty: medium
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.
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.
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 ).
New Rendering System
Estimated difficulty: below medium
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.)
Reconnect / Host change during a match
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.
