SpringEngineTODO
From Spring
This page is badly out of date. Some of these items have been done, abandoned or replaced with better ideas.
Here is a TODO list for anyone interested in developing the spring code. If you are not involved in the development, please contact one of the developers first, or mail to the mailing list before you add things here.
- Implement saving/loading. There are a lot of direct LoadSave() functions in the game code, but the easier way would probably to finish the serialization in the class registration type interfaces (rts/System/creg), so everything can be serialized automatically.
- Implement re-sync. After a sync problem is detected, and a re-sync of the random seed does not fix it the game would pause and use the rsync to adjust game state (current plan if for float3 data) to resync, as suggested by Jesse Schoch in [1]. After using rsync on it should be able to continue normally until the next sync error is detected.
- Abstract and improve unit rendering:
- Improve the S3O rendering: It doesn't generate nice explosion particles like the 3DO system, and it has other issues with drawing as well (refer to the s3o related threads on the forum for this, or test it and see for yourself).
- 3DO/S3O support is not abstracted, many parts of unit rendering are spread throughout spring and assume 3DO, and the rendering is a messy mixture of 3DO and S3O stuff. Abstracting the model rendering with a sort of IModel and IModelInstance interfaces would allow adding other model formats as well (Such as a skeletal animation format).
- Improve weapon collision detection with more complex shapes for the bigger units. Giving every model a set of convex collision meshes, saved in the S3O file, could be a solution. This will need a change in the s3o format and upspring editor, so you will need some cooperate with me on that part(jcnossen).
- Bind a scripting language to Spring. Fnordia already started on this with lua and luabind, but since luabind does not compile on GCC (so I've heard (appears fine the cvs version though)).
- Binding LUA could be done in other ways too ofcourse.
- A lightweight and fast language that can call C/C++ directly is AngelScript (www.angelcode.com/angelscript), class support with inheritance is however not yet supported (WIP), but is already a good choice because it doesn't require wrapper functions.
- Squirrel is a more game orientated derivative of LUA and would be worth looking into. It supports classes directly as opposed to lua which "simulates" classes.
- It would be more work, but it could be possible to create a stripped down version of mono to integrate into spring. Then you can use any language Mono supports, with higher speed than the non-JIT scripting systems mentioned above.
- Make more elements of spring data-driven. Explosion bitmaps, trees, etc... A lot of graphics are hardcoded and should be changeable with scripts or config files (FBI/TDF).
- Implement a general sensor system replacing the radars, as described in http://taspring.clan-sy.com/phpbb/viewtopic.php?t=6105
- Add a dynamic-lighting system: Allow units to have dynamic lights on them that affect lighting of other units and landscape, with sort of "approximating lights" for cases where a lot of units get close together. This is a big thing, but it would improve spring graphics a lot if done well.
- Get a mac version working. Contact the developers on the mailing list for this, as there are people looking into this already.
- Abstract the rendering and add an orthographic renderer for OTA style play on lower end systems.
Even though this isn't really about the Spring engine:
- Get a working multi platform lobby client capable of joining battles, hosting battles, browsing maps, etc. (everything TASClient [the windows lobby] is capable off). Language/Toolkit doesn't matter. There's omni (Python and WxWidgets) and qspring (C++ and Qt 4) in the works.
- Make a proper configuration application, something that reads the settings from some sort of XML file with range, type and category information, and shows them nicely organized. As opposed to one big dialog full of options.