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.

IRC

zaroth

Questionnary (part regarding project)

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

I chose SoC_Ideas_Multiplayer_Improvements_2011

Description of my proposal on how to tackle this project can be found here: [1]

Description of my proposal on how to tackle this project can be found here: Zaroth Simple Content Manager

4.2) If you have invented your own project, please describe the project and the scope.

Not invented, but description can be found here: Planned functionality

4.3) Why did you choose this project?

Since I'm an eager player of Wesnoth multiplayer games, it lies within my best interests to make it as good and enjoyable as possible - and several features are certainly missing. It also allows me to work on network code and networking is one of my main interests in programming.

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

I would like to be able to start and finish coding a little earlier, due to the heavy-exam time on my university in August. However, to compensate that, I will be able to easily devote a lot of time (and love) to the project during May, June, and first half of July. By the end of 3rd week of July I'd like to have all the planned functionality coded and (mostly) tested. So during the second half of July the only thing left is detailed testing, bugfixing and preparing for my exams.

4.5) Include as much technical detail about your implementation as you can.

Implementation details as well as planned functionality and my overall vision can be found here: Zaroth Multiplayer Improvements

4.6) What do you expect to gain from this project?

I expect to learn how a game networking code can be written and see a working example of that.

Last, but definitely not least is a lot of first-rate contact with experienced developers - I hope to pick up a lot of good programming practices from that! I'll certainly be also looking a lot through existing, (hopefully) good code, so it'll be a teaching experience in many ways.

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

A better question is what would make me not stay! I am already an eager, even if not very successful, ladder player and I keep meeting friendly and interesting people in Wesnoth community - on the game server, forum and IRC. I see no reasons not to stay so far...

Timeline

As I learn and plan more on the code I'm going to improve, parts of the timeline may be altered/broken down into more details later.

+	Mar 23 - Mar 31	Familiarize myself with important parts of current Wesnoth multiplayer code and Wesnoth way of doing things. Bug Crab_ and fendrin on IRC for tasks to do. Submit patches.
now	Apr 1 - Apr 15	Discuss implementation ideas and details. Try tackling some bigger tasks, either hacking or producing mainline patches. Gain SVN commit access. Bug Crab_, fendrin and mordante even more ;-)
-	Apr 16 - Apr 25	Easter break. I won't be available during this time.
-	Apr 26 - May 22	Though the mentioned period starts before 23rd of May, which is Google "start coding" date, I want to start to implement parts of my HIGH prioritized ideas. This is due to fact that it's beginning of semester for me (so a more laid-back time) and I hope to make up then for my limited availability in the end of July and whole August (exam preparation/exam writing time for me)
-	May 23 - July 17	Heavy coding time. I hope to have all high priority tasks done by the end of this period, unless serious difficulties occur.
-	July 18 - August 14	In this time I will prepare and later have my exams. I may be able to program a bit, but all the critical parts should be in by now. Time to test the main idea code, bugfix it if necessary and maybe do some of the lower priority tasks.
-	August 15	"'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc."
-	Afterwards	- continue to maintain my code and try to implement my low/medium priority ideas I didn't manage to code during GSoC

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.

Summed up above:

• create log domain for MP create window and make use of it
• learn the current LoW hack
• familiarize with code
• "the code" in question is everything from "create game" buton till "every MP side got their scenario WML"

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
• programmed basic mp change control dialog (learned a lot about GUI2 thanks to this)

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.

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

Summed up above:

• program a C++ function for getting vector of sides from WML
• it is needed in order to allow similar behavior for many WML tags
• [filter_side] is planned, which will make use of it

Improvement of my previous MP campaign difficulty hack

