Zaroth Multiplayer Improvements

This page is related to Summer of Code 2011

See the list of Summer of Code 2011 Ideas

Introduction

This is a page containing details on implementation of Multiplayer engine improvements by Zaroth.

Current issues

Here I'll put comments regarding stuff I'm currently working on, so one doesn't have to check the whole document for changes every time.

Get to know the current code and its problems

Discussion from IRC:

<zaroth> which of the pre-gsoc ideas of the page would you recommend as the first task?
<Crab_> compile wesnoth, find code which deals with multiplayer game creation, and add MULTIPLE debug
  statements to it so you will be able to see what is going on when the game is created.
<Crab_> I suggest using quite heavy logging, involving some new log domains, like "mp/create/foo",
  "mp/create/bar"
<Crab_> so, you'll be able to use --log-debug='mp/create/*' to get all them running at debug level
<fendrin> And learn about your goal. Have a look how difficult levels are handled in singleplayer
  and see the dirty hack that LoW uses to emulate it.
<Crab_> then, launch 2+ wesnothes (can be on same host, can be on different hosts), and see how they
  interact and what they do send to each other when a game is created and sides are selected
<Crab_> basically, I want you to understand the code and add a lot of log info to it, so we'll be able
  to change it and find issues without having to debug
<Crab_> then, submit the logging as a patch
<Crab_> and by 'heavy' logging I mean really verbose things, including logging the entire scenario
  configs to stdout, if explicitly asked for in the command-line switches.
<zaroth> thanks for the advice/assignment! it certainly doesn't sound too hard right now :-)
<Crab_> that's just the beginning, but the code will be familiar afterwards
<Crab_> just to make sure, we're interested in things that start after someone selects a
  'create game' button and that end when the game is started and everyone receives the scenario config.

Already done in this direction:

• got some knowledge of MP code workflow as well as adding some debugging there and discovering some redundant code
• read Mordante's GUI2 design document

Probable next training (pre-GSoC) tasks

If any developer has any quick-to-code wishes not already listed in EasyCoding, I'd love to hear them, even if they are not from the code areas I'm going to work in.

Doing basic implementation of the control panel idea

In progress.

WML utility function to get vector of sides from any tag

As described in this IRC log:

<Crab_> code a function which will take a WML tag, and return a vector of integers
  which are determined by the contents of side= attribute in that tag
<Crab_> [foo]side=1[/foo]              1
<Crab_> [foo]side=1,2[/foo]              1,2
<Crab_> [foo]side=all[/foo]              1,2,3,4,...,6,7,8       (all the sides in game)
<Crab_> wml tag is represented by config
<Crab_> put that function in game_events.cpp
<Crab_> it will be used in many tags to allow them to act in the same way ...
<Crab_> this is to allow most tags to specify not just side=1, but a list of sides
<Crab_> later, a support for side_filter would be added
<Crab_> that is, if the cfg contains [filter_side] subtag, then take stuff from side= in tag,
  and AND it with the list of sides given by side filter
<Crab_> where empty side= and empty [filter_side] match all
<Crab_> but if they are both empty, a deprecation warning is produced

Planned functionality

Priorities explanation:

• HIGH means basically the same as "must have", will be definitely done during the GSoC
• MEDIUM means that I plan on implementing this feature during the GSoC and will do it unless serious difficulties occur
• LOW is the same as "nice to have", I'll get to implementing these if I get some spare time in the end. However, they're still tasks I'm interested in and I'll probably get around to doing them after the GSoC (I don't have any plans of leaving this community soon).

Better integration of MP campaigns

Priority: HIGH

Described in detail in the original idea. Since it's heavily dependent on SP and MP engines unification, I'll describe them together here.

Planned features

• merge the classes in *_controller.cpp intelligently, the goal is to make SP a special case of MP
• allow choosing of difficulty in MP campaigns just as it is done in SP
• (your suggestion)

Subtasks

• learn the current hack Legend of Wesmere MP version uses for introducing different difficulty levels (done)
• get acquainted with the *_controller.cpp files (as in playmp_controller) to get an idea of what has to be done in order to perform the required merge (partially done thanks to fendrin's guided code trip on IRC)
• (will be expanded for sure as I get more acquainted with the code/task)

MP "create game" dialog improvement

Priority: HIGH

Improve the MP create game dialog as stated in main idea topic.

Planned features

• possibly allow categorization of the scenarios to allow easier finding and selection? As in "Official MP scenarios" > "2 players" > "Caves of the basilisk". This would allow easier browsing among maps when a user has many add-ons installed.
• (your suggestion)

Subtasks

• introduce debug logging in these screens, so it's easier for a developer to recognize what's going on there (partially done, probably will add more debug statements as I go)
• convert the creation screens to GUI2
  • create a mockup to allow quickly communicating my ideas of any improvements
  • some GUI elements may be missing, so it probably will involve working with mordante in order to get the necessary widgets in
• possibility to randomize players assignment to sides as in this feature request and make it work over the network (priority: MEDIUM)

Control panel

Priority: HIGH

Instead of host having only command line interface to :control and :droid, I plan on coding a control panel window, user-friendly and GUI-accessible. A mockup made quickly in Qt Designer (with the player seeing this dialog (Zaroth) as host of the game, that's why not any of the "give control" comboboxes are not greyed out):

I feel that sides with attribute hidden=yes shouldn't be shown in this dialog as well, since one doesn't want to give a GUI to allow changing controller of statues on e.g. Caves of the Basilisk (it'd be just confusing). It could be also nice to allow hiding a side from control panel, but showing it in the status table. It would come in handy for e.g. hiding pure AI sides in survival games or any other MP games against the AI (AFAIK the AI sides are currently shown in the status tables of most of current MP add-ons/scenarios) (if you strongly feel that it's (not) needed, please express this in a comment, this will help me with decision on whether to bother or not)

Planned features

The mockup should be quite self-explanatory. If not, let me know, this means I failed at UI designing and have to make it more intuitive ;-)

Subtasks

• learn basics of GUI2 (done, thanks to the mordante's GUI2 document)
• implement a simple working control panel with UI based on gamestate_inspector (in progress)
  • abstract some of the control giving code, since as for now it's pretty tightly tied to the console commands
• get necessary widgets ready (as mordante said, e.g. GUI2 combobox isn't programmed yet)
• since it'll be quite similar to the current status table, I may also convert the current status table to GUI2 (priority: LOW)

Various others

These are small more or less random ideas I'd like to do. In case I get really tired with the main tasks, I can have a small break while working on these. Also, if I get any free time after finishing my main tasks (which may be unlikely), I can fill it with working on these as well.

Surrendering

Priority: MEDIUM

Add a possibility to "properly" resign/surrender a game and make it work over network

Changing difficulty mid-campaign

Priority: LOW

Add a possibility to change a difficulty mid-campaign as described in this topic (and make it work over the network ;-) )

Avoid seeing each other's views when playing hotseat

Priority: LOW

Improve hotseat gaming as in this feature request (prevent unwilling cheating by seeing each other fogs of war cleared areas)