Dev meeting minutes 2012-02-14

[zerver]

Present: <abma>, <hoijui>, <jk>, <tobi>, <zerver>



<abma> hi all!
<abma> so... start?!



=== Release plan ===
<zerver> hi
<abma> whats missing? we already have a release branch...
<abma> maybe jk?
<zerver> looks good, a release is fine with me
<abma> only things i personally would like to add is the pull-requests before release
<zerver> I'm working on one minor issue with builders getting stuck in repair command
<tobi> abma: yeah?
<abma> anything missing for the release?
<abma> hmm
<zerver> :)
<abma> jk makes the release?
<abma> if so, would be nice if that pull requests could get in
<zerver> slap him with peewee until he makes the release
<abma> jk: anything to say about the release?
<jk> should happen AFAP

Conclusion: 86.0 will be any day



=== how to make meetings not suck ===
<abma> ideas?
<abma> beeing afk the whole time makes it senseless...
<zerver> we may need a secretary, one who initiates the meeting, right now it is borderline ridiculous lazy with late arrivals and no one in charge
<abma> arrival was ok today
<abma> 21:30 and all where here...
<zerver> yeah, and kudos to you for starting the meeting
<zerver> always starting the meeting at an exact time may also help
<abma> hmm.... thanks, but it seems a bit senseless currently...
<abma> i try a bit monologue stuff...



