Cumulative gameplay modifications in multiplayer

[lipk]

UMC authors tend to use eras to alter the standard rules. This technique has some drawbacks: firstly, only one modified ruleset can be active at a time, and secondly, by using a modification as an era, you lose the opportunity to select alternative factions, which is the main point of multiplayer eras.

So, what I'm working on: a new toplevel tag, game_mod. A game_mod consists of an id, a description and a set of event tags. There's a new dialog added to the multiplayer game creation screen through which you can activate one or more installed modifications. The event tags of activated mods are be copied into the game's config and work as if they were part of the scenario.

The feature is by no means finished, here's a todo list:
- display activated mods to players when joining a match (currently only host can see them)
- support savegames (I don't think they work right now)
- add a new add-on category
- think out a clever terminology (game_mod sounds silly to me, but I couldn't come up with anything better)
- test, test, test

[lipk]

Here's a further elaborated concept (involving many ideas which came up on IRC):

Options
Modifications could have user editable settings. For example, a modification which would let you win after an X number of enemy units killed should be obviously let you customize that X. The problem of this idea is that options would be naturally represented by variables in the WML code, which could interfere with variables from other modifications or eras. The solution could be to set up a clever naming system.
The options could have different types depending on what values they are supposed store. My proposals:

- integer: an integer, presented to the user as text entry

- integer_range: an integer, presented to the user as a slider

- double: a rational, presented as a text entry

- double_range: a rational, presented as a slider

- boolean: a boolean value, presented as a checkbox

- string: a string value, presented as a text entry

- list: a set of string values, presented as a combo box

Other tags
Currently game_mod can have only event tags as children, but it was pointed that the inclusion of some others would make sense, too. There isn't a list of them yet, but of there's a possibility that multiple tags will be allowed inside game_mod, and regarding that the option-thingy is very likely to require some tags on its own, it sounds like a good idea to separate the tags to be copied into the scenario to a data tag. Like this:

Code: Select all

[game_mod]
  id=test_mod
  description=_ "Test mod"

  [option]
    name=random_option
    type=integer
  [/option]
  [data]
    [event]
      name=start
      #do something
    [/event]
  [/data]
[/game_mod]


Black/whitelist
It's more than likely that not all modifications will be compatible with each other. Authors could be able to maintain black and whitelist of other add-ons which are proven to be in/compatible with their work.

[Alarantalara]

Could the options be separate from the modifications?

There are already scenarios where the game creator selects a difficulty level or other parameter on the first turn of the game. It would make sense for these to be options as well, especially if they were displayed before the game began. (An example: Settlers of Wesnoth has a victory point target and does not make sense as a modification.)

Actually, those first turn events already allow user editable settings, so options are probably not needed immediately, anyway.

[Crab]

There are already scenarios where the game creator selects a difficulty level or other parameter on the first turn of the game. It would make sense for these to be options as well, especially if they were displayed before the game began.

I agree

Settlers of Wesnoth has a victory point target and does not make sense as a modification.)

IMO, it actually makes perfect sense as a modification, but, being scenario-specific it should be only displayed for this particular scenario.

Actually, those first turn events already allow user editable settings, so options are probably not needed immediately, anyway.

having them *before* the game starts is slightly better, as more work can be done before actually starting the game (i.e., even the difficulty can be changed at that point, and prestart wasn't running yet, etc.)

[lipk]

There are already scenarios where the game creator selects a difficulty level or other parameter on the first turn of the game. It would make sense for these to be options as well, especially if they were displayed before the game began.

Seriously, guys, I've just finished the new gui and you come messing with this... kidding aside, what about adding yet another tag, [options], which would be embeddable into modifications and multiplayer scenarios? The actual options could be described in this tag and the settings for the selected scenario and modifications would be accessible through a separate dialog (which could be later merged with the current options panel).

quick and meaningless ui mockup, but it seems that I start to enjoy gui programming :)

Actually, those first turn events already allow user editable settings, so options are probably not needed immediately, anyway.

I have a couple of reasons why I'd like to have options working asap. It's pretty hard to code a decent interface for a WML dialog. It'd be nice if the players knew the exact settings before joining the game. And, overall, this option-thingy is the most risky part of the whole project, so if it has any structural problems, those should turn out before we've put much effort in the other parts.

[Anonymissimus]

Settlers of Wesnoth has a victory point target and does not make sense as a modification.)

