??????
You are not logged in.
The goal is to have a tournament hosted in situ on the main server without too much fragile structure. Pretty much a free-for-all of some kind, where winners are determined after a reasonable amount of time.
A few challenges:
1. Funding the prize pool. The normal house tribute is so small that thousands of games would need to be played to fund reasonable prizes.
2. Players setting up dummy accounts to collude against, beat easily, and increase their ranking in the tournament (for score-based tournaments).
3. Players waiting to join until the very end to increase their chances of winning first place (for knock-out tournaments).
I think I've come up with something that solves these problems.
First, the prize pool could be funded by making every tournament table winner-take-all (you leave the table, you lose your stake), and setting the house tribute at a flat 50% per table (so the winner walks away even, the loser or leaver walks away with 0). The loser's half of the buy-in would go into the prize pool. If the tournament stake level is X, and G games are played total, the prize pool would be G * X. Finally, the winners of each table would have "free" money to use to play additional opponents (they get their money back by winning a table). I.e., loser's stakes fund the prize pool.
Second, to eliminate re-buys, the tournament could be single elimination (or maybe we could set it to a limit of Y eliminations). You lose a table, and you're out---the server simply blocks you from joining another tournament-flagged table this tournament.
With this structure, we could have a nice last-player standing mechanism, along with potentially ranking player tiers based on how many games you won before being knocked out.
Third, to deal with the problem of weird player orderings (you've won two games, get paired with a player who has won three games, and you win, so now you and that player are tied in terms of won games, but they're knocked out, and there's no one left to play) and also playing against dummy accounts to stay in and rack up your win count, a we can add a scoring system on top of this.
Essentially, players could be ranked by a separate, tournament-only Elo that starts at 1000. When you lose, your tournament Elo goes down, and then you're knocked out. The knock-out is important to prevent weaker players from throwing money at the tournament to harass the top player with last-minute challenges long after the tournament should be over.
Thus, who you beat, and how many people you beat, matters. Latecomers are penalized by starting back at 1000 while all the earlier players are higher. Colluders get less and less of an Elo boost from each dummy 1000 account they play against. We start expecting them to beat 1000 accounts, while the top legit player will have a much higher Elo from playing other legit players who are also rising up. So, even if the colluder finally faces and defeats the top player, the top player will still have higher tournament Elo in the end.
Instead of a time limit, the tournament could run until last-player-standing, with an inactivity timeout in place to automatically eliminate players who are dragging things out (if you're not waiting for a game or in a game for X minutes, you're out and get docked Elo as if you lost against the lowest Elo player who is still in).
With this knock-out structure, the prize pool equals the buy-in times one less than the number of players. 21 players at $5 each makes a $100 prize pool. Winner takes half, second takes a quarter, third takes an eighth,
If we allow rebuys (double or triple elimination) then obviously the prize pool could be larger.
Are there any holes in this idea?
The $500 cap is for anyone who hasn't shown us photographic proof that their credit card is legitimate.
Imagine someone coming in with 5 stolen card numbers, charging up $5000, then withdrawing it all or simply losing it all to other players. A month later, the owners of those cards notice and reverse the charges. $5000 is already gone by that time, so I'm stuck with that loss.
So, if you're going to put in $500 or more, you have to provide us proof that you're you and that your name matches the name on your card. Essentially, proof that you approve these charges. Another example is a kid using a parent's card without permission. If you're going to use your mother's card for $500 or more, we need to see a photo of her approving the use of the card (so we know she won't reverse the charges later).
The proof is marked on a per-card basis, not a per-user basis. So, once you cross the $500 mark, you need to send proof for each additional card you want to use.
Finally, the server blocks more than one user from paying with the same card. Stripe has a nice feature called a card fingerprint that lets me remember and recognize a card uniquely without storing the card info itself in my database.
Anyway, $500 felt like the limit of reasonable loss for me without inconveniencing everyone too much.
Hmm... please send me your game recording right away next time it happens. Also, if you're on windows, you could send me your stdout.txt.
Did it seem to be timing out around that time (failing to connect to server)? Like, red [!] showing up? Or just DENIED unexpectedly?
Okay, I changed my mind here.
I can imagine it's demoralizing as a new player to watch your rating get beaten down. So, all players start a 1 now, and that's the floor. If you lose a game at 1, you stay at 1.
I was worried about how a floor would inflate upper ratings, but given that all players are in the same pool, and everything is relative, it kinda all works itself out, because the upper players will just have ratings that are that much higher.
Finally, if we're going to have a floor, let's do away with this arbitrary 1000 nonsense. You start at level 1 and go up from there (zero is itself a demoralizing number).
It is interesting that putting a floor in changes the order of the resulting ratings on recompute. For example, Vegetable Duty was 10 before and is now number 3.
Whoa, that was a huge bug. Fixed it and recomputed.
New global average Elo: 987
New non-provisional average Elo: 1011
New provisional average Elo: 983
Well, I wanted "Victory" to match with money victory and not be something else. If you're expected to win money against a weak opponent, but your opponent chips you down slowly over time and you walk away with less money, then you didn't match our expectation (your opponent played better against you than we expected).
This is certainly a little weird, because the expected score is off for evenly matched opponents. If players have identical Elo, our expected score is "0.5", or "tie," but evenly matched players in reality wouldn't tie, they'd chip each other down and both lose money.
Still, I wonder how much this happens in practice.
Okay, data. In CM history of 1522 games, both players have walked away at a loss in 27 games, or less than 2%.
Anyway, this is where I got the idea of provisional ratings to prevent overrated new players from pushing up the scores of existing players (inflation of the existing player base Elo when new players come in):
http://stackoverflow.com/questions/1881 … tart-value
This would obviously cause deflation in the average, while at the same time maintaining the average of the established playerbase.
It's also interesting that if there's a balance between over- and under-rated players coming in, then there wouldn't be inflation here (some players would lose points to nobody, others would gain points that are taken from nobody).
It seems like a rating floor would inflate the ratings of any stronger players who played against the sub-floor players. E.g, if the floor is 1000, why play against a true-score 1001 player to gain X points when you could play against a true-200 (floored at 1000) and gain the same number of points? Granted, we can't pick our opponents here, but any player that did "luck out" and get paired against a below-floor player would get an unfair Elo boost.
The same problem occurs if you assume new players are correctly rated at 1000 and let them into the pool. If they are overrated, anyone paired against them gets and unfair Elo boost, while players paired with true-1000 players don't get the same boost.
It is also interesting that new players can affect other new players in exactly this way. I could fix that so that provisional players don't affect the ratings of other provisional players (your rating only changes when you play a non-provisional player), but then bootstrapping the whole thing becomes a problem (when I recompute Elo, I roll the whole system back and start everyone as provisional 1000).
Okay, leaderboards have been fixed so that the live game buy-in is taken out of all the formulas.
Thus, you can no longer watch the leaderboard for small changes to figure out who you just joined a game with.
The leaderboards update instantly as soon as a game ends, however. So, you might be able to tell who you just played against.
Well, that's the thing... Elo isn't really injected by new players.
Everyone starts at 1000, so if we left it at that, the average would always be 1000.
But to combat inflation of existing players who feed off of overrated new players, new players have provisional Elos that change for 20 games WITHOUT changing the Elos of their opponents at all. This also combats deflation of existing players who get trounced by an underrated new player. But in general, we'd expect new players to be worse than average, so we'd expect them to be overrated.
Anyway, those extra points, until their Elos settle after 20 games, are lost. This means that the average will slowly drift down from 1000, assuming that most new players are overrated.
Another idea here:
Fixed stake timed tournament, winners chosen by same profit metric as before.
But make the tribute very large, like 50% of each player's chips.
Finally, force every table to play until the end (give all chips to remaining player when one player leaves), so a loser at a table can't punish the winner by leaving early.
So, whichever player "wins" the table breaks even. Whoever loses the table loses the whole stake.
A player with two accounts would lose as much to the rake as they transfer to their other account as a profit stat, and be further punished by table hopping to find their second account.
However, the problem of collusion still remains. Yes, they lose 50 cents every time they collude, but they push the profit on their target account up by 50 cents too, making them more likely to win the grand prize, which will likely be way more than they lost to the tribute (if not, then the prize wouldn't be worth winning).
This is also a problem with your idea above Mzo:
Because you lose 10 coins everytime you collude and that only grows the pot by 8, even if the only players in the tourney were your accounts you still couldn't profit.
Yeah, you lose 10 to grow the prize by 8, but don't forget that other players are growing the prize too. You lose 10 to give yourself an unfair chance of winning that prize, which has grown by 8N in the mean time (where N is the number of pairs of other players). If you have to win X matches to win, fair or not, then the prize would have to be worth more than 5x. But the winner is likely to lose money along the way too, so the prize would have to be even bigger.
I guess as long as the prize is less than 10x, though, we're safe from a colluder winning by collusion alone. But if we set it at 9x, a colluder would still want to collude a bit to gain an edge.
Still, the "huge tribute" version at least funds a substantial prize. It has a much bigger drop-out problem, though, because continuing to play means just breaking even even if you win each match from here on out (though winning each match would probably put you back in the running to win). Point is, losing a match hurts a ton here. People would want to cut their losses, which means the prize pool would grow really slowly at the end. Maybe this is okay, as the final few players fight for places.
Well, it shouldn't be higher on that screen. Should be the lowest CPU screen in the game (fewest fonts drawn). Let me know what you unearth there.
How is it slow on that screen? It chews CPU?
Your idea for prizes funded by the tribute is a good one. The problem is that the prizes would be pretty small that way. How many games would you have to play, and how many buy-ins would you have to risk, before the prize got big enough to be worth it?
After all, in the last 2-hour tournament with the 5-chip-each tribute, the TOTAL tribute for all tournament games was less than $4.00. That's a pretty small prize pool. Yeah, it could last longer, which would make it bigger. But for the prize pool to approach an interesting amount like $100, we're talking 25x longer or 25x more people. And there's still the drop-out problem. If you're way behind, why keep playing these high-tribute games? Better quit tournament games and go back to regular tribute games. Which means the tribute/minute would dwindle over time.
The cool thing about a tournament with an entry fee is that the fee is paid up front and can't be taken back out, so the prize pool is known at the start of the tournament.
I think many of the problems you cite with the rising stakes model are also problems with Poker tournaments. You could play slow for a long time, as long as possible, while other players are dropping out. In fact, you SHOULD do this. So what? If that's what everyone is doing, there will be a "best time" to start playing. Maybe waiting until the buy-in hits $5 is optimal, maybe a bit sooner. Or maybe playing the whole time, so that by the time the buy-in is $5, you have $25, would be better. As long as we're all playing by the same rules, it doesn't matter. "Figuring out" how to win a tournament would be an additional skill.
Which is why I'm not too keen to just adopt the Poker tournament structure---it's widely recognized that the skills that make you good at tournament Poker are DIFFERENT than the skills used in regular cash game Poker. The winner is the one who is best at tournaments.
Poker tournaments also assign you to a table where you must play. You can just fold forever, but you'll still be hit by the big and small blinds every 9 hands. You can't pick your opponent or leave a table when there's a strong opponent there. As players drop out, tables are consolidated, and it eventually gets down to the final table and then final 2 players.
Mzo, if you're interested, maybe read up on tournament poker and their problems and report back? I've got a lot of balls in the air over here.
Staying in a Holdem hand instead of folding does reveal progressively more information about your hand (each new table card shows them a card that is NOT in your hand). Yes, the narrowing is way more extreme in CM.
I get what you're saying about not wasting time. I'd say, "Sure, I'll turn on that button," but I'm wondering if its presence would confuse some players. If the fold button is there, it kinda implies you have to risk more to continue, so some players might not realize they can continue for free.
Yeah, mzo, that's possible, but it would require quite a bit of digging to get everything setting that flag correctly.
Really, there are only a few moments that would be CPU-reduced by this. While you're dragging a slider, it would go back to 60 draws/sec. While you're waiting for your opp's move, it would be doing 60 draws/sec (smooth waiting icon). When moves/bets come through, back to 60 draws/sec. Waiting for a game to start, same thing (though that screen uses a lot less CPU as it is). It's really just those rare moments where you're staring at the screen, not mousing over anything, that would save some CPU. So... is it worth it?
It's also just not what I'm used to doing, because most games have no static moments at all.
You mean draw all the graph pips into their own texture, and then just draw that texture if the graph hasn't changed? Yeah, that's possible.... but since I'm using the OpenGL drawing routines to draw sprites, I'd have to either write my own drawing routines to draw to a texture OR draw to the screen once and then read that bit of the screen to make the texture.
Poker rooms allow you to fold when you don't have to, but they throw up all kinds of warnings... ARE YOU SURE, WHY FOLD?
Essentially, folding when you don't have to is always sub-optimal play. Just because you got the banana on the first pick doesn't mean you're going to lose, but folding guarantees it.
More data here:
On my old slow laptop from 2000, I see my framerate dropping as the round progresses (as more pixel-heavy brush strokes are added). Probably exceeding the fill rate of my integrated graphics card.
HOWEVER, I also see the CPU usage dropping. It's cut by more than half by the end of a round. This is because far fewer sprites are drawn at the end when the graph has cleared out.
At the start of the game, that graph has 300 sprites in it, making it CPU heavy to draw. By the end, the number of draw calls drops, reducing CPU load, but increasing GPU load because the sprites being drawn contain a lot more pixels to fill.
Okay, so I fixed it so the pickers don't jump around when halfFrameRate is high.
Also if you pull minorGems, there's a fix in there so that you can push halfFrameRate as high as you want, and the frame rate will bottom out at 1 fps instead of hitting 0 and crashing.
I'm using a standard update draw game loop that I've used in all my games. Yeah, it doesn't make as much sense here when nothing is changing so much of the time. But you're right that deep architectural changes would be needed to fix it.
Essentially, it's easy enough to just not draw the screen. The problem is detecting when it's okay to skip drawing. There are so many distinct parts of the game that draw to the screen that the "need to redraw" framework would need to communicate with all of them (for example, when waiting for your opponent's move, the little waiting icon is changing, when mousing around, you can mouse over a picker or button and it should change---each of these things would trigger a full frame redraw).
Hmm...
MERCHANDISE!
See this post where I updated the explanation:
http://cordialminuet.com/originensemble … .php?id=59
Oh, I fixed it.
Now it treats each player in isolation to determine their score for the game. If you lose money, it counts as a loss for you, regardless of whether you have more chips than your opponent by the end. If you gain money, it counts as a win for you. It's only a "draw" if you leave even, regardless of your opponent.
Thus, "doing well" in terms of Elo is the same as making money at the game.
Finally, your Elo change post-game is simply weighted by how many chips moved by the end, including the house tribute.
Thus, if you walk away 1 chip up after one round, neither Elo will change much. But if you walk away 1 chip up after 100 rounds (and your opponent is down 25 chips, 24 taken by the house tribute), then both Elos will change more.
So, this balances the two factors.
Whether you won or not depends on whether you walked away with a profit or not.
How much this will affect your Elo depends on how much you trounced your opponent (or how much you were trounced).
And happily, you will NEVER win money and have your Elo go down as a result. You will NEVER lose money and have your Elo go up as a result.
(One unfortunate side-effect is that Elo changes are no longer zero sum, which means the Elo average can change over time... when both players lose money, both Elos go down by the same amount---though this does kinda affect the nature of the game, so slight Elo deflation is probably okay).
Elo ratings have been recomputed using full history, with some interesting results.
Yeah. Working on fixing this. I think I misread your suggestion for weighting based on chips taken. In the current Elo, chips taken is your score. I think I should still have binary win/loss as score, but weight the effect on Elo based on chips taken. Then, your Elo can only go down when you lose chips, and only go up when you win chips, but the amount you go down or up will depend on how many chips.
Yeah, they're overshooting and then moving back to correct. I'll fix this.
In terms of CPU, there are simply a lot of sprites being drawn each frame. I would think that would be GPU-intensive instead of CPU-intensive (because each sprite is already loaded into GPU texture memory), but maybe there's enough code around each draw call to load down the CPU as well (and I have seen CPU being used quite a bit by the game too). I'll look into it.
Yeah, there are problems here for sure.
The good news is that I can manually recompute Elo for everyone using the full history at the push of a button, so we can change the formula as much as we want going forward.
Right now, "fraction of chips taken" is your actual (and expected) score. We expect you to take X% of the chips based on your relative rating with your opponent. That doesn't really make sense intuitively, as you point out above with the player who left three times and lost the same amount.
However, if this is the way the Elo works, then you could imagine that this would all work itself out, with the expected number of chips taken floating around how many chips are taken in practice, etc. Leaving before you lose too many chips would never be as good for your Elo as staying and making a comeback.
The other option would be to track binary win/loss like Chess, but then factor the number of chips taken in the K factor. "Your rating will go up whenever you win chips, but it will go up more if you win more chips."
Then at least your rating would never go DOWN as the result of winning chips. Currently, you can win fewer than we expect you to win and have your rating go down.
Looking at the top established Elo vs the bottom, we expect that top player to take 77% of the chips in each match with the bottom player. If they take only 50%, their Elo will go down!
It does suck that the other leaderboards give realtime information about who just bought-in.... hmm... I'll have to figure out how to fix that.
Well, what I'm "fine" with is different than what I want to actually build into the game.
There's a certain aesthetic experience that I'm shooting for, and playing randomly isn't it. It's very important that the game, as an object, embodies the target aesthetic experience exactly.
So, for example, I'm not going to put a chatroom in it. But third-party chatrooms are fine---and even exciting---to me.
I love the idea of people developing bots for this game, but I'm not going to build a bot into the game, because this is a game for humans at it's core, and I wouldn't want the average player using a bot (or random picker) as their core experience.
I didn't want players NEEDING a calculator or doing combinatorics in their heads as their core experience, so that's why I built the score graph in. But I did want them considering strategy beyond the combinatorics, so I didn't build-in any strategic aids beyond the graph.