=== stats of springrts.com ===
<abma> thanks a guy and tobi piwik is running fine
<abma> piwik is some website analyzer tool
<tobi> someone will need to pull on people for meeting, and ensure meeting topic aren't endlessly discussed
<tobi> so that whole meeting can be done in < 1 hour
<abma> only bad thing is, the implementation of piwik is fail: it requires huge amounts of memory, if i want to select it for larger time-ranges it crashes
<abma> [RoX]Tobi: wip
<tobi> abma_irc: you're doing that well now :)
<abma> but the stats that are a bit interesting too, even if the time-range is so low... currently only a week is possible
<abma> most interesting maybe: top three keywords: 1: spring rts 2: spring engine 3: ta spring
<abma> taspring / spring total annihilation is in the top 10, too, soo maybe we should think about renaming the engine to something else and make an installer for the "framework"
<abma> (but that shouldn't be discussed now)
<abma> top links from external pages are, from google, second from the english wikipedia page...http://en.wikipedia.org/wiki/Spring_%28game_engine%29
<abma> thats it for that point...

Conclusion: We have stats it seems



=== is spring still beta? http://sourceforge.net/projects/springrts/ ===
<abma> imo it isn't... but thats maybe just some "visual" change on that page
<zerver> we have no "b" in the version number, so no not beta
<abma> ok, then i change that...
<zerver> we still have enough bugs though
<abma> yeah, sure
<abma> we are stable now
<abma> uhm
<hoijui> about gajops pull request.. i am in contact wiht him.. it misses some stuff (CMake part that calls the AWK script has to be done)
<hoijui> i said i woudl do that (a few days ago, did not yet get to it)
<abma> ok, thanks

Conclusion: Spring is not beta, and not alpha, but has bugs



=== how to avoid confusion for players, that they should not start spring without a script.txt? ===
<abma> was added by me...
<zerver> but we have the "start lobby" button right?
<abma> that button is gone :D
<zerver> oh
<abma> was to buggy...
<zerver> maybe we should make a real built-in lobby then
<abma> thats still on the todo... luasocket maybe helps there a bit
<abma> imo a full customizeable startscreen/menu would be required to fix that in a clean way
<zerver> a simple one, that game makers can customize to their liking, not too fancy so that springlobby folks get sad about unfair competition
<abma> maybe my topic is wrong...
<zerver> this is like internet explorer vs firefox
<abma> where to go with the engine?
<zerver> only that we bundle firefox with our installer, so we are > M$
<hoijui> somewhere where its always warm
<hoijui> but where we all fit in, not like mummies belly
<hoijui> south america?
<abma> +1 for a warm climate
<abma> (-1 for pollution)
<zerver> Egypt is okay atm
<hoijui> you mean the airplane stuff?
<abma> zerver: yep, thats maybe the question... what to do with the installer
<abma> i already tried some time ago, to allow downloading games / maps, but as i did it, there was to many maintainance work needed
<zerver> DL maps/game already in installer?
<abma> yeah, for example
<abma> or maybe at the end of the installation of the engine / startup of the lobby
<zerver> we bundle 8V8BADSD :D
<abma> lobby-devs seems to have no real opinion
<hoijui> yeahh.. onclick on hte website, some loading bar pops up, and when its done, oyu are in ba8v8dsd
<zerver> instant action...
<hoijui> why would lobby devs have to decide what we put in the installer?
<hoijui> as of games or maps
<abma> we could also just slim-down the installer (remove the lobbies) as there are already lobbies that can automaticly install the engine
<abma> this would reduce many confusion to players if there is only a lobby-download
<abma> yeah, i mostly talk about win32, as most players are there
<hoijui> then we would have to supply hte lobby installers on hte site?
<zerver> I can imagine auto-DL code requires much maintenance
<hoijui> or just redirect to their sites
<abma> [ARP]hoijui_irc: just redirect...
<abma> its not a big change here, mostly removals
<hoijui> what would be the benefit of that?
<abma> fewer confusions for players
<hoijui> user has to lcick one time more, install a lobby, and ends up wiht the same stuff
<hoijui> how so?
<abma> most players seems to still expect, that spring is a game
<hoijui> mm ok...
<zerver> A very customizable game
<hoijui> i cant see how redirecting them to the lobby sites makes any difference
<hoijui> they woudl think the lobbies are games then
<zerver> multiple downloads just add confusion I think
<abma> [ARP]hoijui_irc: http://www.youtube.com/watch?v=FKk1FS6r8-g
<abma> (Let's play springlobby)
<abma> just one ...uhm.. example
<hoijui> hehe :D
<hoijui> ok... that prves my point, right?
<hoijui> proves*
<abma> yeah...
<abma> i would like to stop that topic here
<hoijui> ok
<abma> can be discussed endless... its more to think about / get feedback maybe
<abma> also, the hour is over :D
<zerver> We could just emphasize in the current game menu, that external lobby should be started for multiplayer
<zerver> Or add a "multplayer" button that just quits an pops up message box "please start the external lobby..."
<abma> i guess there are many more solutions, but i'm also no sure, whats best
<hoijui> create a script.txt on the fly
<abma> [ARP]hoijui_irc: thats already done when you click on test?
<hoijui> yeah true
<abma> yeah, its only created in mem, but.... uhm?
<abma> i don't understand
<hoijui> yeah, no difference :D
<hoijui> is there more topic?
<abma> release maybe...
<abma> but jk seems to be afk
<hoijui> mm
<hoijui> i want cake!
<abma> me too :)
<abma> aah

Conclusion: spring.exe start menu will need to be changed somehow, sometime



=== anything against updating changelog for test-releases? ===
<abma> i ask, because it felt stupid, to create a changelog for test-releases on the wiki-page
<hoijui> hmm... right
<hoijui> i would say that makes sense, yeah
<hoijui> later.. jsut change the version number, on a real release
<hoijui> no additional work, for us, in the end
<abma> ok...
<zerver> yeah

Conclusion: changelog for test release is OK



=== win: make unitsync static link its dependencies, so it doesn't depend on any extern dll? and so doesn't conflict with the lobby's dependencies. ===
<abma> maybe jk wakes up...
<jk> I am here
<abma> jk: this topic was added by you?
<jk> yup
<abma> are there drawbacks when doing so?
<abma> i guess the file will be much larger
<abma> but that should be all?
<jk> it is final assumption of the unitsync crash in modoptions
<jk> lobby & unitsync linked to libstdc, but both expected different versions of it
<jk> so it's better when unitsync doesn't runtime link it at all
<zerver> static link is so much cleaner
<abma> ok...
<hoijui> to me it seems cleaner if the lobby would do that instead
<hoijui> not all lobbies are native
<hoijui> and.../
<hoijui> this seems like a problem that would happen to many other softwares aswell.
<hoijui> is this the stadnard approach? static linking at least all but one part of a software?
<zerver> In my world everything would link static, dependency is hell
<hoijui> should not rather the lobby be compiled at the same time/on the smae system as unitsync, isntead?
<jk> imo dll's shouldn't have any dependencies themselves
<hoijui> but.. all dlls depend on libstdc, no?
<jk> but on different versions
<jk> windows is not linux
<jk> the dll is in 99.999999% not generated on the same PC as the lobby is
<abma> most linux distributions don't like static linked libs / programs, because if one lib changes everything has to recompiled
<abma> (just my 2 cents)
<zerver> that is the problem with linux, the libs change too much
<hoijui> i kind of though/hinted towards.. we could do that
<hoijui> buildbot could also compile springlobby
<hoijui> actually.. as we use koshis server.. doesnt that mean it is already the case?
<hoijui> to much change.. BAAAD
<hoijui> stagnation... goooooood
<zerver> :) the windows API tends to be very backwards compatible compared to linux
<abma> i want popcorn!
<abma> jk: does the crash currently only happen on windows?
<abma> if so, try to static link for win32 only?
<jk> check the topic
<abma> uhm
<abma> somebody changed it!
<jk> lol
<abma> did the lobby devs try to static link it?
<jk> ?
<jk> it has nothing to with the lobby->unitsync linking
<abma> i mean, did they static link their lobby?
<abma> unitsync loading has to be dynamic... sure
<jk> it is just that both lobby & unitsync depend on libstdc, but both want different versions -> runtime fail
<tobi> hoijui: it's koshi's desktop that compiles spring, his server compiles springlobby (afaik0
<hoijui> ok, so possible solutions: ensure that loby nad unitsync are compiled on the smae machine (and thus same libstdc)
<hoijui> ahh k, thanks tobi
<abma> [ARP]hoijui_irc: imo thats not possible
<hoijui> staticly link SpringLobby
<hoijui> statically link unitsync
<hoijui> yeah, first thing is too hard i guess
<hoijui> or unpractical.. impssible
<hoijui> the other two, only for windows
<hoijui> btw, let me say at this point, that in java, oyu could circumvnet this problem, simply by ...
<hoijui> :D
<hoijui> i dont care, i am fine with either
<abma> jk: imo you should decide
<abma> i would slightly prefer the lobby links staticly, because much more stuff depends on unitsync (more possible side-effects)
<abma> but ... yeah, don't care :)
<jk> me decide?
<jk> I have like zero experience with dll/so and no in lobby dev
<abma> then maybe a lobbydev has to try out, what works fine?
<jk> yup
<abma> as start maybe http://en.wikipedia.org/wiki/DLL_Hell :D
<abma> so... i guess we are finished...

Conclusion: No consensus, other than DLL HELL

[smoth]

Running spring.exe is how I test 90% of the time but would accept the loss of it if you guys would just give us lualobby so I can get my "online match" menu item started :).