<Crab_> one of good things to do is to modify the map selection dialog to show scenario-specific options
<zaroth> and allow adding them?
<Crab_> yes.
<Crab_> we want to have a special section, i.e. [scenario_information], outside the #ifdef .... #endif guard
<zaroth> by the way, should it be done via #defines or rather WML variables?
<Crab_> WML
<Crab_> so, when we load the scenario for the first time (without difficulty level), we get it from that section
<Crab_> and then we should dynamically add stuff to the GUI
<Crab_> support at least 2 types of stuff. i.e dropdowns and checkboxes
* zaroth has to brush up WML knowledge, then
<zaroth> I modified this section slightly: link
<zaroth> I also stated my doubt about #define/WML variable there
<Crab_> (snippet 1)
<Crab_> it can look like this
<Crab_> alternatively, in a few years, it can be (snippet 2)
<zaroth> should it be within [scenario]?
<zaroth> or like [campaign], outside?
<Crab_> outside
<Crab_> we want to load it before we know the diff level
<zaroth> will be fun :-)
<zaroth> I'll probably extend my existing hack then
<Crab_> yes, it is an extension of your previous hack

Snippet 1:

[scenario_information]
  [parameter]
    type=checkbox
    name="Enable Fun Mode"
    to_variable=fun_mode
  [/parameter]
  [parameter]
    type=dropdown
    name="Attack time"
    to_variable=attack_time
    [option]
      name="Night"
      value="night"
    [/option]
    [option]
      name="Day"
      value="day"
    [/option]
  [/parameter]
[/scenario_information]

Snippet 2:

[scenario_information]
  [lua_code_to_create_the_gui]
     ...
  [/lua_code_to_create_the_gui]
[/scenario_information]

Summed up above:

• create a [scenario_metadata] section outside of [scenario], it will be preloaded
• don't preload the whole [scenario]
• allow defining scenario's own variables and sliders for game creation in the [scenario_metadata]

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
• merge [scenario], [multiplayer] and [campaign] tags ( [scenario] is already almost the same as [multiplayer], and [campaign] can be done by e.g. [metadata] section in [scenario]).
  • The reasoning for this change is the fact that a single scenario can be seen simply as a 1-scenario campaign and a single player scenario is an MP scenario for 1 person.
  • It would also allow showing the scenario settings screen between regular campaign scenarios. It would certainly come in handy for campaigns that already allow controlling of allies by a player or by an AI. (and a must_be_human=yes attribute in [side] would prevent the player for setting an AI to control the main campaign side ;-) - but since one can always droid his side anyway, I don't know if it's needed ). Also, a regular campaign scenario (which suddenly introduces a 1-scenario ally or something alike) could be saved at that moment and played together with a friend on the MP server. Possibilities are plenty.
• allow choosing of difficulty in MP campaigns just as it is done in SP
• allow scenario writers to define their own sliders/controls to be shown in the "create game" screen, with WML-defined values (e.g. slider "Earthquake frequency" with possible values "none", "rarely", "often", "very often") (Priority: MEDIUM)
  • should it be done through preprocessor defines (as currently with difficulty) or WML variables? I'm bending toward defines, but it's open for discussion.

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)
• Write a hack which loads the MP campaigns without the current ugliness (i.e. runs the preprocessor after choosing the difficulty level, not before, which can significantly decrease the loading time) (done)

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)

Issues

<Crab_> ok. so, the task is to hack/modify the MP creation screen (where you select
  the map to play) to use the same system
<Crab_> feel free to delete all MP maps except 1
<Crab_> then, modify that 1 map to use the same #ifdef   thing
<Crab_> so, when you parse it without a scenario-specific define, you'd only parse 
 the info you need for the map selection screen
<Crab_> it's ok if some parts of functionality are lost in the process, or if you 
 need to add a meta-info section like [scenario_meta_info] to store the extra stuff
  you need like the number of sides and the available difficulty levels, etc
<Crab_> then, make sure that after the map is selected, the user is asked to select
  a difficulty  level (or add a dropdown for that)
<Crab_> then, reparse the scenarios with the new define, getting the actual scenario
  data for the difficulty level selected
<Crab_> that's all
<Crab_> feel free to do it non-cleanly, it's only a proof-of-concept
<Crab_> I need to see if you'll be able to hack your way through the code to get the 
 result you want to happen
