??????

You are not logged in.

- Topics: Active | Unanswered

- Index
- » Search
- »
**Posts by zed**

Pages: **1**

I tried out this base 6 graphical representation:

http://mbays.freeshell.org/cm/numbers.png

http://mbays.freeshell.org/cm/numbers.tga

(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

fluidly.

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.

jasonrohrer:

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

http://play.google.com/about/developer- … 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?

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.

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

+z for experimenting with higher antes.

considerate, conservative play. With enough players involved, the highest

scores are likely to be obtained by those who bet rashly but happen to get

lucky.

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

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.

Thanks.

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!

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

Thanks for the Christmas bonus, Mr. Rohrer sir!

zed:

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

> permitting.

It didn't.

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

permitting.

see people trying to bore their opponents into leaving by refusing to bet

anything and leaving it until the last moment to move.

jasonrohrer:

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

Asminthe:

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

..:

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

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

http://www.umass.edu/preferen/Game 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).

jere:

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

jasonrohrer:

> 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

strategies.

consider it Not Your Problem.

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

choice.

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?

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

Pages: **1**

- Index
- » Search
- »
**Posts by zed**