[Beherith]

A MEETING FROM THE FUTURE!

Yeah, spring.exe is on my quick launch bar and is probably the most often used button.

[abma]

see http://springrts.com/phpbb/viewtopic.php?f=71&t=27650 for a report of piwik.

[knorke]

Conclusion: spring.exe start menu will need to be changed somehow, sometime

imo when just spring.exe is started, have it display "Use the lobby to play [ok]" and then have it exit.
The current menu would be accesible by startparameter eg spring.exe -testmenu (so game makers change their shortcut and otherwise everything stays the same)

<abma> top links from external pages are, from google, second from the english wikipedia page...http://en.wikipedia.org/wiki/Spring_%28game_engine%29

Spring is in"see also" of TA wiki page.
guess that brings quite some visitors to Springs wiki page and then to springrts.com

Just seen the german wiki...wtf.
On german wiki on the TA article Spring is used to show TA gameplay:
http://de.wikipedia.org/wiki/Total_Anni ... elmechanik

On the spring page itself 1/4 is about describing the gameplay of TA (commander, nano, etc)
http://de.wikipedia.org/wiki/Spring_%28Engine%29
So imo no wonder Spring is seen as "new TA" so much.

[smoth]

ha ha the german article has my early version of river valley and here I thought no one liked that map.

[zerver]

A MEETING FROM THE FUTURE

Hmm, yeah good point, but it was the 14th in my time zone when the meeting ended.

[Forboding Angel]

Ok, I will love you guys forever if:

A: You kick the lobbies out of the spring installer, and dissolve the installer itself into a portable zip (seriously, installer is not needed. Spring is a tool, not the end product). For now I'll settle for the lobbies just getting kicked out.

B: Static link EVERYTHING on linux (making isolated/portables realistic). I don't care about windows because windows doesn't cry like an 8 year old girl about you having 2 copies of the same lib on your system.

C: Do like you talked about with built in start stuff (lobby?).
Maybe spring could be told to exit w/o a script and someone else could write a startscript generator that selects map game and ai. That should be fairly simple and do the trick.

[AF]

How to shutup the masses who complain about the 'spring download should be an SDK/Tool' argument

