CORDIAL MINUET ENSEMBLE

Hi. That's not it, because the assets are all unzipped on first run (this is handled by the SDL port, with progress shown over a splash screen) -- which takes over 40 seconds on my phone, for 8MB uncompressed! I assume this is CPU bound. Here are some timings for the part of the load time inside the native code:

Initial load time (to show 'Loading' screen): 6.3 sec
  *To load font (variable width): 6.1 sec
Time spent 'Loading' (in initFrameDrawer):  11.7 sec
  *Loading fixed width fonts: 3.6 sec
  *Constructing PlayGamePage (includes loading all other graphics): 7.4 sec
Total: ~17 sec

Time to read TGA files from sdcard: 0.8  (warm start)
Time spent creating Images from TGA: 4.9 sec

I see that the colour channels in Image are stored as doubles. Just converting chars to doubles is taking 5 seconds. Unlike x86, doubles are often far slower than singles on ARM chips even if they are supported in hardware. As I'm targetting the older (roughly for devices 4+ years old?) 'androideabi' ABI (which is ARMv5TE) all floating point code is done by calls to a library, which on my device (an ARM6) uses hardware FP support.

I forgot about halfFrameRate. That works nicely. I notice that the framerate improves quite a lot by the end of the round, when there are fewer pips in the score graph. It would be ideal to adjust the target framerate automatically. Does changing halfFrameRate or the existing framerate throttling on the pause screen cause recorded games to break?

I also tried compiling TCD for Android (just a matter of copy-pasting and adjusting the build script), and there are even more graphical artifacts there. Looks like drawing with per-vertex alpha is quite broken.

Interesting.

Could you provide stats over the last couple of months? I'd be curious to plot it and see whether there are any trends as new players join. Obviously it will need some smoothing. The problem is that if you simply did nothing, I would expect to see a significant shift in the next few days anyway.

My error, you're quite right. It turns out that all of that OpenGL code was getting pulled in by demoCodePanel.h, which you don't include ifdef RASPBIAN. I didn't read the comment and mistook that for honestly Raspbian-specific stuff. Which games actually use that OpenGL GUI code?

I fixed the screen resolution issue, which was partially an issue with the SDL port. The game mostly looks fine scaled down to 320x200 aside from ugly font edges and aliasing on the score graph, and I played a couple games on my phone.

I've decided to make a few changes so that the game is actually reasonably playable; that's what's taken me so long (most of these fixes could be shared with other port efforts). The significant remaining problems are:
-the up/down buttons for selecting bet sizes, etc, are way too close together
-the distorted brush strokes
-loading times on my emulator and phone are reeealllly long. On my phone it takes something like 5 seconds just to show the 'Loading' screen (it has to load the font first) and 12 seconds to load all the other graphics. Even a typical cheap android phone would probably be several times faster than mine, so maybe this isn't a serious problem. And aside from load times and animations the game is still responsive, eg the score graph still updates in real time.
-textures aren't reloaded when resuming the game. I guess it would be best to handle this behind the scenes, eg by making SpriteGL store a copy of the input Image. That would add only 7MB to memory usage.
-twice, I received a "Game timed out" message at the end of a round, after the coins had finished moving. I'm wondering whether this is due to the long time it takes the pot coins to crawl across the screen. Jason, is there a short timeout there that I might be hitting?

I've previously ported an SDL 1.2 game engine to Android by using the unofficial port of SDL 1.2. So I thought I'd see whether I could get Cordial Minuet running in one evening (conclusion: yes, by going to bed really late).

I encountered two main problems.

Firstly I realised, as Pox did, that Jason has only a partial GLES port; as far as I can tell he only has a trivial test program running on Raspbian, while various GUI functions like GUIPanelGL::fireRedraw still use OpenGL functions. I didn't encounter any problem with glMatrixMode, and I'm not familiar with the differences between OpenGL variants. No matter, CM only uses OpenGL 1.something, so I used jwz's handy wrapper (jwzgles) around OpenGL ES 1.x which provides an OpenGL 1.x interface. It was quite tricky to get this working with the right set of #defines, and it turns out I had to use Jason's GLES code anyway: he'd ported just enough for it to work.

Secondly, the build system is REALLY complicated. I still don't understand it, and I wish I hadn't tried. I spent nearly half my time just wrestling with it! (Turns out that I'd shot myself in the foot by trying to do things properly when adding a platform-specific C file to the build by adding it to Makefile.minorGems which caused it to think it was C++. There's no support for compiling C files in the build system, and I still don't understand how you're supposed to add platform-specific object files.)

Plus a bunch of other time consuming stuff.

This SDL port supports the native on-screen keyboard, but warns that invoking causes all OpenGL state and textures, etc, to need reloading. Indeed, I saw backgrounding the app and coming back does the same thing, replacing all text with white boxes. So I avoided it, and instead pushed my account key to the device. To my amusement, someone joined my 1c game immediately:

This is what it looks like while it's painting a stroke. Weird; it's actually the wrong colour. It's also really slow, but the android emulator is always slow on my system.

Afterwards, I ran it on my phone. My phone is a REALLY cheap and painfully slow Android phone with a 320x240 screen and no GPU. It did run, after taking forever to unzip the .tga files, but I didn't bother to try to get it working at that resolution.

