SoC2013 thunderstruck MP Campaign Support

From The Battle for Wesnoth Wiki
Revision as of 18:03, 27 April 2013 by Thunderstruck (talk | contribs) (Created page with '{{SoC2013Student}} Category:SoC Ideas Multiplayer Campaign Support 2013 ==Description== <h4>Andrius Silinskas (thunderstruck) - Multiplayer campaigns improvements (draft)</h…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


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

Andrius Silinskas (thunderstruck) - Multiplayer campaigns improvements (draft)

The current multiplayer campaign support from both UMC developers/maintainers and players perspective is far behind comparing to singleplayer support. I propose a project to improve overall quality of multiplayer games by enabling singleplayer campaigns to be used as multiplayer campaigns and fixing most of the well known issues. The old multiplayer campaigns and scenarios should remain supported.

The Project

Introduction

The singleplayer campaign support surpasses multiplayer support because of the complexity involved in multiplayer codepath. As a result of this, not all important features are yet supported in multiplayer games and there are some blocking bugs which greatly affect the quality of the game. To address these issues, multiplayer campaigns should make use of CampaignWML and ScenarioWML. This use of new syntax would allow to use singleplayer campaigns and scenarios as multiplayer ones and vice versa. It would also make a ground to implement features missing in multiplayer e.g. difficulties and extra defines.

Furthermore, the relevant GUI elements should be improved and/or new ones introduced to cope with the game engine changes and allow better multiplayer experience from the user's perspective. The save/restore issues should be fixed as well and be of high priority since it is a problem for most of the multiplayer community.

This approach would increase an overall quality of playing multiplayer games and developing or maintaining them. The LoW campaign would be ported to the new syntax during the project.

WML syntax changes

Multiplayer campaign file


before:

#ifdef MULTIPLAYER
{~path/to/scenarios}

# details ommited..
#endif

after:

[campaign]
    # Indicates how campaign is allowed to play. Possible values: 'sp', 'mp', 'both'. 
    # Optional. 'sp' will be used as a default value.
    campaign_type="mp" 
    
    # details ommited..
[/campaign]


Scenario file


before:

[multiplayer]

    # details ommited..
    
[/multiplayer]

after:

[scenario]
    # details ommited..
    
    # Indicates a stand-alone multiplayer scenario
    # or campaign entry point.
    # Optional. 'yes' will be used as a default value.
    allow_new_game=yes
    
    [side]
        # details ommited..
        
        # Specifies whether players should be allowed to choose factions.
        # Optional. 'yes' will be used as a default value. 
        custom_side=no
        
        # Specifies whether players should be allowed to modify an order of turns for the sides.
        # Optional. 'no' will be used as a default value.
        custom_turns=yes
        
        # These should be no longer neccessary:
        # save_id=1
        # persistent=yes
    [/side]
[/scenario]

Game Engine Improvements

Important


New syntax support
Currently, engine recognizes singleplayer games by [campaign] and [scenario] tags and multiplayer games by 'MULTIPLAYER' define and [multiplayer] tag respectively. It should be modified so that it would load multiplayer games with only [campaign] and [scenario] tags and sort out what type of game it is by 'campaign_type' and 'allow_new_game' attributes.
Old syntax support
After multiplayer game configs start to use CampaignWML and ScenarioWML, the old multiplayer games would stop to be supported. To cope with this issue and to not introduce a new codepath just to support the old configs, the class responsible for upgrading old multiplayer games will have to be made. It should be called at loading time of game configs and upgrade all configs identified as an old multiplayer WML.
Further new syntax support
To enable multiplayer games to use 'difficulties' and 'extra_defines' attributes from CampaignWML, some parts responsible for singleplayer and multiplayer game set up would have to be merged. That would allow re-parsing of game config file and also setting up binary paths when creating a multiplayer game.
Saving and restoring
TODO:
  • loading the game from the non-host won't let to finish scenario


Players management
The game engine is currently able to provide only a basic players management and only during the connection phase of a multiplayer game. That means users don't have flexibility to change players between multiplayer campaign scenarios unless they reload the game. In order to improve the players management, the connection phase of the multiplayer game will have to be modified. It would have to lock some options to prevent changes if they haven't been allowed by campaign's developer (custom sides and turns). And most importantly, play campaign loop will have to be modified so that it is possible to go from the end of the scenario to the connect window. In addition, non-host players should also see similar connect window, instead of the current wait window, but only be able to modify their side settings. This would allow better user experience and would simplify the current multiplayer screens logic.
Multiplayer screens logic
before (taken from the multiplayer.cpp):
lobby <-> create <-> connect <-> (game)
lobby <------------> wait    <-> (game)
after:
lobby <-> create <-> connect_host   <-> (game)
lobby <------------> connect_player <-> (game)

Not-so-important


Additional players management
The game engine could be improved to automatically suggest appropriate sides for the players. It would benefit campaign players, because if the same side exists over multiple scenarios, the player who used to play for that side should be placed in relevant slot. However, players would still be able to swap sides. Furthermore, the host could be able to kick and invite players during the connection phase.
SideWML
Default values for 'allow_player' attribute should be added to make SideWML less redudant.

GUI improvements

Important


Create game window
The current window which lets user to create a new multiplayer game mix the all multiplayer campaigns and scenarios into one list. What is more, it won't display campaign's name in that list, but the first scenario of the campaign instead (or more scenarios in some cases). It could be fixed by displaying campaign as a single list item. For the cases when there are multiple starting points (scenarios with allow_new_game=yes), all the scenarios should be displayed in the additional dialog if campaign is chosed to be played. In addition, there should be two separate lists for campaigns and scenarios and the "Load game" option should be moved from the maps list and be represented as a button. Furthermore, additional option for difficulties should be added along other game options as a drop-down box.
Connect window
The current connect window would need to be modified so that it would be possible to disable/enable options for a non-host player. In this way, the window could be used not for only host player. After those modifications, wait window would no longer be necessary.

Not-so-important


Connect window
Additionally, connect window could include buttons/drop-down boxes for the host to invite/kick players.

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 above and would be done at the very end if there is time left or possibly after GSoC.

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

Timeline

May 3 - May 27 (pre-GSoC)
  • Work on things related to the project, but on those who could benefit users immediately even if the project is not going to be done at all.
  • Do a further research on project's implementation and make notes on that.
  • Exam period at the University.
May 27 - June 17 (community bonding period)
  • Resolve any ambiguities and issues (if any) with the project's proposal.
  • Start coding.
June 17 - July 25
  • Game engine: new and old syntax support, save/restore issues.
  • GUI: create game window.
July 25 - August 2 (midterm evaluation)
  • Testing.
  • Code clean-up and polish.
  • Port LoW to the new syntax.
August 2 - August 10
  • Game engine: players management.
  • GUI: connect window.
August 10 - September 16
  • Testing.
  • Code clean-up and polish.
  • Implementing 'not-so-important' tasks.
  • 'Additional Improvements'.
September 16 - September 27 (final evaluation)
  • Fix any left blocking bugs.
  • Write documentation.
  • Update wiki pages.

Goals

TODO:

ID NAME PRIORITY DESCRIPTION STATUS
0 Multiplayer WML

MANDATORY

Enable to load multiplayer games using CampaignWML and ScenarioWML. Involves tweaking playcampaign.cpp and game controllers. n/a
0 Refactor game controller

MANDATORY

Refactor parts of game_controller.*pp to unify the set up of singleplayer and multiplayer games. That would enable to re-parse multiplayer game configs and set up binary paths when game is loaded. n/a
0 Games lists

MANDATORY

Sort out between singleplayer and multiplayer games using 'campaign_type' and 'allow_new_game' attributes. Multiplayer campaigns and scenarios would be separated as well. n/a
0 Multiplayer WML upgrade 1

MANDATORY

Implement a utility class to upgrade old multiplayer WML configs to the new syntax. n/a
0 Multiplayer WML upgrade 2

MANDATORY

Use upgrader class to upgrade all relevant configs at a loading time. n/a
0 Multiplayer WML upgrade 3

MANDATORY

Write a script which uses upgrader to permanently upgrade stuff in 'data/multiplayer/'. n/a
0 Create window 1

MANDATORY

Add a new list for games to play and move campaigns to it, leaving scenarios in the previous one. n/a
0 Create window 2

MANDATORY

Remove "Load game" option from the scenarios list and place it in the save window as a button. Add drop-down box (ask mordante) for difficulties. Connect GUI changes with relevant code. n/a
0 Milestone 1

MILESTONE

Everything above to be done by July 10. n/a
0 TODO:Save/restore

MANDATORY

desc n/a
0 Milestone 2

MILESTONE

Everything above to be done by July 25. n/a
0 Multiplayer screens 1

MANDATORY

Modify playcampaign.*pp and multiplayer.*pp to display multiplayer connect window between multiplayer scenarios. Tweak the connect window to corectly respond to the new changes. n/a
0 Multiplayer screens 2

MANDATORY

Enable engine to display multiplayer connect window instead of wait for non-host players. n/a
0 Multiplayer screens 3

MANDATORY

Tweak engine to disable/lock relevant connect window options for host and non-host players. n/a
0 Multiplayer screens 4

MANDATORY

Implement a simple "I'm ready" system for connect windows. It would decide when to enable/disable "I'm ready" buttons and when to start a scenario. n/a
0 Milestone 3

MILESTONE

Everything above to be done by August 10. n/a

Future Aspects

TODO:

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?