• Average Joe Player
  
  Is worried that no installer means no new players, and much harder upgrades to his/her game.
  
  Solution: The real problem is the game s/he plays has no installer. Fix this problem and they'll be quiet
• Engine Developers & Terminology
  
  Quibbles over the terminology, and believes the engine is not an SDK.
  
  Solution: The real problem is being overlooked here, instead sidestep and realise the problem you're trying to solve is not the problem the person is raising, their issue is not with how to package the engine, it's naming, so separate the issue of what it's called and the actual wares.
  
  My favourite idea on this front is to simply call it 'an RTS game engine', placing the emphasis on the word 'engine'. Remember that an SDK is a name for something, and it's not the only name that describes what you're wanting. Also different people have differing views of exactly what an SDK is. So instead simply state what the engine distribution should contain.
• Worried Content Developer
  
  Thinks no installer means their game will not get played
  
  Solution: The real problem is the lack of an installer for their game, or rather, the lack of documentation and help in allowing them to create appropriate installers. Help these people escape the hole community convention dug for them, or provide an alternative.
  
  Alternatively, they may intentionally be resisting the installer route, acknowledging it would be a good idea for their game in the future. Examples include WIP games that aren't intended for primetime. The solution here is to include instructions for how to set up an environment, and making it easier for setting up an environment to place their game into. Ironically, a portable engine installer is the easiest for windows users here.
  
• Concerned Forum Poster
  
  "It will fragment the community" s/he says.
  
  Solution:Time and time again we have seen this argument levelled against a project or idea, and as of yet, not once has it been proven true. Look at the various communities that already do this and recognise unfounded worries for what they are.

Otherwise asking for this will make little difference. When those problems are sorted out, it will make no difference if the lobbies are included or not, as what will really matter is which games a lobby is distributed with.

[gajop]

I think I disagree with you on many accounts. Mainly because people seem to forget that the "Spring" name refers to more than just the engine - it also includes the Spring network, forums, and so on.

The Spring network is what has the potential (with much of it already done) to be something akin to Steam, and I think that would be great.

Now with that in mind, regarding specific points:

How to shutup the masses who complain about the 'spring download should be an SDK/Tool' argument

• Average Joe Player
  
  Is worried that no installer means no new players, and much harder upgrades to his/her game.
  
  Solution: The real problem is the game s/he plays has no installer. Fix this problem and they'll be quiet

The "average" player doesn't actually desire a manual installation process, he just wants to play his game. I believe that some sort of integrated and improved lobby and rapid could lead to better game exposition. F.e, standardizing some sort of way of displaying (with media) and advertising games, as well as an easier way to search for games and so on.
If players can use a lobby to find new games (either through standalone lobby or one that came with a game found on the web f.e), without having to go to some cryptic sites and use that game's installer that does god knows what with their current resources, we actually may improve user experience.
Currently what we have is a bunch of lobbies tailored for specific games/OSes, with only SpringLobby seeming like the official, but lacking some important development (rapid f.e). (This is where zero-k was smart when creating web pages, which could easily be integrated into other lobbies).

[*]Worried Content Developer

Thinks no installer means their game will not get played

Solution: The real problem is the lack of an installer for their game, or rather, the lack of documentation and help in allowing them to create appropriate installers. Help these people escape the hole community convention dug for them, or provide an alternative.

Alternatively, they may intentionally be resisting the installer route, acknowledging it would be a good idea for their game in the future. Examples include WIP games that aren't intended for primetime. The solution here is to include instructions for how to set up an environment, and making it easier for setting up an environment to place their game into. Ironically, a portable engine installer is the easiest for windows users here.

