You are not logged in.

#1 Re: Main Forum » Share your graphics! » 2015-05-22 23:25:18


I tried out this base 6 graphical representation:

(the latter replaces graphics/inkNumbers.tga). The idea was to make it easy to
get a feel for the rough distribution of points. I found it kind of worked,
but it would take some practice before I could do the sums sufficiently

#2 Re: Main Forum » Out-there idea for a "better" game » 2015-05-19 00:03:30


I was sceptical at first, but after trying the new design, I do think
something like this could be interesting.

Having it so similar to poker is a bit boring, though, and it's a shame to
lose the cabalistic connotations. I also just find 9*4 an aesthetically
displeasing decomposition of 36. I wonder if there couldn't be a neater design
waiting to be discovered.

Here's one idea. 36 is 9 choose 2, so it's the number of lines on an enneacle
(which appears to be the etymologically correct term for the analogue of a
pentacle with 9 vertices). I don't know if this coincidence has been remarked
on in existing daemonological texts... but there's nothing wrong with
inventing new daemonology!

So in place of the numbers 1 to 36, each square could be a single line between
two of nine points equally spaced around a circle.

Then once you've picked three, you draw the three lines on a single enneacle,
and see what pattern results. Rarer and more aesthetically pleasing results
are worth more. So maybe a triangle would be worth most, followed by having 3
connected lines forming a path which isn't a triangle, followed by a path of
length two. Having two or three lines of the same length could also be worth
something, and ties could be broken by looking at the lengths of the lines
involved. With appropriate graphical indications of why a pattern is worth
something, I think a system like this could be learnable.

#3 Re: Main Forum » Any thought given to an Android port? » 2015-01-07 22:52:14


> 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.

Actually, I happened to notice this the other week: … olicy.html
> Gambling: We don't allow content or services that facilitate online
> gambling, including but not limited to, online casinos, sports betting and
> lotteries, or games of skill that offer prizes of cash or other value.

That last clause sounds like a problem, right?

#4 Re: Main Forum » How to Fix Cordial Minuet » 2015-01-07 01:46:46


One thing maybe worth mentioning: the problem I have with deep stacks is risk
aversion. I'm quite sure that if I ever ended up in $10 game, and my opponent
went all-in, I would fold even if I were sure the odds were in my favour. It's
just too much to gamble.

#5 Re: Main Forum » Eliminating all random elements » 2015-01-07 01:37:28


So is rock-paper-scissors considered a "subject to chance" for the purposes of that law?

#6 Re: Main Forum » How to Fix Cordial Minuet » 2015-01-06 02:29:53


+z for experimenting with higher antes.

#7 Re: Main Forum » New idea for a tournament structure---feedback, please » 2015-01-06 02:28:29


One possible problem with time-limited tournaments: it heavily penalises
considerate, conservative play. With enough players involved, the highest
scores are likely to be obtained by those who bet rashly but happen to get

#8 Re: Main Forum » wee UI bug with halfFrameRate » 2014-12-30 01:41:28


Anyway, thanks for fixing the bug with low framerates. It works nicely at 7.5 fps now.

#9 Re: Main Forum » wee UI bug with halfFrameRate » 2014-12-29 22:24:32


Right... maybe not so simple with opengl. I'm used to bare SDL. And depending on what's causing the slowdown when drawing the pips directly, I guess it might not help anyway. Never mind!

#10 Re: Main Forum » wee UI bug with halfFrameRate » 2014-12-29 20:26:48


OK. If there's no abstract representation of the UI state you can check for
equality between frames, I guess it's too late to insert one now. Supporting
low frame rates is good enough.

There's an obvious optimisation you could make for the assist graphs, though,
to deal with drawing so many sprites each time - blit the graphs from a buffer
which is redrawn only when they change.

#11 Re: Main Forum » wee UI bug with halfFrameRate » 2014-12-29 18:47:49



I do have hardware acceleration on this machine - although it's just crappy
intel integrated graphics with Mesa drivers, so I don't know how much ends up
being software emulated.

I suppose it seems a bit strange to me to have a constant frame rate with the
whole screen being redrawn each frame, when there isn't actually much
animation in the game. I guess you'd make huge savings just by not redrawing
when nothing's changed. But perhaps this would require painful architectural
reworking, so I'm not necessarily really suggesting it!

#12 Main Forum » wee UI bug with halfFrameRate » 2014-12-29 07:38:01

Replies: 14

I don't know if this is worth fixing, but I thought I'd report it anyway.

