Spring RTS Engine

abma on github wrote:also the general goal is: do not require a lobby any more

meaning?
SL will be discontinued?

8611z wrote: abma on github wrote:
also the general goal is: do not require a lobby any more

meaning?
SL will be discontinued?

no, its about distributing games, atm a lobby is still required for multiplayer games / updating / downloading maps and games.

The github comment did read as if sl would stop development or so.
Your reply leaves more questions now: Why is the lobby "atm" "still" required?
Basically: Will SL be continued or eventually be abadoned in favor of in-engine stuff or whatever.

8611z wrote:Basically: Will SL be continued or eventually be abadoned in favor of in-engine stuff or whatever.

it will be continued but maybe abadoned when its not needed any more.

(split from the release thread, thats totally off-topic there)

what is the long term lobby for spring games?

something that runs on a web browser?

raaar wrote:what is the long term lobby for spring games?

nobody knows. i vote for an in-engine lobby.

I'd vote for keeping SL for developers, and having less featured 'ingame' lua lobbies for casual players.

raaar wrote:what is the long term lobby for spring games?

Excactly my question.
My thoughts on it:

I had begun modding with the thought that an infrastructure to play would be there.
It never bothered me much that lobbies have various bugs, sure annoying, but okay when they were under development. (report & move on)
Similiar with singleplayer-campaign: I started developing SP-stuff despite knowing that Spring-Restart was broken, and no lobby supported it, yet, and simply hoped eventually lobbies would have such feature. I am totally cool with working on content for a broken/WIP platform, really does not bother me the the slightest, IF the future perspective looks good.

If the plan is that in future each game has to make its own installers, lobbies and fight for players (instead of one community, as it was when I started) then I am not interessted in that. In such enviroment I would never have started, modding or playing.

Further, an in-engine lobby would to me be the wrong way.
I have played multiplayer spring long enough to know that between matches there are long waiting periods, with that I never had big problem.

But I noticed how important it was that during waiting springlobby (or other lobbies) could easily run in background while I do something else.
Waiting for next match will always be a part of spring.
Also lobbies could do stuff like popup-notifactions when you got a pm or someone wanted to play.
I experienced how often players could not run the engine, until they asked for help in chat.
With an in-engine lobby I can not imagine any of this, already alt-tabbing spring does for me not work as good as simply having another window on desktop, resource usage is higher etc.
If there is to be some seperation between "devs" and "players", or something along lines that games 'start small in spring' and eventually take half the players away to their seperate walled-garden communities, then I have no interest in that either.

TLDR;

closing, this leads to nothing

Reopening, no need to close, discussion is perfectly civil.

abma wrote:

raaar wrote:what is the long term lobby for spring games?

nobody knows. i vote for an in-engine lobby.

# I vote for a separate lobby.

As it is now, playing Spring is pretty much a game of waiting for a match. If we have our "desktop" taken-over by Spring that's quite an entry-barrier keeping players from opening the game and after players will then be either:
- not paying attention to the waiting game;
- or will be severely bored to death.

Another issue with that path is that is increases the complexity of SpringRTS (the engine), which would have to start taking responsibility for all of those other things. Keeping them as completely separate areas of responsibility really helps with the complexity. One of the very important issues that we need to keep in mind is the nature of SpringRTS, a community of real-life people that just keep leaving (with all their knowledge) and new ones coming (oblivious at how things work).


# Having said that,
As it is now feels really disconnected. Unsurprising, since SpringRTS is «just» the engine, the mods/games have virtually no independence and, even though users were pitched "SpringRTS" / "Spring Engine", they're having to start an ugly tool named "SpringLobby" (it's far from immediately obvious that if you want to play "Spring" or "BA" or "Kernel Panic" you have to start "SpringLobby").

It is also preventing the "game" from having a nice intro animation, shiny menu, etc, the standard game stuff. Again, unsurprising, since the whole thing isn't structured as a "game" but instead a collection of tools: the spring Client, the engine, and the content packs.

Controlling multiple versions of lobbies and of the engine? Having to cope with where the heck the engine is installed and what not? Ugh!

Having in-game lobby/ies could help with these points.

^ I still think these points do not override the other more important points and that in-game control should be reserved for the "Games" (mods/content packs), like for things as campaigns.

I dont really see ingame lobbies taking off for multiplayer.
As it is right now i use springlobby like an irc with gaming plugin, i can leave it on the whole day and mind my own business even if i dont play at all or i can wait for hours for a game and not be disturbed by the waiting.
Tough i think a interface for singleplayer missions campaigns and even a cheap online lobby will be needed for those who accidently just start spring rather than a lobby.
And for those sad souls who have the attention span of a pigeon there is no hope in a rts game anyway.

An ingame lobby limits the pool of potential developers to those familiar with the engine, OpenGL, lua, and whatever UI toolkit is being used, most likely Chilli. That pool is miniscule and dwindling in comparison to frontend web and javascript, python, or others who can waltz in and build tools with what they already know rather than climbing a learning curve shaped like a mountain

Ingame lobbies sounds good, and running spring directly should at least give you a decent UI for setting up a single player game, maybe even a basic LAN game, but it'll never compare to external lobbies, it's simply too expensive developer-wise to build and maintain. I wish it weren't the case