What community devs (depending on type) need to make is a graphically pleasing, competitive/interesting game and lobby support to play these games easily (matchmaking! - that's why !join is being pushed).
A couple have succeeded on the first part, but the matchmaking still sucks.

[*]Concerned Forum Poster

"It will fragment the community" s/he says.

Solution:Time and time again we have seen this argument levelled against a project or idea, and as of yet, not once has it been proven true. Look at the various communities that already do this and recognise unfounded worries for what they are.[/list]

Because community is being fragmented. We have less total players than we did a year ago, and it seems like they're divided into at two major games - meaning less players per game.

Now regarding what forboding said, we may want to look at engines like resources (but shared resources!), instead of it being the main product. You can potentially have multiple engine versions (again something that zero-k seems to be doing right), with each mod/game using only one at a time (but again, shared, use the official released versions please, no need to add more unnecessary downloading).

[Forboding Angel]

Gajop, you're off base. Spring is like Source. Just think of it in those teams. However, we do not have steam (although Desura likes having spring games, so effectively Desura is our steam).

[gajop]

Gajop, you're off base. Spring is like Source. Just think of it in those teams. However, we do not have steam (although Desura likes having spring games, so effectively Desura is our steam).

well, "Spring" the engine is similar to Source engine, but Spring the network infrastructure (or how would you call it?) is similar to Steam (you have rapid, SD, lobby servers, lobby clients, etc.)

[knorke]

However, we do not have steam (although Desura likes having spring games, so effectively Desura is our steam).

The lobby is steam. In the lobby you can see what other people are playing and you can chat about all games. Even if you are currently playing game A you can see that your friends are playing game B, just like in steam.

Spring is more like a gameboy (or gameboy emulator): there is some program thing and you throw in new playable content.
The only reason why that does not work that good for new players is because "everything must be better."

[PicassoCT]

well, tehn you have two options:

Make all the things better (very realistic option) A:
For the first option you need a company - and a cathedral.

or Make a big red "Panic" button, in every lobby that gets you support. B:
For this you need people. Lots of them, willing to give a shit. Oh, wait.. shit i get the first shift right.. Me and my big mouth ...

[smoth]

just want to put my nickle in here, once I get lua lobby, gundam is going to abandon the fing lobbies. They are great and I will regularly hang in the but I don't see any merit in marrying my project to one.

<3 springlobby and zkl is neat but doesn't support map options. What I want is in game ability to leave a match to join another or to host.. you know like NORMAL Games. The lobby is neat and all and maybe the lobbies could start being like steam but until my game can handle the join/leave/host shit.

[AF]

Gajop:

• A cryptic installer from a cryptic site will never be installed unless the player is stupid, that is not an argument for an all encompassing engine installer, that's a dramatic failure of a content developers marketing, the two aren't the same. A simple installer from an elegant site however..
• Community player count has been falling very slowly for a long time, that isn't community fragmentation, that's community retraction. Zero-K and BA don't split the community, there's a substantial amount of crossover, and people can play more than one game.
  
  I remember when I was a child and I played a pokemon game. This choice has crippled me, since I wish I could play BA, but as a Pokemon player, I am simply incapable of comprehending a non JRPG game that doesn't involve catching monsters, that wasn't made by Nintendo.
  
  We've had multiple games for a long time, and yet the forums are still here, the engine still gets updates, and the world keeps on turning.
• You don't need everybody on the same server. Spring had to start somewhere? Spring didn't die because of a chicken and egg problem of there's no players in the lobby we've just built, so nobody will play games, so nobody will go into the lobby etc etc. There was no Proto Spring rival engine that was massacred by the arrival of the spring engine, and stole their players
• The worst possible scenario envisioned by the fragmentation people has already happened. OTA still lives. TAU is still alive, it's still played, people still make TA mods.
• Making it easier for a person to install game A means that they enter the community faster. Game installers and ecosystems make springs meta-community bigger and increase transference between different games. It was a big factor in OTAs modding success, but we're failing to capitalise on it here despite us having infinitely more modding power.
• The lobby route has already been tried. Great leaps and bounds have been made in making these things more accessible, but it all falls apart when you realise a huge proportion of a potential playerbase for an RTS will never go to multiplayer, and a significant portion will not try until they feel they can best the AI. In a community where most games have poor AI or no AI, and where the means of acquiring new content is hidden behind the multiplayer lobby (which the user won't click because they don't want to go online and play against other players), the player is thus unable to even reach these improvements and the ones you're suggesting. Ironically when this problem is tackled, its the same people touting these ideas that try to stop the change, despite the self defeating nature.

Fragmentation is a scaremongering tactic. In reality we loose more people to poor marketing, inconsistent instructions, poor UI, and the number one reason: boredom. Played DSD everyday for 6 months and know nothing else? Not everybody can play a game forever, no matter how much they love it.


Adding steps and hoops to jump through for new people in the name of keeping the community as tight knit as possible is not a scalable way of growing, or of attracting new players. It keeps us small as a community, limits growth, and stifles new ideas, slows engine development, and prevents necessary changes from happening.

All in all these 'solutions' do not benefit the community or increase player numbers. They merely aid existing players who are already here stay exactly where they are and do what they already do, something which they can continue to do without any change anyway.