Annoyed with CM taking a non-trivial amount of CPU power, I put '3' in
settings/halfFrameRate.ini. The result was a perfectly playable 7.5fps, as
expected, but with an unfortunate side-effect: the pickers oscillate when
they're moved, and normally quickly settle down, but with this frame rate they
don't fully stop oscillating and end up in perpetual simple harmonic motion.
Worse, mousing over squares doesn't have the usual effect - I assume this is
because the pick isn't assumed properly picked until the picker is stationary.

With '2' in the file, it works fine.

#13 Re: Main Forum » [UPDATED] Boxing Day TOURNAMENT » 2014-12-26 20:38:56


Thanks for the Christmas bonus, Mr. Rohrer sir!

#14 Re: Main Forum » [UPDATED] Boxing Day TOURNAMENT » 2014-12-26 18:16:56


> It could give me the necessary shove to try to hack something up, time
> permitting.

It didn't.

#15 Re: Main Forum » [UPDATED] Boxing Day TOURNAMENT » 2014-12-25 00:42:45


Would it be Acceptable to play the tournament as a centaur, i.e. using
external tools to get a machine to do some game-theoretic calculations?

It could give me the necessary shove to try to hack something up, time

#16 Re: Main Forum » Table pot idea » 2014-12-17 02:06:10


If you got a reward of more than 1-3 coins for being the last in, I'd expect to
see people trying to bore their opponents into leaving by refusing to bet
anything and leaving it until the last moment to move.

#17 Re: Main Forum » More Thoughts on Cordial Minuet/The Problem With Tributes » 2014-12-01 00:41:15


> As for simultaneous decision games that are intractable to solve, I think
> space of possible strategies is exponential in the number of rows/columns.
> So... wouldn't 8x8 or 10x10 do the trick there?

I expect so! But I doubt it would be much fun as a game - even an 8x8 matrix
is just too much information to process. I expect.

#18 Re: Main Forum » More Thoughts on Cordial Minuet/The Problem With Tributes » 2014-12-01 00:34:13


> I'm curious why you think that betting actions are cheap and unsatisfying.

Obviously this is subjective, and rather to the side of the discussion here.
I should probably say "differently satisfying" rather than "unsatisfying";
betting games are interesting too, but they have a very different feel from
"pure" simultaneous move games. As for what it is I mean by "pure"... nothing
well-defined, I imagine, but I guess it's essentially a matter of this:
picking a number based on estimations of probabilities feels too directly like
calculation. Of course all simultaneous move games come down in the end to
estimating probabilities, and when played properly to calculating probability
distributions. But I find games in which the reasonable available moves on any
turn are well-differentiated, and not too large in number, to be satisfying in
a way betting games aren't. Sadly I know very few examples of such games, and
none I'm really happy with.

As for "cheap" - I just mean that if you take a game with hidden information,
and add a betting to it, it suddenly becomes massively richer.

I don't at all mean to put CM down here - it's a very neat and
canonical-feeling betting game, and the world needed it too!

#19 Re: Main Forum » More Thoughts on Cordial Minuet/The Problem With Tributes » 2014-11-30 18:39:55


> Koller, Megiddo, & von Stengel. (1996). Efficient Computation of Equilibria
> for Extensive Two-Person Games
> This translates into a linear programming problem linear in the game tree
> size.

Just the kind of trick I was hoping for, thanks. So if I understand correctly,
that reduces the dimension to a little over 30 * (12*2*5)*6 = 21600, which is
rather more manageable! Still not bruteforceable in the timeframes required by
a bot, I believe, but it might be interesting to see if that "double-oracle"
algorithm does it.

I'll be a bit disappointed if it does, to be honest. I know that betting is
the main point of the game, but I rather feel that it's a cheap and
unsatisfying way to inject complexity into a simultaneous move game. I believe
the world needs more deep (in particular computationally intractable) discrete
simultaneous move games. This seems to be harder to achieve than I'd realised!

#20 Re: Main Forum » More Thoughts on Cordial Minuet/The Problem With Tributes » 2014-11-29 14:55:11


> I've heard from someone else who came the the same conclusion as you
> regarding the infeasibility of applying minimax to the betless game as a
> single move.  There was some reference to a linear programming algorithm for
> computing such things that had a specific running time given the number of
> possible strategies, but I can't find it now.

That was probably me, by email, a couple of months ago.

The algorithm is roughly cubic in n where n is the number of strategies for
each player.

