GSoC Ingame lobby: Difference between revisions
From Spring
Jump to navigationJump to search
Brain damage (talk | contribs) New page: = GSoC idea: Basic ingame lobby = == Why == External lobby programs are powerful but confusing. There's a need for a simple lobby client that works in-game and to launch spring. == Backg... |
|||
| Line 7: | Line 7: | ||
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. | 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 | 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. | Optionally, the engine's start screen should be replaced and integrated with it. | ||
== Required skills == | == Required skills == | ||
Revision as of 22:22, 11 March 2010
GSoC idea: Basic ingame lobby
Why
External lobby programs are powerful but confusing. There's a need for a simple lobby client that works in-game and to launch spring.
Background
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
- C++, Lua and Lua API
- Some OpenGL
Difficulty
Estimated: hard
- 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
- create a new Lua context or initalize current context earlier in the code during Spring init and script start interface using Lua.
