Red Team / Blue Team and Fighting Self


#1

Just a question on how Red team and Blue team are supposed to work. I recently created a Blue team to test improvements on a code in Treasure Trove. Now half of my Blue team matches are against my Red team. (5 of the last 10 and 3 of the last 5)

This has raised my Blue score by a lot (pushed it to the top 10), but completely destroyed my Red team score (My Red team has posted 61 losses to my Blue team in the last 3 hours).

Are you supposed to fight yourself so much?

update:
no longer in the top ten. Tried a code optimization… Finally got it working, but not before it destroyed my rankings (anyone simulating my games will be more happy though). Now I’m going for the red team leader board instead of the blue. Going to take a lot longer…


#2

Well, it also happened to me, and I also found it strange:

screenshot 1

https://files.slack.com/files-pri/T0DEDCL22-F0F6DHWJH/pasted_image_at_2015_11_24_13_32.png

screenshot 2

But it might be absolutely normal: I guess that “blue team you” and “red team you” are considered totally separate entities…


#3

They are treated as different players, but the rate of competition is too high to be random. I wonder if it is a method to keep the same people off the top of the charts for both the red and the blue sides.

In other news I made it back to top 10. Yay!

Ranking Image

How do you do the thing with the spoiler text? I can’t find it on the posting guidelines page.


#4

Use the [details] or [spoiler] tags, as described in the FAQ

Cheers


#5

Thanks. I see it now.


#6

The problem is that those old levels bias some of the rankings towards recently submitted sessions, which means if you submit both your sessions recently, then they’ll both get a lot of plays. The simulation selections really need some work, but it’s a bit hard to determine what the optimal selection should be when there are tens of thousands of players on a leaderboard and you are limited in what you can effectively query for due to your database indexes.


#7

Looking at the code, I am getting the basics of what is happening although I don’t even know what a quarter of the methods are or why they are being called.

I have been doing programming for less than two months so I am wondering if this solution is possible:

Start with a Math.Random() to choose ogres or humans then use the current favor recent method to choose a player.

Since the skill of players submitting is randomly distributed you could choose an opponent for the player non-randomly by sorting the database by player start date (which I am assuming is the date they submitted the session for ranking) and then working through the list backwards by having a property attached to the player with the last played opponent start date and looking the next value earlier than it. It would have to start with the property being the player’s own start date. If there are no more players earlier, then the last played opponent start date could to reset to the most recently added player. You would play players who submit after you by having them call you as their opponent.

That system has the benefit of ensuring that everyone only plays another player once until they resubmit without needing to keep a list of everyone played. It will also favor recent submits and will reduce the time the severs spend doing simulations that it has already done once before.

Edit: This is for external league play ,even though many of my replays are probably caused by me having the only blue team in my very small clan.


#8

Well, “blue me” just beat “red me”, thus pushing “red me” out of the top 10 in Treasure Grove… :rage: Shall we call it an issue?


I also noticed that on Dueling Grounds I have a match history of “186 Wins, 14 Losses”: 13 out of 14 losses are against the same player. I don’t complain that he’s better – but that also means that during my last 200 matches I fought against the same guy 13 times out of a pool of 65000+ players…


#9

Might be worth adding as an issue. There should be more fighting among the top players as well to help determine who is at top. It would require some testing to work out. Luckily there is Wakka Maul, the ladder no one cares about!

I’m also #2 on this one…


#10

I’m down to #25 from #11 (or so), because in the last 20 games I lost against my own code 15 times… :cry:

update: the situation is getting worse: my “red self” has now a balance of 127 Wins, 73 Losses – out of that 70 losses are against my “blue self”… :cry: :cry: :cry:


#11

@Hinkle I like that solution and even started to implement it, but then I realized there are two problems: 1) if the favorRecent method of picking the first session picks the same session for multiple simulations in close succession, then each simulation will pick the same opponent, so you’ll get clusters of duplicate matches; and 2) the issue is, as you point at, mostly due to the league-based simulation picking.

@ant Look at your Example Clan league –there are only a few players on it, and when you simulate (or when anyone in that clan simulates), a match between players in that league is much more likely. We do this to make sure there are any league matches simulated and so that you get more of your own interesting games played when you simulate. However, when you oversimulate a small league like this, you get tons of repeat matches, and currently the simulation doesn’t know how to avoid those, so particular matches will repeat and have an oversized effect on your scores (even on the general ladder).

Still trying to figure out what to do about it…


#12

I think I’ve come up with something good that applies Hinkle’s suggestion to leagues, and also doesn’t rematch yourself vs. yourself all the time. Give it a shot and let me know how it’s going now.


#13

