Difference between revisions of "SoC Ideas Multiplayer Data Analysis"
(→Additional Information) |
(→Additional Information) |
||
Line 35: | Line 35: | ||
#*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. | #*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 | + | '''FAQ''' |
− | Q: Where in the code the data saving takes place? | + | |
+ | '''''Q: Where in the code the data saving takes place?''''' | ||
+ | |||
A: src/server/game.cpp: game::save_replay() | A: src/server/game.cpp: game::save_replay() | ||
+ | |||
+ | '''''Q: How will I open up the archived replays for data analysis?''''' | ||
+ | |||
+ | A: Using a WML parser you'd go through the replay like the game proper and collect data you think is useful (storing it in the database). | ||
+ | |||
+ | '''''Q: Where would the data analyzation tool live?''''' | ||
+ | |||
+ | A: The analyzation tool would probably be run on the server where also wesnothd runs but it's an independent process, since wesnothd just saves the replay data it has no real idea what's in it. | ||
==Whom to ask about this== | ==Whom to ask about this== | ||
Soliton, happygrue (IRC is preferable) | Soliton, happygrue (IRC is preferable) |
Revision as of 16:03, 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()
Q: How will I open up the archived replays for data analysis?
A: Using a WML parser you'd go through the replay like the game proper and collect data you think is useful (storing it in the database).
Q: Where would the data analyzation tool live?
A: The analyzation tool would probably be run on the server where also wesnothd runs but it's an independent process, since wesnothd just saves the replay data it has no real idea what's in it.
Whom to ask about this
Soliton, happygrue (IRC is preferable)