New structure of campaign loading

[Zaroth]

Hello!

I'm a GSoC applicant who have ambitious plans to change parts of the engine running the very core of the game: the campaigns. As some of you may have heard, MP/SP unification is planned for this GSoC and I'm an applicant attempting this.

The main idea is to allow launching everything from one creation screen and make everything a multiplayer campaign - especially since:

• single player campaign is just a special case of n-player campaign, where n=1
• single scenario is just a one-scenario campaign

No worries about that will complicate current WML much - I know well about KISS principle and I plan on sticking to it. If you don't want to define the new special header, fine - the old behavior will be maintained as much as possible.

My rough plans on how and in which steps to implement this are here. As you may have noticed, up to Milestone 2 there is not much you can do. However, this is balanced by massive amount of testing that has to be done after Milestone 2. QFT:

Milestone 2: All mainline content is ported to the new syntax and therefore my code can receive heavy testing, much heavier than I could ever do with my simple test campaign. A release for wider audience would be nice, with important note that things will break in this release and stability of regular development releases will not be maintained. If a release prove to be not possible during GSoC, spend at least one week testing everything and bugfixing. As for the old campaign code, it will still be there, so UMC authors can see their campaigns in the old campaign choice window until they decide to port to new syntax.

As you can imagine, porting all mainline campaigns is no easy task and will most likely produce tons of bugs. Therefore, everyone who is able to help with testing after the changes are introduced (optimistically planned, this should be before the end of June) is most welcome. Please note that I may or may not convince Ivanovic to make an unofficial binary development release for Windows and such to make the testing easier for you, so it may turn out knowledge on how to checkout latest SVN version and compile Wesnoth from source will be necessary (especially people who know how to do it on Windows are welcome).

But hey, Milestone 2 is not the only point you're able to help with. There's also this:

11. (if time allows) add cool new things to the [scenario_metadata] tag, such as allowing defining in WML your own sliders/comboboxes in the game creation screen.

Therefore, if you have any ideas what cool new stuff can be done with the new [scenario_metadata] tag (for some examples you can look in my proposal), feel free to write them here or (better, I find wiki pages awesome for brainstorming) in this special wiki page.

