Advanced game configuration

[timparenti]

A typical game of CtFwS is run with parameters setup_duration=900, rounds=4, round_duration=900:

I.D.6. Every fifteen minutes, starting from the beginning of play, all prisoners are released from all jails. …

I.E.1. At the beginning of the game, there is a setup period of fifteen minutes. …

I.E.2. The game begins at the end of the set up period and ends after one hour, or when there remains only one team with uncaptured flags.

ctfws-timer-web/scripts/start_game.sh

Line 66 in 67132c8

m="$d 900 4 900 $num_flags $game_num $territory"

Unfortunately, these durations are very long for testing purposes. :(

Additionally, head judges may wish to have the flexibility to modify these gameplay parameters, especially for later games:

[email protected]. The judges may choose to change the rules or add or remove stuff into the game. …

It should be possible to override these values from the Judges' game panel, perhaps behind an "Advanced" link in a similar manner to the "Hide messages…" panel implemented in bfe79e1.

[nwf]

Not to say that we shouldn't do this in the judges' UI, but, for testing, I find using the mosquitto command line tools sufficient. https://www.ietfng.org/nwf/ee/ctfws-iot.html has the commands at the bottom for (my) ease of reference. :)

[timparenti]

That's reasonable for testing cmukgb/ctfws-timer-iot and cmukgb/ctfws-timer-android, but currently these parameters are also hardcoded elsewhere in the configuration for the web interface:

ctfws-timer-web/templates/timer.html

Lines 144 to 151 in 67132c8

	rounds: {
	// Number of jailbreaks. Set by the broker but always should be 4.
	total: 4,
	// Jailbreak length in secs. Also set by broker but always 15 min.
	duration: 15 * 60,
	},
	// Setup length in secs. Also set by broker but always 15 min.
	setupDuration: 15 * 60,

[michaelfelixmurphy]

Those are hardcoded only as initial values. This is so that the UI looks reasonable while the MQTT data is loading. They update to match what's on the broker:

ctfws-timer-web/templates/timer.html

Lines 381 to 388 in c687837

	if (!isNaN(start) && !isNaN(setup) && !isNaN(rounds) &&
	!isNaN(roundlen)) {
	this.times.start = start;
	this.setupDuration = setup;
	this.rounds.total = rounds;
	this.rounds.duration = roundlen;
	this.flags.perTeam = flags;
	this.gameNumber = gamenum;

As such, I feel like the MQTT tools should be good enough for testing. I can leave this as a low priority because the judge should be able to do it. The main barrier right now would be adding more optional arguments to the start_game.sh script.

[timparenti]

FYI: At today's Rules Committee meeting, a proposal was discussed to modify the timing of jailbreaks to avoid people sitting around doing nothing for too long, as games have been smaller recently.

[michaelfelixmurphy]

Thanks for the heads up. If this passes or is decided to be done as an experiment, let me know. It won’t be that hard to implement custom timing, but it’s not my priority right now.

…

On Mar 31, 2019, at 12:56, Tim Parenti ***@***.***> wrote: FYI: At today's Rules Committee meeting, a proposal was discussed to modify the timing of jailbreaks to avoid people sitting around doing nothing for too long, as games have been smaller recently. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[timparenti]

In F21, games 2 and 3 were played with (setup_duration, rounds, round_duration) values of (1200, 4, 900) and (600, 3, 600), respectively.

In order to accomplish this for the event, I hacked on a personal copy of scripts/start_game.sh just enough to allow for what was needed by explicitly specifying the custom config. #21 is my somewhat more robust attempt at amending the script to take optional parameters --setup-duration, --rounds, and --round-duration.