Difference between revisions of "SoC Ideas Multiplayer Data Analysis"
From The Battle for Wesnoth Wiki
(→Improve the automated collection and display of multiplayer game data) |
(→Additional Information) |
||
| Line 22: | Line 22: | ||
==Additional Information== | ==Additional Information== | ||
| − | The primary use for this would be for multiplayer balancing, both for developers and for authors of UMC. This breaks down into 3 parts | + | The primary use for this would be for multiplayer balancing, both for developers and for authors of UMC. This breaks down into 3 parts. |
| − | # 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" due to network disconnections or savegames that are never reloaded, 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. | + | # '''Implement some way in the Wesnoth client to select a winning side (when it is not otherwise obvious).''' |
| − | # Store in a database as much data useful to analysis as is currently possible. Savegames are stored in [[SavefileWML|WML]], which can be parsed by C++, Python and Perl. Some highlights of very useful things: | + | #*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. Thought needs to be put into how to handle this to include different types of games (regular duels as well as custom scenarios that might end with special conditions). 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" due to network disconnections or savegames that are never reloaded, 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. User Made Content (UMC) would also provide good data if the [end_level] tag is correctly implemented. |
| − | #* By era, which factions win the most and on which maps. | + | # '''Implement a replay data analyzation tool that processes replays and save what it finds out in a database.''' |
| − | #* Which side(s) win the most on which maps. | + | #*Store in a database as much data useful to analysis as is currently possible. Savegames are stored in [[SavefileWML|WML]], which can be parsed by C++, Python and Perl. Some highlights of very useful things: |
| − | #* Which eras and/or maps see the most games, and their various full-game completion rate. | + | #** By era, which factions win the most and on which maps. |
| − | #* If possible, what difficulty (if applicable to MP campaign or UMC) was selected for the game. | + | #** Which side(s) win the most on which maps. |
| − | # While the first two parts are most important, if time allows it would be great to 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. | + | #** Which eras and/or maps see the most games, and their various full-game completion rate. |
| + | #** If possible, what difficulty (if applicable to MP campaign or UMC) was selected for the game. | ||
| + | # '''Implement some frontend to query/visualize the data in the database.''' | ||
| + | #*While the first two parts are most important, if time allows it would be great to 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. | ||
| + | |||
| + | FAQ: | ||
| + | Q: Where in the code the data saving takes place? | ||
| + | A: src/server/game.cpp: game::save_replay() | ||
==Whom to ask about this== | ==Whom to ask about this== | ||
Soliton, happygrue (IRC is preferable) | Soliton, happygrue (IRC is preferable) | ||
Revision as of 15:42, 3 March 2014
| This page is related to Summer of Code 2014 |
| See the list of Summer of Code 2014 Ideas |
| This is a Summer of Code 2014 Idea |
Contents
Description
Improve the automated collection and display of multiplayer game data
Page for the idea: SoC_Ideas_Multiplayer_Data_Analysis
Multiplayer games are currently archived. This includes lots of interesting and potentially useful data, including recruits, deaths, number of turns and other things. The only way to access this information currently is parsing the WML one save file at a time. Additionally, which side(s) won the game is only recorded in some cases. We would like to record which side(s) won or lost (for as many games as possible) and then display useful information about these games for balancing and feedback purposes.
There are no submitted student proposals for this idea
Additional Information
The primary use for this would be for multiplayer balancing, both for developers and for authors of UMC. This breaks down into 3 parts.
- Implement some way in the Wesnoth client to select a winning side (when it is not otherwise obvious).
- 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. Thought needs to be put into how to handle this to include different types of games (regular duels as well as custom scenarios that might end with special conditions). 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" due to network disconnections or savegames that are never reloaded, 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. User Made Content (UMC) would also provide good data if the [end_level] tag is correctly implemented.
- Implement a replay data analyzation tool that processes replays and save what it finds out in a database.
- Store in a database as much data useful to analysis as is currently possible. Savegames are stored in WML, which can be parsed by C++, Python and Perl. Some highlights of very useful things:
- By era, which factions win the most and on which maps.
- Which side(s) win the most on which maps.
- Which eras and/or maps see the most games, and their various full-game completion rate.
- If possible, what difficulty (if applicable to MP campaign or UMC) was selected for the game.
- Store in a database as much data useful to analysis as is currently possible. Savegames are stored in WML, which can be parsed by C++, Python and Perl. Some highlights of very useful things:
- Implement some frontend to query/visualize the data in the database.
- While the first two parts are most important, if time allows it would be great to 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.
FAQ: Q: Where in the code the data saving takes place? A: src/server/game.cpp: game::save_replay()
Whom to ask about this
Soliton, happygrue (IRC is preferable)