GSOC 2009?

[YokoZar]

At Wine we get about 6 or so summer of code students every year, so I'm familiar with the process.

i don't quite believe google would want a rather niche game... and we're not exactly an organization.

They had projects for BZFlag, Battle for Wesnoth and ScummVM in the past, so why shouldn't we try?

Were they projects done by individual students or entire mentoring organizations? We don't have the infrastructure in place yet to have mentors sponsoring students.

[Agon]

First informations for gsoc 2009 are released.
Accepting mentor organizations applications on March 9, 2009.

Also the FAQ was updated for 2009:
http://code.google.com/intl/de-DE/opens ... /faqs.html

Here is a small example of a wiki page of a game which practices last summer with 8 students and mentored by 6 mentors:
http://www.thousandparsec.net/wiki/Goog ... er_of_Code

[el_matarife]

Proposal: Build a new lobby from scratch with the Win32 APIs or using .NET / WPF

Spring Lobby's developers and main userbase are Linux users, which I totally understand, but that means the Windows build will always be pretty unpolished. TASClient is the real Windows lobby, but a Delphi program is just plain not maintainable in 2009 since the IDE is terrible and no one "speaks" it anymore. We need a lobby built on Windows for Windows users using native Windows APIs on a good IDE in a really common language. It should be pretty close to TASClient in look and feel, but fix some of the really ugly or unintuitive UI issues.

[imbaczek]

better to polish springlobby... no point in duplicating the effort again.

[BrainDamage]

We need a lobby built on Windows for Windows users using native Windows APIs on a good IDE in a really common language.

wxWidgets uses native win API calls in windows, hence the native look
c++ is a pretty common language
dunno what you mean WRT IDE bit

It should be pretty close to TASClient in look and feel, but fix some of the really ugly or unintuitive UI issues.

feel free to make a patch for an alternate ui layout or maybe make the current one more flexible which is what I was trying in the first place

[danuker]

Why not an in-game lobby? Would eliminate the need for a lobby on every platform.

I warmly encourage the GSOC application.

[clericvash]

I think an ingame lobby would be much better to be honest either that or have all platforms by defualt use the same one.

[tombom]

SpringLobby is absolutely fine for Windows in most respects. It has some issues, but those are better fixed through just working on Springlobby than duplicating all the effort to create two separate lobbies.

[YokoZar]

SpringLobby is absolutely fine for Windows in most respects. It has some issues, but those are better fixed through just working on Springlobby than duplicating all the effort to create two separate lobbies.

Agreed.

There's no point to an ingame lobby (what does that even mean, in terms of features?)

[Argh]

There's no point to an ingame lobby (what does that even mean, in terms of features?)

It basically means... "one icon launches everything you want". Most games don't make you launch 3rd-party applications, and most games feel like... a game, not just some client that you hook into things. Game-specific skins and things like that for SpringLobby would really help with that, TASClient already had them, but nobody was taking advantage of them yet.

[Tobi]

An in game lobby also means "nice" things like when Spring crashes you crash out of the lobby too. When the lobby part crashes you crash out of the game you're in. The UI will probably be near unusable for use as chat client because it doesn't use native APIs but has a weird custom GL based interface that behaves just different to what you'd expect. Spring would probably crash on the second game because not everything happens to be cleaned up properly after a first game.

Besides these user-side issues it would bump compile/link time of Spring even more, it would require more collaboration between developers of the lobby part and the engine part, resulting in (much) more overhead, it would again tie together Spring and lobby updates with all the accompanying problems, etc.

In other words, from a technical perspective I think an game lobby is, definitely at this moment, a very stupid thing to do.

[AF]

There's no reason why a lobby or program cant be customized and fool the user into thinking that it and spring are the same program using clever trickery and fullscreen mode.

[Tobi]

That's not an in game lobby then

[AF]

We wouldn't tell the users that =p

[YokoZar]

There's no point to an ingame lobby (what does that even mean, in terms of features?)

It basically means... "one icon launches everything you want". Most games don't make you launch 3rd-party applications, and most games feel like... a game, not just some client that you hook into things. Game-specific skins and things like that for SpringLobby would really help with that, TASClient already had them, but nobody was taking advantage of them yet.

A full screen lobby would be a step backwards. The way it is now I can do other things while waiting for players to join my game - surf the internet, IM, etc.


Ideally, we'd have the lobby notify the user in some way when important things happen (receive a message, game gets full, players ring you, etc.) Currently we do these with sound, but we could do more: the window could also call for attention or we could even send an ephemeral notification with the new Ubuntu notifier system.

[AF]

The last battlehub preview sent out to testers had a demo button which shifted the lobby in and out of full screen should the user wish so.