SoC Ideas Multiplayer Improvements 2011
|This page is related to Summer of Code 2011|
|See the list of Summer of Code 2011 Ideas|
|This is a Summer of Code 2011 Idea|
Reengineer Wesnoth's multiplayer engine
More info at SoC_Ideas_Multiplayer_Improvements_2011
Wesnoth includes a lot of multiplayer content, like 'standard' scenarios, custom scenarios and multiplayer campaigns. However, when creating a multiplayer game, the player's options are highly limited - for example, it is not possible to select the difficulty level before starting the scenario, and it is not possible to allow the scenario to set what 'variables' can be customized by players before game is started (there's only global 'use map settings' flag and some control over sides). We want to reengineer the architecture of Wesnoth's multiplayer engine to allow it to support those things.
There are no submitted student proposals for this idea
Difficulty levels in MP
Wesnoth includes a lot of text data config files which need to be 'parsed' before game starts. Difficulty needs to be known at the time we parse those config files. Currently, we parse those files before entering the multiplayer lobby. As a consequence, we cannot select difficulty in multiplayer game (data's already parsed at the point when the game is created). Note that parsing takes a lot of time, so, if we do it while already connected to MP server, we need to add workarounds to ensure it doesn't think the client is dead.
Game creation screen
We want the multiplayer game creation screen to be different and better. We think that we need different screens for normal MP scenarios, 'custom' MP scenarios and for MP campaigns.
Unification of multiplayer and singleplayer in the engine
A really long-term goal would be to reduce the complexity of the codebase by merging SP and MP (making SP a special case of MP and allow seamless transition between both). There is a number of steps which could be taken to gradually move closer to this goal.
Under the hood
Wesnoth uses a pre-processor to organise its file hierarchy and to make use of macros. This system is used to load only a certain subset of all available WML code depending on the current needs.
A freshly started Wesnoth instance does neither know about the inners of single player campaigns nor multiplayer content. The player is able to choose between the mainline campaigns before the wml tree gets re-parsed because the [campaign] tag hosted in the campaign's _main.cfg contains all needed information and it's parsed from game start.
But the engine does only read the _main.cfg when the whole directory was included by a pre-processor directive. If you allow me to show you some wml code you will discover that the rest of the campaign is guarded by a pre-processor symbol:
. . . [campaign]
id=Heir_To_The_Throne . . . define=CAMPAIGN_HEIR_TO_THE_THRONE . . .
[/campaign] . . .
- ifdef CAMPAIGN_HEIR_TO_THE_THRONE
Whom to ask about this
Ask Crab_ and/or fendrin on #wesnoth-dev
Possible pre-gsoc tasks
- Talk with devs, users, and MP devs about UI design of MP creation screens and show some prototypes of game creation screens for MP campaigns, and custom MP scenarios
- Hack in a way to select difficulty before MP scenario start (doesn't need to be done cleanly, can be a prototype hack)
- Add a new attribute to game creation screen, to allow each player to select a number from 1 to 100 and make it available to WML code as a variable after scenario starts. Bonus points if you allow host to see the variable in the game creation screen and allow him to change it and lock it down for any particular player.
- write or download a small MP campaign and report on any MP campaign support bugs that you find.
- implement a lobby command to make the player who issued that command host and start a game with specified parameters, bypassing side selection screen.
- Make yourself familiar with the multiplayer port of the "Legend of Wesmere" campaign. Try to understand why and how the difficult setting is handled in it's case.