AF wrote:An ingame lobby limits the pool of potential developers to those familiar with the engine, OpenGL, lua, and whatever UI toolkit is being used, most likely Chilli. That pool is miniscule and dwindling in comparison to frontend web and javascript, python, or others who can waltz in and build tools with what they already know rather than climbing a learning curve shaped like a mountain

I don't know about that. Lobby development requires the exact same kind of knowledge as Spring game development, so it's a reasonable wager that most Spring game devs would have the ability to write them without much learning.
OTOH nearly every non-ingame lobby is written in a different language and framework, and I'm fairly certain there are some which I'd struggle with to get into.

True, if you want to participate in the current lobby system, settle on all the conventions and baggage, implement the TASSERVER protocol as it currently stands, then you've got a lot to implement and catch up on regardless of what language or platform you're working with

If on the other hand you don't care about all that stuff then you only really need to learn how to:

- Start spring
- Get a list of maps and their minimaps
- Get a list of games
- Get a list of factions

The rest can be whatever you want. I think a good first goal of ingame engine lobbies would be to handle the battle itself. Have external lobbies launch the game which then shows chat/map selector/faction picker/etc the way OTA did. At this point the engine is now compatible with the vast majority of existing matchmakers and lobbies out in the wild, and content devs can customise as much as they like. Meanwhile the technical burden of the existing lobbies is massively cut down as is their maintenance cost, and the server protocol can be reduced to less than a quarter of its existing footprint

Engine
Well, if someone starts the engine directly, it makes sense to have the engine have a built in front-end for pr downloader. Much like my batch menu for pr downloader (although my menu is crude where the in-engine one could be very nice). That front end could be made to download games+dependencies.

In cases where the lobbies are screwing up downloads, such a frontend could be very helpful. Would probably need the ability to download maps as well (springfiles maps downloader of sorts or something?).

Single Player
As far a single player experience... The AI's need to stop being bundled with the engine. It is extremely confusing to players and the lack of support for validais.lua and validmaps.lua is crippling to the entire experience. Most games won't have a reasonable SP experience. Evo does, but even though shard plays a pretty good game, I don't find it terribly interesting. And the fact that I can't bundle shard with Evo as a luaai really hampers the experience (And the spawner is a bad joke). S44 and ZK have ok sp experiences, and I'm sure some of the *A stuff does, but my point is that you're gonna have this weird mishmash of stuff that has crap SP (Like Evo (It may exist, but I still think it's shoddy)) and stuff that has ok -> good SP (Like BA and ZK). The fact that it's so all over the place makes all the projects look worse for the wear.

Spring Site
I think that on the download page for spring, it would be beneficial to have games listed prominently and have the actual engine download listed below as a footnote. I understand that this might stick in your craw, but look at this website... It is advertising games, not an engine. Moreover, it is trying to appeal to players, not developers. Some might say that promoting games attracts developers to which I disagree and say that techdemos do a better job of advertising to devs than games do. I do not feel as though the current approach is the best one.

So in short, this site should advertise to players or devs, not both, because It seems to me that we have learned the trying to appeal to both doesn't really do good for either. Imo it should advertise strictly to devs and use game sites (Springinfo, ZK, Evo, Bar, NOTA, Etc) as sister sites, such as "Hey here are some cool projects using this engine!", but the game sites should be add-on mentions, not front and center. You could aggregate news from these sites if you wanted, but that has been tried and tbh there isn't really much point if we are marketing strictly to devs.

AF wrote:True, if you want to participate in the current lobby system, settle on all the conventions and baggage, implement the TASSERVER protocol as it currently stands, then you've got a lot to implement and catch up on regardless of what language or platform you're working with

Just want to point out that there's a TASSERVER protocol implementation available for (Spring) lua: https://github.com/gajop/liblobby

AF wrote:At this point the engine is now compatible with the vast majority of existing matchmakers and lobbies out in the wild, and content devs can customise as much as they like.

Outside of ZK, the only known matchmaking is the one being developed by Nemo (bot-side) + me (lobby + uberserver side) and it only works for the ingame lobby. No other lobby dev has expressed direct interest in it.

AF wrote:Meanwhile the technical burden of the existing lobbies is massively cut down as is their maintenance cost, and the server protocol can be reduced to less than a quarter of its existing footprint

Reducing the server protocol? What do you mean exactly? The less defined things are, the worse off we are probably. If you want a very flexible lobby protocol it's probably best to write your own from scratch, otherwise it's good for it to be well-defined.

There are numerous lobbies out there, not to mention the ones built for OTA, gameranger, the SteamWorks lobby system, etc etc Spring isn't the only ecosystem that has lobbies and this isn't something unique to us. A lot of games manage the battle, and their lobby and matchmaking systems focus on listing battles and channels, rather than what our lobbies do with map pickers, battle chat, teams, allies etc

As a result, the entire battle section of the protocol can be eliminated, preserving only the join leave create and list protocol components, which can be simplified further, and the engine can then be used with the full spectrum of external systems, as well as integrations becoming easier

Underwhelming drawing of reusable components architecture, allowing the ecosystem to grow, bringing differences of opinion regarding direction together by allowing the use of a core of libraries for multiple types of lobbies, using multiple servers/protocol versions. A core of in memory data structures holds state regarding server connection, available games and maps, their versions, while the UI is a mere 'thin client' that can show or not show the data, but the core is shared.

MetalSucker wrote:Underwhelming drawing of reusable components architecture,

Use the program called Dia, it's really that good.