CORDIAL MINUET ENSEMBLE

If you want to also penalise the loser less for losing after a long game (which I think is fair, because if you've lasted 20 rounds then you can't be playing much worse than your opponent), then the loser could also receive coins+tribute points, but then you have a situation where both players could receive positive points.

This is a problem that every CM tournament has encountered (with the exception of the amulet contest, due to its winning streak thing): they reward maximising your profit rate per minute, not profit rate per game (i.e. playing as well as possible). A structured tournament like a round-robin, Swiss, or double elimination, (or, I suppose, ranking by profit ratio instead of profit) seems necessary to reward those long games. I certainly hope we have those types of tournaments. Adding artificial points systems to change the incentives is sketchy.

Great, thanks. I see an individual query is limited to 100 results, but that's good enough for me; I simply polled repeatedly to grab all 10000 available events. The oldest available game is from Feb 22nd.

I've been polling the profit, elo/prov_elo, and top 100 dollar leaderboards hourly for a few months, but higher-resolution data is nice to have. There's a lot of variability in the Elo rankings (the multiplier is probably too large for CM), so I'd like to smooth them over games played and see what I get.

AnoHito, that API is great. But is there any way to fetch more than just the last 100 profit changes (for all players)? And is there anything else available?

Also, I notice that some of the user pages contain duplicated entries, for example http://minuet.isans.net/json/profit?user=cat%20flask

Also, was "minuets" a deliberate typo?

Not a dynamic executable? I'm running ldd against the 32 bit linux pre-built copy of CORDIAL_MINUET, and it's definitely dynamically linked. Maybe the ldd error actually indicates that it can't support 32 bit binaries because the 32 bit binutils aren't installed.

But yes, 32 bit compatibility libraries aren't included in all x86_64 linux distros. Some are minimalist and skip that stuff by default. Sadly that apparently includes Ubuntu. Jason, how do you get away without providing 64 bit binaries?

In my experience, there's a pretty small number libraries that need to be installed to run most packaged 32 bit games on a 64 bit linux system. But any distro should have an easy way to install them all.

Darn, I'm going to bed now.

I've been gathering clues since the beginning. I reduced it down to a single possibility (assuming you have a single account used since the beginning), but only because Josh mentioned you entered a certain tournament. But that alias looks sure to be wrong, never plays, low stakes. Maybe he had it wrong or I made a mistake. I should try again, but I haven't managed to gather any new information in months!

I think this (or something on the same principle) is a great idea, as it removes one of the incentives to spamming games and isn't a major change. I think it's definitely a flaw in the current rules for playing short games to be majorly advantaged.

However this only concerns one part of the problem: dropping unclaimed amulets. And that's actually only a small problem. Even during the launch contest, most games will be amulet games whenever there are less than 75 active players because of the 2N+3 players rule (number of amulet equal to about half the number of players active in last two minutes).

The flip side would be removing the ability to get in huge numbers of amulet games (as the challenger) by playing lots of fast games (which lets you funnel points to an accomplice with an amulet). That should also be achievable with some kind of timeout or counter.

I think many of these other suggested changed are far too major which makes them unappealing.

I've done very little network programming, but by coincidence I was looking for networking libraries yesterday.

