Contested Command Job Slot Chance Change

[Guest Marlon Phoenix]

This suggestion is based on observation, and stats would be wonderful.

If we have a contested slot, where A B C and D want to be Captain, then if A gets the slot they should have a lower chance to get it next round.

We should prioritize giving a better % chance to get a contested slot to the people that get it the least.

This will give us a higher diversity of command players which will be a net positive.

 

[Arrow768]

Would be rather difficult to implement compared to the standard selection.

[Guest Marlon Phoenix]

Is it possible to flag someone who played Captain a previous round(s) (like 2) and put them at the bottom of the list of candidates to be picked out? Then just decide when to reset the counter.

Edited April 4, 2020 by Marlon Phoenix

[Carver]

There's an argument to be made for applying this to every role. I'm neither for or against it (As someone who hogged the Detective slot back in the day), as different doesn't always mean good.

[Guest Marlon Phoenix]

2 hours ago, Carver said:

There's an argument to be made for applying this to every role. I'm neither for or against it (As someone who hogged the Detective slot back in the day), as different doesn't always mean good.

I do remember when i was a detective main and one week id get it every round then for 4 months after that I'd get it maybe once a week.

Preferential bias job selection could be cool in these limited jobs, but I'm mostly concerned with command because of the importance in command players being present. And the more command players we have the more retention we get and we will hopefully have less "bleed-off" where command just settles into a handful of mains.

[Scheveningen]

Against it. The odds are already very even between two or three individuals competing for a single slot, and the chances of a single person getting their desired job is lowered dramatically with each person who intends to compete over it. There's no real need to get this formula any more complicated. A different person from the last round playing as captain for the next one does not necessarily guarantee that there'll be variety.

[Guest Marlon Phoenix]

The odds are not even and you can't prove they are without the data to support it. There is strong anecdotal evidence and observations in general that go against your arguments and support there being a bias. That is why I would really like to see data on this, because while I could be wrong the evidence is stronger over it being present.

And yes, there will be variety if a different person plays. The more people that want to play captain that get to play captain means there are different captains. I laid out the reasons why this is a benefit in the OP.

[Guest Marlon Phoenix]

Tracking the phenomenon using this method is ideal.

[Cnaym]

3 hours ago, Marlon Phoenix said:

There is strong anecdotal evidence and observations in general that go against your arguments and support there being a bias.

Explain this line to me please.

Afaik the system picks equal from everyone who readied up, disregarding how much or often they play or when they readied up before roundstart.

Total rounds played on a given day, while readied up at roundstart for a given command role, will increase your chance to play this role more often, since you have more total rounds.

Don't get me wrong, I think the idea is great, although hard to implement, but someone who readies up for every round will play more rounds in that role without it being an indication of a rigged or broken system ^^

[Scheveningen]

3 hours ago, Marlon Phoenix said:

The odds are not even and you can't prove they are without the data to support it.

Data doesn't matter when this is what the code literally does, which proves it is fairly random, though with caveats to priority specifics:

// New job giving system by Donkie
	// This will cause lots of more loops, but since it's only done once it shouldn't really matter much at all.
	// Hopefully this will add more randomness and fairness to job giving.

	// Loop through all levels from high to low
	var/list/shuffledoccupations = shuffle(occupations)
	// var/list/disabled_jobs = ticker.mode.disabled_jobs  // So we can use .Find down below without a colon.
	for(var/level = 1 to 3)
		//Check the head jobs first each level
		CheckHeadPositions(level)

		// Loop through all unassigned players
		for(var/mob/abstract/new_player/player in unassigned)

			// Loop through all jobs
			for(var/datum/job/job in shuffledoccupations) // SHUFFLE ME BABY
				if(!job || (job.title in SSticker.mode.disabled_jobs) ) //11/2/16
					continue

				if(jobban_isbanned(player, job.title))
					Debug("DO isbanned failed, Player: [player], Job:[job.title]")
					continue

				// If the player wants that job on this level, then try give it to him.
				if(player.client.prefs.GetJobDepartment(job, level) & job.flag)

					// If the job isn't filled
					if((job.current_positions < job.spawn_positions) || job.spawn_positions == -1)
						Debug("DO pass, Player: [player], Level:[level], Job:[job.title]")
						AssignRole(player, job.title)
						unassigned -= player
						break

