Let me offer some thoughts about this idea. "1) Alter how multiplayer games end in such a way that they must either declare a winning side or have the players select a "continue later" option. This will allow much of the game data that is already collected to be used more directly for analysis. Many games will no doubt never finish "successfully", but if most players simply declare a winning side via some interface at the end of the game we should get many good data points."
On the ladder systems that currently exist, the same issue is confronted, that we basically cannot automatically analyze from a replay who won, and so players are required to self report. If the program is changed to try to force this to happen in a replay it would be great in theory, but I am somewhat skeptical. What will you do in case of a crash or a network disconnection? I think more games end this way than you might guess. "2) Render as much data useful to analysis as is currently possible. Some highlights of very useful things: i) By era, which races win the most and on which maps. ii) Which side(s) win the most on which maps. iii) Which eras and/or maps see the most games, and their various full-game completion rate. iv) If possible, what difficulty (if applicable to MP campaign or UMC) was selected for the game." If your interest here is aggregating stats for multiplayer balance, you might want to look at an add-on Tekelili has made called Ladder2000 which analyzes ladder stats among top tier players over the course of a year or more (I think) and answered questions (i), (ii), (iii) above and many variations in an interesting and powerful interactive framework. Although he doesn't continue to update it, because I guess it is tedious, it might not be hard to automate that. (iv) above is outside the scope of his project, and I guess (iii) might be more interesting for the general mp server. It would also be interesting to know (i) and (ii) for general mp server games, but most likely not for mp balance reasons. "3) Create a medium to display and filter the data (preferably web-based). Allow for filtering of many different variable with an eye toward being able to expend and add display variables in the future." Tekelili did a good job with this, although it is a bit wonky that it is a wesnoth add-on rather than a website. If you decide to make a website you still might like to look at how he organized his system. Best, Chris Beck On Thu, Feb 13, 2014 at 11:27 AM, George Birthisel < [email protected]> wrote: > Based on a conversation with Soliton and some others yesterday, I propose > this GSoC project idea: > > * Automated collection and display of multiplayer game data. > > The primary use for this would be for multiplayer balancing both for > developers and for authors of UMC. This breaks down into 3 parts that I > can see. > > 1) Alter how multiplayer games end in such a way that they must either > declare a winning side or have the players select a "continue later" > option. This will allow much of the game data that is already collected to > be used more directly for analysis. Many games will no doubt never finish > "successfully", but if most players simply declare a winning side via some > interface at the end of the game we should get many good data points. > > 2) Render as much data useful to analysis as is currently possible. Some > highlights of very useful things: > i) By era, which races win the most and on which maps. > ii) Which side(s) win the most on which maps. > iii) Which eras and/or maps see the most games, and their various > full-game completion rate. > iv) If possible, what difficulty (if applicable to MP campaign or UMC) > was selected for the game. > > 3) Create a medium to display and filter the data (preferably web-based). > Allow for filtering of many different variable with an eye toward being > able to expend and add display variables in the future. > > ~~~~~~~~~~~ > > That's the idea, perhaps it can be written better, I am quite happy to let > anyone edit it and post it if it seems reasonable, or I will await feedback > here and on IRC. > > George (happygrue) > > > On Wed, Feb 12, 2014 at 3:50 PM, Mark de Wever <[email protected]> wrote: > >> On Tue, Feb 11, 2014 at 08:24:49PM +0100, Nils Kneuper wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > Hey folks! >> > >> > The proposal is submitted to google, but what is really lacking is the >> list of >> > ideas [1]. So far only three "ideas" are listed which will not be >> enough. >> > Could you please make sure to add more ideas? You only have until Friday >> > morning to get stuff done. >> > >> > The currently available ideas: >> > * UMCD >> > * Game Engine: Unify SP and MP >> > * Other: Your own ideas >> >> I added: >> * The sprite sheet idea, proposed before in 2010 and 2011 [1]. >> * Since there were no objection against SDL2*, I also added it as a GSoC >> idea [2]. The goal is to find a student who will work on a walled of >> sub project in this project. >> >> > As you can see this will probably not be enough to be accepted in GSoC. >> Maybe >> > someone can add some AI related idea? What about some work on the >> editor or >> > the eclipse plugin? >> >> I would welcome an AI idea, the AI always a subject that attracts a lot >> of students. >> >> *) I'm somewhat time constrained so will reply in the SDL2 thread when I >> have more time. >> [1] http://wiki.wesnoth.org/SoC_Ideas_SpriteSheets2014 >> [2] http://wiki.wesnoth.org/SoC_Ideas_SDL2 >> >> -- >> Regards, >> Mark de Wever aka Mordante/SkeletonCrew >> >> _______________________________________________ >> Wesnoth-dev mailing list >> [email protected] >> https://mail.gna.org/listinfo/wesnoth-dev >> > > > _______________________________________________ > Wesnoth-dev mailing list > [email protected] > https://mail.gna.org/listinfo/wesnoth-dev > >
_______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
