New structure of campaign loading
Moderator: Forum Moderators
New structure of campaign loading
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:
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:
But hey, Milestone 2 is not the only point you're able to help with. There's also this:
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
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
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:
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).Zaroth wrote: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.
But hey, Milestone 2 is not the only point you're able to help with. There's also this:
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.Zaroth wrote: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.
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
Re: New [scenario_metadata] plans - volunteers needed
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.
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.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: New [scenario_metadata] plans - volunteers needed
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 ?
(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 ?
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: New [scenario_metadata] plans - volunteers needed
Thanks for your feedback! Now replies, in order:
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:
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?
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
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.
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:
fancy MP scenario (with e.g. sliders or comboboxes in the parameter window):
A campaign's (MP or SP, won't matter anymore) _main.cfg
A campaign's scenario (not intended to play outright, but only as a continuation):
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.
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.doofus-01 wrote: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.
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:
- You press "Campaign" button.
- 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.
- You choose difficulty. A difficulty= define is loaded and cached.
- First [scenario] is loaded, based on the first_scenario= information in [campaign] tag.
- Special beginning-of-the-scenario save is created.
- You watch the intro, if there is one, play and win.
- Depending on scenario author's intentions, scenario X is loaded.
- Go back to step 5, until you have won the campaign.
- 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)
- You see familiar (but probably a bit different) MP game creation screen.
- 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.
- 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)
- 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.
- 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:
I think you can imagine what this code is supposed to do
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]
- You press OK. After that, all #defines (also difficulty=) and WML variables get loaded and cached.
- 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.
- Special beginning-of-the-scenario save is created.
- 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!
- You watch the intro, if there is one, play and win.
- Depending on scenario author's intentions, scenario X is loaded.
- Go back to step 4, until you have won the campaign.
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?
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)doofus-01 wrote: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.
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
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.Anonymissimus wrote: 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).
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.
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:Anonymissimus wrote:I guess this will also mean that mp campaigns and mp scenarios will each "live" in their own preprocessor scope ?
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]
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]
Code: Select all
[scenario_metadata]
define=MY_CAMPAIGN
...
[/scenario_metadata]
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
Spoiler:
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: New [scenario_metadata] plans - volunteers needed
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 -)
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...).
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...).
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: New [scenario_metadata] plans - volunteers needed
The
Oh boy does it. Good-bye add-ons if one crappy SP campaign can break everything.Anonymissimus wrote: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.
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.Zaroth wrote: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.
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.Zaroth wrote: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
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.Zaroth wrote:please leave UI discussions for later.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: New [scenario_metadata] plans - volunteers needed
[endlevel]replay= ?doofus-01 wrote:I have no idea where that switch should go.
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.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: New [scenario_metadata] plans - volunteers needed
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.Anonymissimus wrote:let's stop derailing the thread.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Re: New [scenario_metadata] plans - volunteers needed
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?
Or am I misunderstanding something and the whole point is not to balance but to make multi-player capability possible?
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: New [scenario_metadata] plans - volunteers needed
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.bigkahuna wrote: SP campaigns are made for a single player, so how would this be balanced correctly
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: New [scenario_metadata] plans - volunteers needed
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.
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.
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: New [scenario_metadata] plans - volunteers needed
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.)Zaroth wrote: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.
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...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.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
Re: New [scenario_metadata] plans - volunteers needed
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.Zaroth wrote: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.
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.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Re: New [scenario_metadata] plans - volunteers needed
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)
"This game cured me of my real life addiction."
-Flameslash
-Flameslash
-
- Inactive Developer
- Posts: 2461
- Joined: August 15th, 2008, 8:46 pm
- Location: Germany
Re: New [scenario_metadata] plans - volunteers needed
a reply to a pm by zaroth, regarding the [endlevel] tag
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:
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.
No.Zaroth wrote:Did you discuss it with fendrin in private query?
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]
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign
A Simple Campaign: campaign draft for wml starters • Plan Your Advancements: mp mod
The Earth's Gut: sp campaign • Settlers of Wesnoth: mp scenario • Wesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign