GSoC Ingame lobby: Difference between revisions
From Spring
Jump to navigationJump to search
Brain damage (talk | contribs) No edit summary |
Brain damage (talk | contribs) |
||
| Line 2: | Line 2: | ||
== Why == | == 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 == | == What == | ||
Revision as of 16:24, 12 March 2010
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.