I found that it doesn't play nice if the screen is less than 666x666. I expected it to scale down gracefully, but it didn't, even after I tried editing initDrawString and initFrameDrawer in game.cpp . Instead I just changed the resolution to 480x480 to match my emulator. There are lots of other issues I'll mention some other time. Much of my code can be contributed back to minorGems. I'll upload all my code and an .apk tomorrow, it's time I went to bed.

I know from experience that getting a ported game running on Android is the easiest part, after that you have to fix the game itself to work well on a phone. And just because I got this running doesn't mean that a HTML5 or SDL2 port isn't a better idea. The SDL 1.2 port I'm using is very messy, and designed to allow porting games from PCs with the minimum of effort, while also providing little ability to do things the proper way: it makes annoying decisions on your behalf.

That's called a Latin square.

This isn't a serious suggestion, but just an amusing variant of CM: neither player would have an advantage if you played two simultaneous games with one board a rotated version of the other.

I don't think that playing each board twice in a row would be boring; it would probably be more interesting, allowing you to more deeply analyse a board and your opponent's perspective. It could even speed up play.

Yes. Those two systems have advantages and disadvantages to one another, but I don't think any of those are major. So I don't know which to suggest.

A tournament isn't going to "eventually grind itself to a halt" due to exhausting all allowable (unique) pairups if the number of players is large enough, e.g. 40 players, unless we're talking days or weeks.

Forgot to reply to this:

What if you put a withdrawal "floor" on gifted accounts? For example if an account containing $5 is gifted then you can't withdraw those $5, and if the recipient works up to $7 in total then they can only withdraw $2 (the $3 cheque fee can safely eat into the floor, kind of like a gift card for bank transfer fees : ). Also, maybe after each game you could set withdrawal floor := min(account, withdrawal floor).

Yes, because I wish that the antes were larger, I usually try betting a fixed amount on the first turn. Some players oblige me, others exploit me. As you said, it doesn't work because it's not a blind bet.

When I brought this up before, Asminthe pointed out that increasing the ante would decrease the number of rounds, which I agree is generally bad. But wait, actually it's only bad if the number of rounds isn't boringly high to begin with. If conservative play results in potentially more rounds than both players are willing to play before getting bored, then increasing the ante/reducing coins might have less effect than expected.

I think that a 5 coin ante might be larger than needed -- 3 coins is still 3 times more, so shouldn't it still have a large effect? Also, I suggest increasing antes rather than decreasing number of coins, because often you will want to raise 50% of your current total bet, so still want granularity.

As for what you should measure: well, measure it all. I suggest trying to reduce the percentage of rounds that are "uninteresting": those where someone folds away only their 1 coin ante. Maybe plot the distribution of 'uninteresting round percentages' to see the difference between players with different styles and skills. For example, maybe 30% of games have rounds which are 80+% uninteresting. I think what everyone is asking for is to reduce "uninteresting" rounds/play. Alternatively, look at number of rounds (don't want to reduce that much) and average transfer of coins per round (it's possible that raising the ante doesn't have much effect on profit/round, because profit is dominated by a few rounds with big bets)

His Elo is 215 points above cullman. That corresponds to only a 78% chance of winning a game, so if he wins 100% of those matches his rating will keep increasing rapidly.

The Elo ratings of all the top players is probably still hundreds of points below the true ratings. It's going to take a while to pump them up to the true levels.

I didn't understand much of the description. It seems complicated. (Sorry if the rest of this is way off.) What's the winning criterion? Elo rank? Last man standing?  Elimination after Y losses, where different players complete games at different rates, implies that the number of games you win has no consequence. But it sounds like you mean that Elo rank is the winning criterion, and the last-man-standing system is mainly just a consequence of the 50% tribute. If you get a penalty to your Elo rank when you're eliminated from the tournament, and that penalty decreases over time, that sounds to be equivalent to "bonus points for lasting a long time". Which means that drawing out your games until the time limit could still be beneficial. Also, I don't see that what you described actually causes the Elo elimination penalty to actually decrease over time. "Lowest Elo rating of any remaining player" can move up and down.

Honestly, single elimination doesn't sound too appealing to me. Half of competitors would play a single game and get kicked out? There's still a lot of luck involved in this game, and besides, single elimination is an objectively bad system for determining the top 3 places. Tournaments aren't just about prize money. It's also about being at the same place/time that everyone else turns up for guaranteed serious, tense, play. I would hope to be able to play a series of games over, say, an hour. I guess you want to avoid that people stop playing games once they no longer have a hope of winning and thereby stop contributing to the prize. But I don't see a way to avoid that without an upfront entrance fee. On the other hand having a lower upfront commitment (a fraction of the maximum/total entrance fee) could also attract more players. Maybe tournaments just aren't what I'm looking for.

Thanks for the explanation. But...

What's the intention? You said that the $500 limit is per card rather than per user, so it doesn't seem that this is needed to prevent anyone from getting around the $500 limit. It sounds more like a measure to prevent cheating in tournaments. If I ever put up a bot, I wanted to create a separate account for it, so it sounds like I would have to ask for an exception. I was also thinking of creating an account for my sister, but she might not be interested afterall.

What do you mean by high level and low level strategies? I think that my problem is that I'm decent at picking columns and predicting the opponent, but really crap at betting.

Ouch! With the latest recompute, my score is pathetic! Loads of provisional players have leapt ahead of me.