Difference between revisions of "User:Thunderstruck"

From The Battle for Wesnoth Wiki
m
Line 81: Line 81:
 
<h4>Additional improvements</h4>
 
<h4>Additional improvements</h4>
  
Some other things not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned in above and would be done at the very end if there is time left or possibly after GSoC ([[http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 forum members opinions]]).
+
Some other things not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned in above and would be done at the very end if there is time left or possibly after GSoC ([http://forums.wesnoth.org/viewtopic.php?f=15&t=38683 forum members opinions]).
  
And also there are some bugs who would be worth looking at ([[http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs]]).
+
And also there are some bugs who would be worth looking at ([http://forums.wesnoth.org/viewtopic.php?f=10&t=38487 bugs]).
  
 
=Timeline=
 
=Timeline=
 +
 +
TODO:
  
 
Now - May 27 (pre-GSoC):
 
Now - May 27 (pre-GSoC):

Revision as of 17:31, 22 April 2013


This page is related to Summer of Code 2013
See the list of Summer of Code 2013 Ideas



This is a Summer of Code 2013 student page


Description

thunderstruck's proposal draft

The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support.

I propose to make developing multiplayer campaigns as easy as singleplayer ones. I am going to do that by enabling Wesnoth's engine to handle [campaign] and [scenario] tag with their attributes when used for multiplayer campaigns with very little modification and implementing additional GUI elements to let users easily choose difficulties, save/restore games and manage network players.

This approach would fix a lot of bugs related to multiplayer campaign support and would improve the overall quality of multiplayer games in Wesnoth.

The Project

The multiplayer campaign support project would consist mainly of two parts: engine and GUI modifications. Those changes would be based on WML syntax changes and some other general improvements of multiplayer campaign support.

The higher priority tasks would enable LoW campaign to be ported to a new syntax.

WML syntax modifications

Enable top-level [campaign] and [scenario] tags to work properly with multiplayer campaigns.

  • [campaign] tag should contain an attribute called 'campaign_type' with a value of 'sp', 'mp' or 'both' to indicate the type of game campaign is made/adjusted for.
  • [scenario] tag's attribute 'allow_new_game' should be used to define whether the scenario could be played anytime or just after completing particular scenario(s) as it was used in [multiplayer] tag.
  • Extra boolean attribute 'custom_side' inside [side] tag to specify whether players should be able to choose multiplayer factions or not.
  • Extra boolean attribute in [scenario] tag called 'custom_turns' to specify whether players could swap not only the sides, but also the order of the turns of those sides.
  • 'save_id' attributes should be omitted from [side] tags.

Engine improvements

Deal with all changes of WML while keeping support for old ways to create multiplayer campaigns and solve the most important issues of multiplayer campaigns.

Higher priority tasks (listed by the order of implementation):

  1. Proper filtering of singleplayer and multiplayer campaigns using 'campaign_type' attribute to display them in appropriate dialogs and adjusting multiplayer create window accordingly.
  2. Enable multiplayer campaigns to use difficulty attributes inside [campaign] tag.
  3. Refactor or fix the current save/restore code of multiplayer campaigns to fix known problems.
  4. Enable network players management between scenarios.
  5. Enable 'extra_defines' attribute to work when used in multiplayer.

Lower priority tasks:

  • Add default values for 'allow_player' attributes to make SideWML less redundant.
  • Players' management window should suggest appropriate sides to the players (e.g. if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot) if possible. However, players should still be able to swap sides.
  • Allow the game to be played in custom turns (specified not by the campaign's designer, but the players).

GUI improvements

Tinker to work well with changes made to the engine and implement new elements where needed.

Higher priority tasks (listed by the order of implementation):

  1. In the multiplayer game 'maps to play' list, users should see only one option for one multiplayer campaign. Any chapters or scenarios which could be played without playing before should be displayed in additional dialog. Also users should see not the first scenario's name, but multiplayer campaign's name in that list option.
  2. Difficulties should be allowed to be chosen in the multiplayer game create window along with other options.
  3. Between every multiplayer campaign's scenarios players should be displayed with manage players window.

Lower priority tasks:

  • Players should not be allowed to choose any multiplayer factions if campaign's designer specified so, in order to keep campaign well balanced.
  • Players should be presented an option to modify turns of the sides.

Technical Considerations

TODO:

Here are some implementation details of major engine modifications.

Multiplayer create window:


Difficulties: To allow the game engine to use difficulties for multiplayer campaigns in the same way as for singleplayer campaigns, multiplayer create window and game settings should be adjusted to include proper GUI elements to display difficulty options and store/retrieve them.

Save/restore:

Players management: The new players management window should be created or the old one adjusted and be displayed between multiplayer campaign scenarios. The new window should let players to swap sides, kick/invite new players and possibly adjust other settings.

Extra defines:

Known Problems

  • Custom turns can be hard to implement due to scenarios having events or code tied to the side number.
  • Synchronization for some tags ?
  • The multiplayer campaigns written in the old way should still be compatible. ?

Additional improvements

Some other things not mentioned in the project could also be implemented to improve multiplayer campaigns support. They are of lower priorities than tasks mentioned in above and would be done at the very end if there is time left or possibly after GSoC (forum members opinions).

And also there are some bugs who would be worth looking at (bugs).

Timeline

TODO:

Now - May 27 (pre-GSoC):

  • Work on things related to project, but on those who could benefit users immediately even if the project would not be done at all.
  • Do a further research on project's implementation and make notes on that.

May 27 - June 17 (Community bonding period):

  • Resolve any ambiguities and issues (if any) with the project's proposal.
  • Start coding.

June 17 - early August:

  • Implementing high priority tasks.

early August - mid August:

  • Testing.
  • Fixing introduced bugs.
  • Port LoW to the new syntax.

mid August - 16 September

  • Implementing lower priority tasks.

16 September - 23 September

  • Write documentation.
  • Fix wiki pages.
  • More testing.

IRC

thunderstruck

Questionnaire

TODO: fill out the questionnaire, on your copy of this page. Question are here : SoC_Information_for_Google#Does your organization have an application template you would like to see students use?