GSoC Ingame lobby: Difference between revisions
From Spring
Jump to navigationJump to search
libSpringLobby hint is better placed here than on the overview page |
|||
| Line 21: | Line 21: | ||
* ensure Spring can clean up properly | * ensure Spring can clean up properly | ||
* ensure Spring can change | * ensure Spring can change game and map 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 ) | * 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. | * 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. | ||
Revision as of 20:16, 7 March 2012
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
A new lobby should be implemented with customization and control in mind, using Lua scripting and reusing Spring codebase when possible. It should be running as a separate process overlaying to 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 game and map 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.
There is some potential of re-using/adapting libSpringLobby for the server interaction. Contact koshi in our IRC/Lobby channels if you are interested.
