|
|
| (38 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| [[Image:GSOC.png]] | | #REDIRECT [[Project proposals]] |
| | |
| = 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. Currently, this system uses a rectangular definition of the bounds, which is not sufficiently flexible for some types of simulation or game designs.
| |
| | |
| 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.
| |
| | |
| [[GSoC_Limited_play_area]]
| |
| | |
| == Sensor handling redesign / simplification ==
| |
| | |
| Estimated difficulty: '''Hard'''
| |
| | |
| 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.
| |
| | |
| Currently there are a number of different "sensor" systems in the engine: LineOfSight, Radar, Sonar, and Seismic. Some can be "jammed", some cannot. Some use a LineOfSight algorithm to determine coverage, and some are circular in area.
| |
| | |
| A new sensor system should integrate the current systems into a streamlined codebase, to reduce amount of code per function, and it should add additional features which would be then available for all types, while improving efficiency where possible.
| |
| | |
| [[GSoC_Sensor_handling_redesign]]
| |
| | |
| == Abstraction of Resources ==
| |
| | |
| Estimated difficulty: '''Medium'''
| |
| | |
| The Spring engine has its roots in an older Real-Time Strategy title, where only two major resources ("metal" and "energy") were incorporated into the game design.
| |
| | |
| This model has proven to be too inflexible to support certain types of gameplay, and is an obvious disadvantage to the Spring Engine when it is compared to other available software for constructing certain types of simulations. Furthermore, the use of Lua to support alternative models has not always proven satisfactory to game developers, who may lack the programming experience to build a resource-distribution system from scratch.
| |
| | |
| Therefore, we propose to write a new, more-flexible system that will support more than two resources, and possibly implement new behavioral models.
| |
| | |
| [[GSoC_Engine_resource_abstraction]]
| |
| | |
| == Basic ingame lobby ==
| |
| | |
| Estimated difficulty: '''Hard'''
| |
| | |
| All existing Spring online player match-making systems ('lobbies') are either difficult to customize for game developers or have a different look and feel from the games which are expected to operate with them. While they are Open Source, and are being actively maintained, they do not provide the same end-user experience one finds in commercial titles.
| |
| | |
| An in-game Lobby, leveraging the Spring Engine's strong Lua scripting support, should be implemented with customization and control in mind. This may possibly be integrated with Spring's codebase, or it may be designed as a separate process overlaying to the game's UI.
| |
| | |
| This could also serve as a practical "front end" for the Spring Engine, giving all games developed on the engine a standardized, yet flexible, system to support their players.
| |
| | |
| [[GSoC_Ingame_lobby]]
| |
| | |
| == Smarter pathfinder ==
| |
| | |
| Estimated difficulty: '''Hard'''
| |
| | |
| Given the Spring Engine's need to routinely handle responsive and bug-free pathfinding and path-following for large numbers of actors, this project could become a useful showcase and useful codebase for projects needing pathfinders, and could expand the world's understanding of pathfinding and path-following in realtime systems.
| |
| | |
| 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 is already a popular engine for academic projects to study Artificial Intelligence, given the Open Source model of development and strong support within the A.I. community. This project could enhance Spring's attractiveness to developers and teachers wanting to explore or teach about A.I.
| |
| | |
| The Spring engine's A.I. interface supports bindings for multiple languages. Currently C++, C and java are supported, and AIs may be constructed using Lua.
| |
| | |
| Bindings for more languages and/or virtual machines would 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 Engine's rendering system remains near the cutting edge of practical, functional OpenGL in a realtime environment, and is certainly notable amongst free, Open Source projects for its realism and flexibility. While it is not as advanced as the latest commercial engines, Spring's developers have made great strides in the last year, adding significant new features to the engine.
| |
| | |
| However, the core Spring rendering engine still includes many fixed function pipeline OpenGL functions. This rendering system is becoming deprecated and is generally slower and less flexible than more modern approaches.
| |
| | |
| Under this proposal, the rendering pipeline would be given a complete overhaul using modern graphic programming techniques, including shaders, standardised model formats that are easier for new artists to adapt to, and other enhancements, such as bump mapping, normal mapping, and multiple textures per Unit, while utilizing code that adheres to the OpenGL ES 2.0 specification.
| |
| | |
| [[GSoC_New_rendering_system]]
| |
| | |
| == Reconnect / Host change during a match ==
| |
| | |
| Estimated difficulty: '''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, or "desync". This causes an end-user to lose the true state of the simulation, and is a significant problem for players.
| |
| | |
| Our proposal is that a new system should be designed to allow manual and/or automatic switching of the game's host (possibly using an existing player's state, after testing load handling capabilities) and manual and/or automatic reconnection from client side if host remains the same.
| |
| | |
| [[GSoC_Reconnect_Host_change]]
| |