Current sketch of my vision of this tag and its functionality can be found here (please don't edit this one without consulting me first) I certainly won't be able to implement all of your ideas during GSoC, but I want to hear your opinions/suggestions - after all, this is all for you, UMC creators

[doofus-01]

I have two comments/questions (and sorry if I overlooked something):

1. Once support for current [campaign] WML is dropped, the bare minimum revisions needed for SP campaigns would be to add a [scenario_metadata] block to the top of each scenario? That doesn't sound too painful, especially if one can define a macro for default behaviour.

2. In the [scenario_metadata], can there be a key for disabling replays? You propose doing this for sides, to avoid looking at statue turns, but replays and their pop-up boxes are annoying and useless for cutscenes in campaigns.

[Anonymissimus]

Uh oh. This doesn't become like the whiteboard I hope.

(I wouldn't dare to touch that part of the engine . I see that such a step makes sense however.)

Is it neccessary to convert all mainline campaigns (and mp scenarios) ? I'd leave a few for providing better backwards compatibility. Using certain standards in mainline tends to push/create work on the side on UMC authors (bugs that only appear in UMC and the like).

EDIT
I guess this will also mean that mp campaigns and mp scenarios will each "live" in their own preprocessor scope ?

[Zaroth]

Thanks for your feedback! Now replies, in order:

I have two comments/questions (and sorry if I overlooked something):

1. Once support for current [campaign] WML is dropped, the bare minimum revisions needed for SP campaigns would be to add a [scenario_metadata] block to the top of each scenario? That doesn't sound too painful, especially if one can define a macro for default behaviour.

I'm not even sure currently if to make a campaign behaving exactly like the current ones there'll be anything else to do for an UMC author besides editing the [campaign] tag to comply to new standards. Since the current settings are working for tens of current SP campaigns, why don't assume them by default for new ones? Why fix something that isn't broken? That should minimize the effort needed for porting. And although it might turn out during GSoC that some serious compatibility-breaking (i.e. requiring more then renaming [campaign] to [scenario_metadata] or [scenario_header], whichever name will be more liked) changes can't be avoided, I don't see any yet.

You seem to be missing the point of the [scenario_metadata] a bit, since in my vision certainly not every scenario will need it. It may be my fault for not expressing myself clearly enough. I am happy to explain it, however.

Current course of events when playing a SP campaign goes like that:

1. You press "Campaign" button.
2. You choose campaign. After your campaign choice define= and extra_defines= are loaded and cached, plus all the scenarios that belong to the campaign are now unlocked by the #ifdef "campaign define" and loaded.
3. You choose difficulty. A difficulty= define is loaded and cached.
4. First [scenario] is loaded, based on the first_scenario= information in [campaign] tag.
5. Special beginning-of-the-scenario save is created.
6. You watch the intro, if there is one, play and win.
7. Depending on scenario author's intentions, scenario X is loaded.
8. Go back to step 5, until you have won the campaign.

The new course of events will look more like that:

1. You press "Create local game" button. (please leave UI discussions for later. There will be time for that and I'd like to focus on the functionality/implementation details now. That implies that initially some current eye-candy like showing a pre-campaign portrait or using images to depict difficulties may be initially lost, but surely back in time for the 1.10 release)
2. You see familiar (but probably a bit different) MP game creation screen.
3. From the long list, you choose one MP campaign (please note that from now on basically every playable content will be a MP campaign, just number of players may happen to be 1 and number of scenarios as well). It means that every file that has a [scenario_metadata] will be shown there. A file that has [scenario] but not [scenario_metadata] is assumed to have a default one, well suited for multiplayer.
4. A parameter window is invoked. Its appearance will be possible to define through various attributes of [scenario_metadata] (it is noteworthy that by default it won't appear, because the default [scenario_metadata] doesn't have any configurable parameters - more in the next points)
5. You choose difficulty in the parameter window (yes, you'll be able to change the difficulty mid-campaign). A difficulty= define is loaded and cached. The difficulty= option will probably stay specified through #defines, if only to avoid immense and pointless work converting all these campaigns to use WML/Lua variables for specifying difficulty-dependent scenario conditions. In order not to break current state of things, it will also be mandatory for the engine to have a difficulty= define. However, if you don't specify it or specify just one difficulty, difficulty choice will not be offered to the player (what for?). In fact, Wesnoth kind of already does that, even in MP games - if you don't believe me, open any MP save and look for difficulty=. I guarantee you'll find a difficulty="NORMAL" somewhere.
6. You choose other parameters in the parameters dialog. What kind of parameters? Well, whatever scenario author specified in the [scenario_metadata] tag. Some mock-up examples:

   Code: Select all

   [parameter]
     type = combobox
     store_in_variable = earthquakes
     title = _ "Earthquakes"
     description = _ "Number of earthquakes per turn in this scenario."
     [option]
       title= "No earthquakes"
       store="none"
     [/option]
     [option]
       title= "Some earthquakes"
       store="some"
     [/option]
     [option]
       title= "Many earthquakes"
       store="many"
     [/option]
   [/parameter]
   [parameter]
     type = slider
     store_in_variable = woses
     title = _ "Crazy woses"
     description = _ "Probability per turn that one of your woses will turn crazy"
     range=20-80
   [/parameter]
   

   I think you can imagine what this code is supposed to do
7. You press OK. After that, all #defines (also difficulty=) and WML variables get loaded and cached.
8. First [scenario] is loaded, based on the first_scenario= information in [scenario_metadata] tag. It however defaults to pointing to the same file the [scenario_metadata] is in, so even if we loaded a file with just [scenario] and used implicitly default [scenario_metadata], we're fine.
9. Special beginning-of-the-scenario save is created.
10. unless specified otherwise in the [scenario_metadata], current MP waiting screen appears. Since in our example we assumed playing something that before was just a simple SP campaign and now got converted to the new style, you won't wait too long, because there's just one playable side. You may experience a feeling of loneliness, though - because playing campaigns with friends can be so much more fun!
11. You watch the intro, if there is one, play and win.
12. Depending on scenario author's intentions, scenario X is loaded.
13. Go back to step 4, until you have won the campaign.

I hope it clarified things a bit

I'd also like to advocate adding support for controlling your allies in your campaigns whenever possible, even if those are one-scenario allies (after the mid-campaign MP waiting screen thingie is working). Cooperative gameplay is quite popular on the MP server and I bet that some people would love to ask a friend on the server to help them win some scenarios in your campaigns, or even play through whole campaigns with them.
As a side note, this will probably reduce saveloading tactics, simply because reloading a game with other players involved is so much hassle (no worries, I will keep current defaults / make an option in the "Load game..." window to skip MP waiting screen if you're simply playing SP and want to do some saveloading).

Now, who is willing to make "A tale of Three brothers", where two brothers are looking for the third?

2. In the [scenario_metadata], can there be a key for disabling replays? You propose doing this for sides, to avoid looking at statue turns, but replays and their pop-up boxes are annoying and useless for cutscenes in campaigns.

As you may already caught on from my above description, this attribute rather shouldn't belong to [scenario_metadata] - because [scenario_metadata] contains only info that is necessary prior to playing - such as these parameter definition thingies. (This may change, however)

Therefore, if I understood correctly, you want a possibility to disable the automatic popup offering user to save replay after a game, right? That's easily doable (wherever it wouldn't be placed) and if I hear more voices that it's needed, no problem

Is it neccessary to convert all mainline campaigns (and mp scenarios) ? I'd leave a few for providing better backwards compatibility. Using certain standards in mainline tends to push/create work on the side on UMC authors (bugs that only appear in UMC and the like).

I don't really understand what you mean by "backwards compatibility" here. It's not like versions of Wesnoth prior to the 1.9.x-first-Zaroth-influenced-release will suddenly become deleted from the server, for folks who still want to write 1.8 content, in case if you meant that.

In case you meant that it can be hard to convert current 1.8 stuff to 1.10 - it is my intention to KISS the conversion as much as possible - read above, it may clarify things a bit for you.

Please take note that maintaining two versions of essentially the same code in game is no developer's maintenance dream and dropping the old code may be actually a blessing in this case.

In case you didn't mean any of these things, I'm afraid don't understand your point. Please elaborate.

I guess this will also mean that mp campaigns and mp scenarios will each "live" in their own preprocessor scope ?

Well, again, I'm not sure I understood you correctly. I'll try to answer by some example code anyway, since a good example can be worth 1000 words:

Suggested structures are the current plan, they may change later, especially if some experienced WML wizards like you or zookeeper point out flaws in this approach.

regular MP scenario:

Code: Select all

[scenario]
...
[/scenario]

fancy MP scenario (with e.g. sliders or comboboxes in the parameter window):

Code: Select all

[scenario_metadata]
... (no first_scenario= here needed, since [scenario] is in the same file and it defaults to such)
[/scenario_metadata]
[scenario]
...
[/scenario]

A campaign's (MP or SP, won't matter anymore) _main.cfg

Code: Select all

[scenario_metadata]
define=MY_CAMPAIGN
...
[/scenario_metadata]

A campaign's scenario (not intended to play outright, but only as a continuation):

Code: Select all

#ifdef MY_CAMPAIGN
[scenario_metadata] (if needed) - if not present, simply uses default settings, which should be okay for most cases
[scenario]
[/scenario]
#endif

So... I guess not much will change. Except of creation of the [scenario_metadata] tag, which will define how the scenario behaves before the game actually starts, hardly anything.

Spoiler:

I wouldn't dare to touch that part of the engine

Don't worry, [duke_nukem_voice]I've got balls of steel[/duke_nukem_voice]

No, seriously. I was quite scared at the beginning as well, but my poking around the code and actually succeeding with the hack Crab asked for did wonders to my confidence. I think I can do it. Moreover, I think I can Make It Work™.

[Anonymissimus]

From what the whole thing looks like I'm currently carefully optimistic.

As for the "preprocessor scope": SP campaigns have their [campaign]define=. All their wml/lua/binary data is (should, if the author does it right, including [binary_path] data) only be read if that define= is defined (which is done by choosing to play that campaign). If sp campaigns become specialized mp campaigns, mp campaigns need to have this mechanism too. (From what your ugly hack looks like you did that -

Code: Select all

game_config::scoped_preproc_define campaign_def(campaign_header["define"]);

)

Currently it is so that mp addons can easily conflict with each other. For example, both addons could use an image with the same filename (but looking different), and the version of the image of addon 2 is used while playing addon 1 instead of the version from addon 1. Similar thing can happen for macros (overwriting, ignoring, or undefined behavior, don't know what actually happens). So that's something to test - try bringing 2 mp campaigns in conflict with each other.

Another thing to test would be the interaction of an era setting with a campaign which was sp so far (and shouldn't be used with another era of course...).

[doofus-01]

The

As for the "preprocessor scope": SP campaigns have their [campaign]define=. All their wml/lua/binary data is (should, if the author does it right, including [binary_path] data) only be read if that define= is defined (which is done by choosing to play that campaign). If sp campaigns become specialized mp campaigns, mp campaigns need to have this mechanism too.

Oh boy does it. Good-bye add-ons if one crappy SP campaign can break everything.

I'm not even sure currently if to make a campaign behaving exactly like the current ones there'll be anything else to do for an UMC author besides editing the [campaign] tag to comply to new standards.

OK, so if there is nothing about [scenario_metadata] in a scenario, it falls back to what was in the (renamed) [campaign] section. And the default is to behave the same way as now. So, there is very little a UMC maintainer of old campaigns has to do to bring them into compliance, just tweaking _main.cfg. If that's all true, that sounds fine to me.

Therefore, if I understood correctly, you want a possibility to disable the automatic popup offering user to save replay after a game, right? That's easily doable (wherever it wouldn't be placed) and if I hear more voices that it's needed, no problem

Right, the WML writer defines for each scenario whether replays get saved or not (or can at least override whether they get saved). Replays may be annoying and useless in, say, scenario 3, but useful in scenarios 1,2, and 4. I have no idea where that switch should go.

please leave UI discussions for later.

Not sure if this is the type of thing you don't want to discuss now, but I'll keep it brief. I have my doubts about designing this so that SP is just a subset of MP where n=1. It could be perfectly functional, but packaged that way, for those of us who don't really do online gaming, it might be a turn-off (or maybe I am just too used to the way things are now). Just something to consider.

[Anonymissimus]

I have no idea where that switch should go.

[endlevel]replay= ?
There already is an [endlevel]save= key determining whether a start-of-scenario save for the next scenario oughta be created.
Now file a feature request and let's stop derailing the thread.

[doofus-01]

let's stop derailing the thread.

OK, but how do we know what should go in [parameters]? It sounded like it could have gone there. What is necessary "prior to playing"? I wouldn't have guessed something like "earthquake frequency" (a WML variable?) would be.

[bigkahuna]

Multiplayer campaigns are carefully balanced gold and difficulty wise according to the number of players... SP campaigns are made for a single player, so how would this be balanced correctly?

Or am I misunderstanding something and the whole point is not to balance but to make multi-player capability possible?

[Anonymissimus]

SP campaigns are made for a single player, so how would this be balanced correctly

You are missing the point. This thread is not about wml-based changes of sp campaigns into mp campaigns. It is about changing the way the wesnoth C++ engine interprets wml. SP campaigns will be interpreted as mp campaigns. But ideally a wesnoth player will not notice anything of these changes and a wml author should notice as few as possible and there is no relation to balance at all.

[Zaroth]

Thank you for assistance in the hard task of trying to explain my ideas (and for careful optimism), Anonymissimus.

I should definitely test colliding namespaces and their handling. Added to my testcases list.

doofus-01:
[parameters], as currently planned, is a tool for a WML author to make their scenarios feel more configurable. My examples (earthquakes and crazy woses) were on purpose so off, so nobody would think that they are mainline WML tags/variables. Well, let's me clarify that anyways.

The most obvious thing that is better chosen before start of the scenario is difficulty, so let me thing of something different. For example, you want for player to be able to choose starting ToD before the scenario starts. Currently, you'd have to declare a message box at the beginning of the scenario with possible choices and then react to user choice in WML. With the new [parameters] tag, there is no need for such message boxes - you could simply specify a [parameter] type=combobox. Bam, now when loading your scenario, before the game starts (and before any players join), player will see a combobox allowing to choose him starting time of day. And you'll be able to read his choice from a WML variable.

Actually, also here I could use your (UMC authors) input - is there need for storing the user's choice in #defines, or are WML variables sufficient? I never coded a lot in WML, so I'm not sure which one is more comfortable to use.

About your GUI doubts: well, providing certain kind of shortcuts for players used to old GUI certainly shouldn't be a problem. The main purpose is to unify the engine interpretation, UI to that can be always modified. But as I said, it's a discussion for later.

bigkahuna:
As Anonymissimus already said, it's not about modifying content/balancing at all. It's about providing infrastructure. Right now trying to code a multiplayer campaign looks kind of horrible and hacky in WML - did you see the Legend of Wesmere WML in 1.9? Not mentioning the fact, that due to lack of needed infrastructure every scenario is parsed thrice - once for every difficulty. You can imagine how horrible slow the loading times in Wesnoth would be if we were to add more MP campaigns without fixing that.
Furthermore, unifying SP and MP would effectively reduce the amount of code to maintain for developers. Did you know, for example, that loading savegames for MP and SP are currently done by two separate pieces of Wesnoth code (according to YogiHH)? That effectively doubles amount of places where bugs can appear whenever implementing a new feature in this area.

[Anonymissimus]

Currently, you'd have to declare a message box at the beginning of the scenario with possible choices and then react to user choice in WML. With the new [parameters] tag, there is no need for such message boxes - you could simply specify a [parameter] type=combobox. Bam, now when loading your scenario, before the game starts (and before any players join), player will see a combobox allowing to choose him starting time of day. And you'll be able to read his choice from a WML variable.

What's more - with the current way of using a turn 1 event displaying a message with options, only player 1 can select the options, who is not neccessarily the same person as the host. With that pre game dialog it will always be the host selecting starting parameters. (I suggest to name the key variable= to stay consistent with the store_unit tag and else.)

Actually, also here I could use your (UMC authors) input - is there need for storing the user's choice in #defines, or are WML variables sufficient? I never coded a lot in WML, so I'm not sure which one is more comfortable to use.

I vote for wml variables (other than the stuff which is already #defines in existing sp campaigns - difficulty and the extra_defines= key). They're much more flexible, and can easily be referenced by lua files (which is impractical to do for #defines). A disadvantage may be that wml variables can be used (afaik) only inside [event]s and [story] and [part], but e.g. not to disable/enable wml at scenario level. So actually, there's probably good usage for both...

[doofus-01]

Actually, also here I could use your (UMC authors) input - is there need for storing the user's choice in #defines, or are WML variables sufficient? I never coded a lot in WML, so I'm not sure which one is more comfortable to use.

I'd also say WML variables. I don't think the preprocessor things can be modified on the fly like the WML variables can. I guess one could have a #define in the [parameters] that sets a WML variable... Not sure what advantage would be for that though.

As for WML variables being restricted to [event]s and [story]s, that doesn't strike me as very restricting. If there is a top-level setting you don't like (turns, gold, time-of-day, something else?), you can often override it in prestart event, and the player doesn't have to know what happened.

[alluton]

if i understood right(what i hope cause english isnt my native langue) this seems excellent idea. Tought im not familiar whit coding. I could do testing if stuff works.(just pm to me)

[Anonymissimus]

a reply to a pm by zaroth, regarding the [endlevel] tag

Did you discuss it with fendrin in private query?

No.

The last two recent posts in this thread are related: http://forums.wesnoth.org/viewtopic.php ... 57#p486157

Apart from what the tag currently really does:
[endlevel] is the only wml action tag I can think of atm which I suspect to work differently in mp than in sp, which is affected by the plans described in this thread and which should be reworked. wml-wise I could imagine such syntax:

Code: Select all

		[endlevel]
			#keys at the toplevel are interpreted as belonging to side=1 for backwards compatibility
			[side]
				side=2
				#same keys as in [endlevel] so far
			[/side]
			[side]
				side=3
				#etc
			[/side]
		[/endlevel]

However, I guess this causes tons of problems...what happens if one side is switched to linger, and the other continues immediately with the next scenario ? Some major form of OOS error I guess. It should be possible to display the defeat dialog for one side and victory for another at least (side-specific result= key, which is currently not possible). This should probably mean that the defeated side is then "kicked" from the campaign and must not appear in the next scenario. But not all of the keys can be made side-specific I guess, due to the above.