GSoC Engine resource abstraction: Difference between revisions
From Spring
Jump to navigationJump to search
| Line 19: | Line 19: | ||
Estimated: medium | Estimated: medium | ||
* The new system should completely | * 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) == | == Possible Mentor(s) == | ||
Revision as of 22:13, 11 March 2010
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; 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 modify it's state.
Required skills
- C++
- Lua
- OpenGL skills to adapt the engine gui (optional)
Difficulty
Estimated: medium
- 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