<Crab_> ask questions, if necessary
<Crab_> that's all )
<zaroth> if I understood correctly, main goal is to avoid preloading everything?
<Crab_> yes
<Crab_> only load everything once you know the difficulty level
<Crab_> by the way, by doing that task, you'd add support for difficulty levels for MP )

Summed up above:

• hack MP creation screen to allow choosing difficulty
• don't preload all MP campaign maps before a difficulty and scenario are chosen
• use the existing campaign defines

Surrendering

Priority: HIGH

Add a possibility to "properly" resign/surrender a game and make it work over network. I didn't consider this a high priority task so far, since no developers expressed much of interest about it. But after getting feedback from Noy, I plan on looking in depth into this problem. Some of doubts/issues can be already seen described below in the IRC log and following lists.

<noy> it's a critical fix that would enable a lot of different functions to be added
<noy> it's just never been coded in properly
<noy> and thinking through the gameplay effects is kinda important.
<noy> one issue that I'm concerned about is what happens in a 2v2 where one player quits?
<zaroth> as far as I thought, when a side surrenders and still has teammates, his side is
  automatically passed to his teammate
<noy> okay, that sounds good
<zaroth> when the last player in the team surrenders, the whole team loses
<zaroth> and in case it's 2v2v2 is offered to be droided to host
<noy> that was the other one
<zaroth> (of course there can be a 1 player team ;-) )
<noy> the option there is also to have a pre-game box that might say sides get droided or
  are removed from the map
<noy> it's critical for a 2v2 ladder
<zaroth> mm... removing a team from the map seems like a huge change to a gameplay
<zaroth> there was so far nothing that did total extermination
<noy> well you could just make them neutral third side

Summed up above:

• if a side in 1v1 resigns, it's an automatic win for the other side
  • maybe add an "automatically resign quitting players" option in MP creation dialog? Possibly even with a customizable timer to provide a buffer time to reconnect in case of connection problems. However, for it to be dependable, the timer should be server-sided.
• if a side in 2v2, 3v3, other team games resigns, its control should be automatically passed over to its teammate
  • note that only control of the side is changed, not the units side (as in blue units join red forces) - this would be a gameplay change I don't intend on here.
• if a team in 1v1v1, 2v2v2, FFA, etc. resigns, the host droids it automatically
  • as noy suggested, there could be an MP creation dialog option for the resigned team to disappear - however, this would be a huge gameplay change and isn't Wesnoth following OAB philosophy? I'm reluctant to implement this therefore, but if I hear more voices for it, I may do it

Potential problems

• What will happen if after surrendering a side in a more than 1v1 game (e.g. 1v1v1) an observer wants to take over this side?
  • In case the side was exterminated (noy's idea), it's obviously impossible.
  • But what should happen if it just became neutral (droided?) - in competetive gaming it doesn't feel right, but I think that allowing/disallowing that happening should be left to host's decision.
  • And what about its (also resigned) teammate, if it was 2v2v2? - my opinion is that it should be also passed to the observer taking over and automatically droided.

Control panel

Priority: MEDIUM

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).

Separation of hiding a side in status table and control panel

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 shown in the status tables of the majority of current MP add-ons/scenarios)

(in my opinion it's not very useful, but if you strongly feel that it's 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 (done)
  • abstract some of the control giving code, since as for now it's pretty tightly tied to the console commands
• find a good way to determine AI sides' nick ownership, to allow proper showing of the AI owner in the nick table (it's not so easy to do with current infrastructure)
• 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.

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)

It could also involve fixing naming of local players, since it's currently disabled.

Remove statues' turns from replays by introducing a skip_replay attribute

Priority: LOW (but I'll try to do it before GSoC to get some more coding practice)

As you may have noticed, navigating replays using "Play side turn" isn't too pleasant on e.g. Sulla's Ruins and Caves of the Basilisk. Once per turn you get to see the statues' moves, which are not too interesting. This causes confusion and requires additional clicking.

To solve this, I propose introducing a skip_replay= attribute (default: no) in the [side] tag. Sides with this attribute set to "yes" would have their units moved instantly in replays (as in "Quick replays" option). It would also disable possibility to pause at this side's turn, the next side would be played and paused at instead.