CORDIAL MINUET ENSEMBLE

I've realized that the prizes jumping down when just one more player joins at the threshold for one more player receiving a prize is hard to fix.

Say there's a number of players such that 4 should win a prize.  As you add more players, you eventually cross the point where 5 should win a prize.  Before you cross that point, the prize pool is growing linearly, so those 4 winners prizes are growing linearly.  Then one more person is added (one more entry fee), but the whole prize pool is now divided among 5 players instead of 4.

If P is the number of players who each pay E, and V players receive a prize, we have the average prize equal to:

EP / V 

Now we add one more player, crossing the threshold where V+1 people should get a prize.  The average prize is now:

E*(P+1) / (V+1)

This is smaller than (EP / V) whenever V < P.

I've noticed that Poker tournament prize structures suffer from this same problem:

http://www.fulltilt.com/poker/tournaments/payouts

One way to fix it might be to let V = P.  A distribution where everyone got some kind of prize, with a ramp up toward first place.

That is a good point.  I'll fix that.

The prize pool is currently 80% of the entry fees.  The house keeps the other 20%

Prizes are distributed according to a geometric sequence that starts as close as possible to the entry fee and has a ratio of 1.5.  So, you get 1.5x as much money as the person one place below you.  The smallest prize is the entry fee or a little higher (tweaked higher so that the entire prize pool is split into prizes with none left over).

Fixed!

minorGems contains a whole bunch of code from over the years.  Not all of it is used in CM or the "game.h" game platform wrapper.  In fact, there is a bunch of OpenGL stuff in minorGems/graphics that isn't used by this game.

Essentially, as far as OpenGL code goes, the game uses only stuff in minorGems/game, minorGems/graphics/openGL/ScreenGL_SDL.cpp and minorGems/graphics/openGL/SingleTextureGL.cpp

The other OpenGL code is not used.

I'm pretty sure that the code used by the game IS GL-ES compliant with the ES macro defined.  I'm not sure which version of ES, except that it was the one on Raspbian.

That said, though the game RAN on Raspian (very slowly), I recall that there were some weird blending issues with the brush strokes as they were painting in.  Pretty much like that screen shot there.  Maybe the blending mode being used isn't ES compatible.

So... runToBuild generates the Linux makefile into:

gameSource/Makefile

That file pulls its .cpp and .tga file list from the platform-independent makeFileList

I wouldn't count on SDL 1.2 supporting Android---it's pretty old.

The game itself is SDL-independent except for the SDL implementation of the minorGems/game/game.h platform interface.

What you might want to do is look at game.h and simply rewrite those for Android however you want, using whatever library you want.  You'd need to implement everything from here down:

int loadSoundSprite( const char *inAIFFFileName );

The stuff above that is implemented BY the game, not the platform.

Then, take a look at minorGems/game/gameGraphics.h  Those are currently implemented by minorGems/game/platforms/openGL.  I'm pretty sure that code will just work on Android, because I recently wrote GL-ES versions of all the functions with a macro that detects ES.  I was getting the game working on Raspbian.

Anyway, beyond the game.h platform implementation, the game code doesn't rely on SDL or OpenGL.  There are only a very few minorGems things that it depends on (like SettingsManager, SimpleVector, stringUtils, and logging), but they're all platform-independent and library independent.  Thus, it should be pretty straight forward to gather the required .cpp and .h files into your project.  Essentially, just keep building, looking for missing dependencies, adding those, repeat.

Would be great if you wanted to tackle this!

I don't have any Android devices here, nor am I aware of policies that would or would not allow a game like this in the official store.

There's been some talk of an HTML5 version of the game that would then run on every device everywhere through a browser.  Of course, that would require a complete rewrite in Javascript.  Still, the client is pretty simple compared to the server.

Oops, yeah, forgot that those 190 pairings would happen in parallel!

Idea was, for example, a $5 entry fee that is put in the prize pool (taken from your main balance), and then you play $0.50 games from your main balance.  You're blocked from entering the tournament unless you have at least $5.50 (entry fee plus first game stake).

Most profit on $0.50 games over two hours wins.  Prize pool split over various placings.

I'm not sure what the stakes should be.  Lower per-game stakes (like 1-cent) means less risk for players who are falling behind to keep trying.  But also less inherent profit in continued play.  "I have no chance of winning, why would I risk another 50 cents?"  Or "I have no chance of winning, why would I waste my time playing penny games?"

Wow, that's very generous, and I definitely appreciate it!

However, I want you to be making an informed decision.

We made $140K from The Castle Doctrine (and other games) in 2014.  We made a bit more from TCD in 2013 as well, with the grand total somewhere up near $180K.

The TOTAL tribute received from all Cordial Minuet games so far is $683.4939.  Of course, I also paid out $420 in prize money for the first tournament.  Thus, the total income is only $263.49.

I've been actively working on Cordial Minuet since June 19, 2014.

Cordial Minuet is my 18th game.  I made 12 games that made nothing or close to nothing.  My 13th game brought in a few thousand dollars.  My 14th game brought in about $100K.  At that point, I had been making games for about 5 years, and trying to make a living from independent software for about 7 years.

As I understand it, you are working on your first game.  You may, in fact, need the money more than I do.

On the other hand, I'm 37, gazing at the prospect of game 19 with weary eyes, have three kids, and still cannot afford to buy a house in Davis.  Of course, none of those things are your problem!