Yes, SDL_net provides a low level interface, but I still think it's a pretty good interface. You might think that it's providing you with little (it's only 1500 LOC), or that it's hairy, but I had a look at its source, and it's sure shielding you from a lot of nasty gunk stuck in the drain pipes. Also, it seems that SDL_net can be compiled without a dependency on SDL.

I personally also wanted some library that provides more in the way of abstractions, and didn't come to any conclusion, except that if you ever want to do raw UDP networking, don't, use ENet instead (there are other libraries for reliable UDP, but ENet seems to be very popular). ENet doesn't do TCP, and while it reimplements most of TCP, if I want guarantees then I'd rather have all of TCP.

Sure sounds like a bug to me.

Regulating the number of active amulets is exactly what's needed. However, the problem with what you described (the simplified situation where an amulet is handed out for every non-amulet game) is that it's a very bad behaviour because amulets will keep getting handed out until either the supply of amulets runs out, or the supply of players runs out. In order words, the MAXIMUM number of amulets is distributed, so the system is doing no at all regulation (it's up to the players to drop amulets because it's out of control):

I had a look at the source code; the quote above describes it well but it misses a crucial detail (which is a mistake): ALL amulets waits concurrently for N games.

The way it works is the following:

-Every amulet has a counter users_to_skip_on_drop.
-When an amulet becomes available (timeout, dropped, or has never been owned), users_to_skip_on_drop gets set to number of non-amulet games being played - 1
-Any time a relevant non-amulet game* finishes, users_to_skip_on_drop is decremented for all amulets
-Any time a relevant non-amulet game* finishes, the last person standing gets the first available amulet with users_to_skip_on_drop=0
-In addition, when amulets are handed out for the first time it's staggered: one gets added at a time with users_to_skip_on_drop as above whenever none of the previous amulets are unclaimed

(*relevant if the last person standing doesn't have an amulet and has $3.)

What's wrong here is that this regulation is quite broken:  if there are fewer active players then amulets are handed out faster!! Actually, since the delay before an amulet is handed out is equal to the number of non-amulet games, the above rule tries to hand out one amulet every average-game-length minutes!

This is back to front. Consider the two extremes: firstly, there are no non-amulet games because almost all active players hold amulets. Then an amulet will always be dropped when possible! The other extreme: suppose are 36 amulets and thousands of active players. Suppose an average game is 5 minutes, so an amulet is dropped on a player roughly every 5 minutes. Occasionally a player with an amulet either discards it or walks away without dropping it. Consider a single amulet. If on average it's discarded by a player every 5min*36 = 3 hours, then the system can't reintroduce amulets fast enough to keep up with the rate they're being discarded, and that's not even counting time-outs. 3 hours sounds like what could actually happen, but repeat the calculation supposing there are 200 amulets and you will see the flaw.

(BTW: it's confusing to use 'drop' with two opposite meanings, so I'm using 'discard')

OK, so how to fix this flaw? Options 1 & 2: Scale the existing rate amulets are distributed by the number of active players, or perhaps by min(num amulets, constant * num active players). Option 3: try to explicitly maintain a ratio between number of players with amulets and active players without. Option 3 is similar to option 1 but more direct, but behaves differently when the players with amulets aren't looking for games: in that case option 1 hands out more amulets, under option 3 the other players are out of luck. And option 1 means replacing N (starting value for users_to_skip_on_drop) with a fixed constant. Something like 5-10 might do.

Is it me, or are a lot more games being played for 1c and other low stakes than usual? Could also be due to the latest batch of invites being sent out.

It's funny to know all those $3 games were just illusions rather than someone spamming them : )

So that means that entering the "Create Game" page and leaving it again doesn't just refresh the display but actually causes the score to be recalculated? Sounds like a mild bug: if your score is effectively -X (time penalty is larger than score) then you can increase the score you will have after your next game from 200-X to 200 by entering and leaving that page.

I agree with most of this, especially the problem with negative scores.

It's OK if amulet holders aren't in-game 100% of the time. For them to be in-game 50% of the time would only require about 50 active players. However if I understand correctly, if all amulet holders want to play amulet games only and there are less than 72 players active then pretty much every game will be an amulet game (ignoring the effects of the random delays, which I can't comment on because I don't know how they work). Is that bad? I don't know.

Also in practice a number of amulet holders won't be playing amulet games at any moment either because they're AFK and haven't timed out yet, or they want to be able to control the stakes they're playing at rather than risk $3, especially people who don't think they have a chance. I'd think a large fraction (half?) of the amulets would be out of play (not contested in an amulet game) even with enough active players.

An alternative to starting with more than 0 points when an amulet is dropped on you would be to just not lose any points until you play your first amulet game. But I don't see any need for people to lose points while they're waiting for an amulet game to begin anyway, which is also a partial solution. (They could still lose points while actually in-game, to reward people with a higher profit/time ratio.)

I also agree with the suggestion to allow amulet holders to play each other. There's two options: either randomly pair up those waiting for amulet games if they've been waiting too long, or allow amulet holders to end up in amulet games when they tried to play a regular game.
In both cases, I suggest that the winner of a double-amulet match keeps their amulet, while the loser of a match loses their amulet only if they tried to play an amulet game. Using this rule you don't really need to add a "drop amulet" button because you can continue to play regular games against anyone (without endangering your amulet or winning points or being in the running for any other amulets), and it only requires a server change. However, this doesn't cover the case where you want to drop your amulet to get a different one. But is it a good idea to assist people to do that?
I don't see anything wrong with randomly pairing up two people waiting for amulet games either.

Found another bug: after you have an amulet and lose it, hovering over "New Game" in Create Game continues to display "Create a non-amulet game"