> Can you post a link that explains "recursively dominated?"  My searches
> aren't turning up much on that topic.

I don't know a standard reference, but searches gave me this: Theory Evolving/GTE Public/GTE Eliminating Dominated Strategies.pdf
which gives the basic definitions and has a nice 3x3 example where elimination
collapses it to 1x1. There's a zero-sum example in the exercises (f).

#21 Re: Main Forum » More Thoughts on Cordial Minuet/The Problem With Tributes » 2014-11-28 23:53:36


> > As far as I know, it's infeasible to actually do the computations for this game
> I believe you, but can you elaborate? I'm not getting it. Each board has
> only 518,400 outcomes, no?, which is like the search space in a couple moves
> in Go. I need to think about this one more.

But it isn't outcomes you have to work with, it's strategies.

There may well be a more cunning way to approach it, but the only way I've
seen to try to fully "solve" the whole (betless) game is to reduce it to a
single-move simultaneous move game. You can do that by having a strategy in
the one-move version be the choices the player will follow in the actual game
according to revealed information. So that's 30 possibilities for the first
move, then, for each of the 6 possible revealed rows after the first move, 12
possibilities for the second move, then for each of the 5 possible revealed
rows after the second move, another 2 possibilities for the last move. So
that's 30 * (12*2^5)^6 = 9.6*10^16 possible strategies. Utterly infeasible.

#22 Re: Main Forum » More Thoughts on Cordial Minuet/The Problem With Tributes » 2014-11-28 22:47:21


> But it is NOT optimal in terms of how much you could win against various
> different strategies.  If your opponent is not playing the Nash eq, you'd
> better switch strategies, because by playing the Nash eq, you've stuck
> yourself with no net winnings and rewarded your opponent with more winnings
> than they deserve.  Let's say their strategy is as simple as "always pick
> column 1 for me and 2 for you."  If you're sticking with your Nash eq
> strategy, you will win 50% of the rounds.  Your opponent's strategy is just
> as good as your Nash eq strategy in terms of the outcome.

That's only correct if the oppenent is not playing a recursively dominated
strategy (being one which is dominated once you ignore recursively dominated
strategies). The equilibrium strategy wins against such strategies more than
half the time. As far as I know, it's infeasible to actually do the
computations for this game, so I don't know how common domination is. But I
would be surprised if humans didn't regularly play recursively dominated

#23 Re: Main Forum » UI suggestions » 2014-11-27 22:44:01


Re the X and GL thing: yes, I get it for glxgears as well. So I guess you can
consider it Not Your Problem.

#24 Re: Main Forum » UI suggestions » 2014-11-27 22:42:47


I just tried this out. I like the column picking; being able to immediately
tap out my choices once I've made them is quite satisfying.

I see what you mean about typing bets being problematic, and adding 1 or 10 at
a time seems to work nicely.

I'm not sure about 'x' for folding, just because it isn't easily discoverable.
I tested before reading your post carefully, so was trying 'f' and 'F' and Esc
and BkSp and such for folding; 'x' didn't occur to me at all.

Bonus points, of course, for making the keys configurable! Personally I'd
prefer dvorak vi keys for bet increments, but that's unlikely to be a popular

One last thing: it felt natural to me to use left and right to choose a column
to reveal, in the final stages. Maybe left and right could always move the
currently active slider between viable columns?

#25 Main Forum » UI suggestions » 2014-11-26 00:18:47

Replies: 5

Mouse control is great for introducing people to the game, but I'm starting to
find it unpleasantly fiddly. It would be very nice to have keyboard control
for the convenience of people familiar with the mechanics.

For the main game, I'd go for something like:
* columns are enumerated as 1-6;
    these keys place a marker, alternating between green and red;
    RETURN commits.
* bets are placed by typing the number of coins;
    maybe SPACE wipes it back to 0 so you can retype;
    RETURN commits.

I would suggest a text-only interface, but I suppose the sidebar information
would be tricky to usefully communicate. I can see it working in a curses
interface, but portability is (ridiculously enough) tricky with curses.

I have another problem with the UI, but it may only affect me. I mostly live
on the linux console, so I would like to be able to switch to X, start a new
game, and switch back to the console while I wait for the bong. But switching
to the console causes the client to freeze, such that if a game starts I'm
considered inactive and just lose a coin. I tried fiddling with the code about
minimisation in minorGems, but it didn't make a difference. Maybe this is just
standard unalterable SDL+GL behaviour? It doesn't happen with pure SDL-1.2.

Board footer

Powered by FluxBB