In essence, the Low/Medium/High job preferences hold significance as anyone with a High Level job preference with a specific job will prefer to have that job considered first before being rolled through their other job preferences. Thus, if they fail to get that job, they're considered through their other medium priority jobs for that character as a fall back, as long as those medium priority jobs preference are set. If not, the person usually goes back to the lobby on this server.

The job controller randomly chooses among the subgroups generated by the tiers of job preference. 1 = High 2 = Medium 3 = Low. Therefore, if there is only one person with Captain on High, they're guaranteed to get the job regardless of whomever has Captain on Medium or Low in the other categories. This is so individuals can dedicate themselves to "main" a role if it is not in major demand, but any degree of High Level job preference competitiveness over a single roll throws this "guarantee landing my desired job" into total flux. So, there is an individual, predictable aspect of this where it relies entirely upon a player to ready for a job in the first place. But when several individuals want the same job, that's when randomness is at play. Because there's only one slot, only one person of a set sample group can have it. Out of a group of say, 3 people who want (all three have high priority preference for it, and are readied) the captain slot, guess what that chance is? You do the math.

Another thing is that theoretical probability !=  experimental probability. Flip a balanced coin 100 times, let it fall on your desk. How many times do you get heads and tails each? Supposedly, you should get 50/50 theoretically because it is a double-sided, balanced coin - in theory, right? Realistically, that won't always happen. Such as not getting that perfect 50/50 that you so wanted, but sometimes 52/48. Which is still *relatively close* to the theoretical posed, therefore the theory was still pretty damn good, it just couldn't account for whatever happened that made the two flips fluke out.

The factors that matter at play are:

1. The requirement of someone to ready for a role. 
2. If a person has a high priority role preference for a specific job, they are guaranteed to get that job over anyone else unless someone else readies in high priority preference for the same job.
3. A group of people who have high priority role preference for the same one-slot job are fairly chosen among the number of people who readied with the intent of that one job.
4. Role preference goes all the way down to secondary/tertiary/etc preferences, however many jobs you have flagged for medium/low preference, until you get that job. Note that you will always lose against other high priority preferences when you're filtering down to medium. 
5. All of this only rolls once. Whatever you get is final, based on what the job controller system succeeded in giving you.

Further, true, the odds are not totally even. They can't be even if the percentage chance of acquiring a contested role is an odd number.

Edited April 6, 2020 by Scheveningen

[Skull132]

Note regarding anyone crying "BIAS!" towards systems that involve randomness.

There is a horrible human fallacy to believe that "random" means "without logical sequences". The only meaningful way to evaluate the presence of a bias in any pseudorandom system is to do so over a very large sample size. And I do mean very large. True randomness (and thus, good pseudorandomness) is very likely to produce sequential output when observed over a small sample size.

Also, it is not as easy as you think it is to maintain state across rounds. Modifying the job selection code is also another form of ass. So hnrg.

In the job selection code, randomness is introduced in two places. First, the job list is shuffled. So we assign people to jobs at random points. Priority is used here, with high priority picks being picked first. The second point is that the "unassigned" list of players is also shuffled before touching it. So while job selection is, "Go down this list of unassigned players, find the first player who has it set at a given priority, and assign them," which would be a deterministic under specific scenarios, shuffling of the unassigned list removes this. So the whole process is indeed random.

What would be interesting to consider, though, would be to remove the priorities. ? Priorities are the most deterministic aspect of this process, and will have a noticeable effect. But this will also remove control from da players.

[Guest Marlon Phoenix]

In a fully random system there are points where things repeat. Flip a coin enough and youll end up getting heads 8 times in a row. Do it long enough and youll get tails 12 times in a row.

We are flipping a lot of coins for job slots and players.

46 minutes ago, Skull132 said:

What would be interesting to consider, though, would be to remove the priorities.

Is it not possible to instead flag someone when they get the job and have that flag put them on the bottom of the list next round? Then have the flag expire after that until they get the job again?

[Skull132]

1 minute ago, Marlon Phoenix said:

Is it not possible to instead flag someone when they get the job and have that flag put them on the bottom of the list next round? Then have the flag expire after that until they get the job again?

As I stated. Persisting state across rounds is not ideal. And touching job selection code is eough.

[Guest Marlon Phoenix]

Well im interested to see the result of whatever you implement, if you do.