Thanks for your answer. After reading it, I have a “few” questions:

  • (I was not aware of clan leagues… But) why such a strong preference for matches against clan members? Why not just “blend in” clan members for every nth simulation? Or once you fought all your clan members n times, just skip them for some time?

  • If I quit my clan, does it change things?

  • I also created a private clan, which includes only myself. Does it mean that I have 100% chance of fighting myself?

  • Why do you prefer recent submissions? “Old” sessions are not good enough?

  • I didn’t check the method for game selection, but I thought it’s something like “pick someone randomly within (e.g.) +/-200 places of your current ranking and fight it”. Would that be too simple?

  • Could some minor improvements (as mentioned here) improve the current selection method?


Another method of game simulation and ranking:

In another game I played years ago, the ranking was done on the basis of “tournaments” which were run twice a day. Groups of 8 players were selected randomly (on the same level +/- 1); a tournament was simulated for each group, and the best 2 players (if I remember correctly) in each group got a certain amount of ranking based on the difference of the ranking of their opponent (bigger difference = more ranking earned).

I know this is cannot be applied here directly, but you may find some ideas that give a more balanced game selection.


#14

Seems to be working. Around 15 hours ago (from now) I stopped having lots of battles in the global ranking against members of my clan (including myself.)

I submitted a new cavern survival code to blue. I will see how that works with the new system.

Now we will see what that will do to my rankings…


#15

If you run out of clan/course league matches to simulate, you will simulate other random matches, so they do end up getting skipped for a while then. We use a strong preference for simulating your own leagues because most people simulating aren’t in any leagues, so this balances it out a bit, plus you can more directly cause games you’re waiting for to show up in your rankings (because you are part of your league).

If you quit your clan, it should remove those leagues from your multiplayer sessions, but it doesn’t yet until you resubmit the sessions after leaving the clan.

I think you will just fight yourself once for every time you submit due to that particular clan that just has you now.

Old sessions are from players that don’t care as much about the rankings (or they would be resubmitting to increase their score). Players who have just submitted are waiting for rankings, so we simulate more games for them so that things update faster.

It turns out that it is slow to pick things randomly based on complicated queries like “score is near mine”, plus you may not play players too far below or above you, and it will be hard for your score to change. And on levels with huge numbers of players, score within +/- 200 places may be very, very similar. We do grant more score based on the difficulty of the player you beat relative to your own strength, so playing players similar to you doesn’t change your rank as much a beating someone far above you, and that makes it take a long time for good strategies to converge.


#16

Is it possible use the clan system to increase the interplay in the top rankings?
If we auto appended everyone with a score above 8,000 (or who beats Thoktor) to a ‘Dueling Grounds Champions - Red’ clan they would play against each other much more often without the need for another random choice system.

Update:
Checked my recently submitted cavern survival - the burst of selections problem you mentioned in an earlier post (I played myself 3 times in 2 min) happened, but that could have been from clans or normal play as they were both recently submitted. After that, no more plays. In the last 190 matches I have only played myself 3 times. Good fix. :smile:


#17

Thanks for the detailed answer.

I’m a bit concerned about “old” sessions, though: if you check the top 20 players of the ladder, usually there are only a few submissions from the last week(s), all the others are several months old. Those players will probably not resubmit their code, because it’s already good enough :wink: and resubmitting causes an immediate drop in the ranking (as discussed here and here). But that means you will rarely fight the champions… and that means probably less chance for new submissions to climb to the top and less chance to challange the “champions”.

Dueling Grounds, for example:

Also, what is considered “old”?


#18

It would be odd if more than a few in the top 20 were old. Assuming the mulitplayer arena 10 months old (because it makes the math easier) There should be somewhere around 4 in the last month in the top 20. Which is the case. There 5 if you count Chronist Gliverbind.

Fine tuning any mulitplayer stuff can probably wait until after hour of code though… I just noticed all the updates recently to get it ready.


#19

Yeah, there should definitely be more churn at the top; I haven’t thought too much about how to incentivize that yet in a way that would work with the indexes we have and without knowing what the score range for a specific ladder should be. Here’s the logic for determining the recency weighting.


#20

I think of two ideas that may work.

Retire old code. After 3 months or so code needs to resubmitted. Any code that is in the top 10 when it expires has the writer added to a ‘hall of fame’ like how the winners for zero sum and ace of coders is displayed. It gives due props to people who spent a lot of time getting to the top and also makes room for new people.

Hall of fame could be ranked by highest place attained with number of times code hit the top ten determining who wins ties (to encourage re-submits), and then by score when code expired

Use the current function and win / lose ratios to determine if a code is strong and have strong codes play against each other. After 100 matches, if 90 or more are wins the code is marked as strong. (if 90% are wins they are probably at least in the top 10% for score or would be there if given enough time)
Add a second match function that will randomly get called that doesn’t rely on time but instead has 2 randomly selected strong codes fight against each other.
After the next 100 matches the win / lose ratio is checked again. If it is under 60 (lower now because the code is fighting stronger opponents and time has passed, so it might only be fighting strong opponents) it looses the strong modifier.