GSoC Ingame lobby: Difference between revisions

From Spring
Jump to navigationJump to search
Koshi (talk | contribs)
Line 28: Line 28:


== Possible Mentor(s) ==
== Possible Mentor(s) ==
[http://www.example.com FORUMLINK]


[[Google_Summer_of_Code_2010]]
[[Google_Summer_of_Code_2010]]

Revision as of 16:49, 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

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 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.


Possible Mentor(s)

Google_Summer_of_Code_2010