IMO, it actually makes perfect sense as a modification, but, being scenario-specific it should be only displayed for this particular scenario.

Thanks for bringing it up.
Well - what I would want in Settlers of Wesnoth (small (ok, giant) wishlist):
-Display this victory points option somehow before game creation (in the create game screen), which also means that *the host* and not *side 1's player* chooses it.
-Disallow most or all of the usual modifications choosing, such as leader, faction, income, use map settings, since most of it doesn't make any sense.
-Make sure that no eras or modifications other than the ones I explicitly allow can be used with it, since most or all of the usual wesnoth eras or modifications don't make any sense combined with it.
-And later on, display other options previously as well. Play with "tutorial" ? With this or that extra functionality enabled ? Those could be [game_mod]s included in the same (wesnoth) addon package.

ps: what about calling the tag [modification] ?

[lipk]

My heart is broken, but I have to cancel the plans about options. Mordante himself assured me that dynamic dialogs aren't possible with the current framework, and I don't want to bother with low quality static workarounds. Maybe later... moving on to the dependency check for now.

[lipk]

moving on to the dependency check for now.

...and so he disappeared in the mist.

Alright, I'm back on this thing. Dependency management is up and working, although there's no GUI yet, so you have to communicate via the command line. Because of the non-platform independent nature of consoles, I'm not sure if it works properly on Windows or OSX, it's tested under Linux.

Instead of the obvious recursive option, I decided to design the resolver algorithm in an iterative way, which is probably less flexible than the former, but it's guaranteed to finish in no more than three steps.

You need 1.11-svn to test this patch. Feedback is much appreciated. Don't forget to run Wesnoth from console!

I'll compile a "test suite" soon, till that:

Syntax

Code: Select all

[modification]
    id = mod_id
    name = "Modification's name"

    #Only the following eras can used with this modification
    allow_era=era_default
    #Only the following scenarios can NOT be used with this modification
    disallow_scenario=multiplayer_Weldyn_Channel,multiplayer_elensefar_courtyard
    #Only the following modifications can NOT be used with this modification
    disallow_modification=mod_dummy

    #require_modification is not allowed here!
[/modification]
[era]
    #The following modifications are required to play this era
    require_modification=mod_id
   
    allow_scenario=multiplayer_Weldyn_Channel
[/era]
[multiplayer]
    allow_modification=mod_id,mod_dummy
    disallow_era=era_default
[/multiplayer]


EDIT: the usual bug-discovered-just-after-publishing is fixed big sorry for that one downloader

[lipk]

Here's a new version of the patch, now with fully graphical interface.

Also an archive with some demonstrations:
- Anonymissimus' Plan Your Advancements Era, converted into a modification so that it works with any era
- Gambit's GambCiv, modified in a way that you're allowed to play on GambCiv maps only
- two little modifications alternating the victory objectives (they might not work properly atm, but that's not the point ). I coded them, however, the original idea belongs to zookeeper

Have fun with testing!

EDIT: I've cleaned up the code and sent it to Gna, so if you're interested in this project (ha-ha), you can keep track of the events at patches.wesnoth.org.

[Gambit]

-Make sure that no eras or modifications other than the ones I explicitly allow can be used with it, since most or all of the usual wesnoth eras or modifications don't make any sense combined with it.

I don't like this. It should always be up to the player what crazy crap they want to do.
That's why "use map settings" is a checkbox.

[lipk]

Welcome to the discussion, Gambit, better late than never
The dependency system isn't meant to be a "sense police" to tell users what they can do and what they can't. It's just to filter out combinations which are technically incompatible. Neither I am a Big Brother, though, to supervise how umc authors use existing features. So yes, we might want to add an "Ignore dependencies" checkbox...