New Pentominoes Variant
Arthur J. O'Dwyer
Here's a two-player game that I came up with yesterday.
It seems to be fairly intriguing, and so I think this is
the group to post to. It's a variation on "Pentominoes,"
which has been around for a *long* time, but I think
this is a new variation.
The twelve classic pentominoes are the unique ways of
arranging five unit squares contiguously:
FF NNN PP TTT V W X Y ZZ
FF IIIII L NN PP T U U V WW XXX YYYY Z
F LLLL P T UUU VVV WW X ZZ
Make a set of these twelve shapes out of cardboard, or
Legos, or something. I used corrugated cardboard and
unit squares of one inch, although since this game uses
a board, you should use whatever size the squares on your
favorite checkerboard are.
Materials.
The 12 pentominoes.
One 7x7 board (such as a truncated chessboard).
Several (5-10 of each) black and white counters.
Rules.
BASIC RULES
The pentomino pieces are put into a "pool" accessible
to both players. Players alternate turns.
On a player's turn, he takes a piece from the "pool"
and places it in any empty area on the board.
The first player to be unable to place a piece
on the board loses the game.
NEW INTRIGUING RULE: CAPTURING
If a player's move places a piece such that it
touches another piece on three or more unit sides,
the touched piece is "captured." The capturing
player then puts one of his colored markers on
top of the captured piece. Example:
.......
....... Black plays the T.
..Y.... White plays the Y, which
..Y.T.. captures T. He places
..YYT.. a white marker on the T.
..YTTT.
.......
If one player has captured a piece,
the other player may capture it back.
In that case, the first player's marker
is removed. Example:
.......
....... Black plays the U, which
..YUUU. captures both the Y and
..YUTU. the T. White's marker
..YYT.. is removed from the T and
..YTTT. Black puts his markers on
....... both pieces.
At any time during the game, a
player may remove from the board
one of his captured pieces. The
removed piece goes immediately back
into the "pool," with the restriction
that the player who removed it may
NOT use that piece on his next move.
Example:
Black U TY/
White L T/Y
Black V TU/Y
.......
....VVV It is White's turn.
..YUUUV White removes the Y
.LYUTUV from the board and
.LYYT.. plays the Z.
.LYTTT.
.LL....
White ~YZ T/LU
.......
....VVV
.ZZUUUV
.LZUTUV
.LZZT..
.L.TTT.
.LL....
A player is allowed to remove more
than one captured piece at a time, and
may remove pieces at any time, even
though it usually only makes sense to
remove pieces immediately before one's
own turn.
That's all the rules. In my very limited
play-testing, the second player won a lot
of the time - I don't know whether that's
really true if both players know the game
well, though.
Comments, kudos welcome. ;-)
Also, if anyone has any source code
for a Pentominoes-like game they'd like
to share, I would really like to get a
computer player (or just an interface) for
this game.
Thanks,
-Arthur
Torben Ægidius Mogensen
> BASIC RULES
>
> The pentomino pieces are put into a "pool" accessible
> to both players. Players alternate turns.
> On a player's turn, he takes a piece from the "pool"
> and places it in any empty area on the board.
> The first player to be unable to place a piece
> on the board loses the game.
This is fairly well known.
> NEW INTRIGUING RULE: CAPTURING
>
> If a player's move places a piece such that it
> touches another piece on three or more unit sides,
> the touched piece is "captured." [details deleted]
> Comments, kudos welcome. ;-)
As far as I can see, it is possible to have a never-ending game, so
some mechanism to avoid this should be introduced. You could make it
illegal to repeat a position.
Another variant of the basic rules is to use a standard 8x8 checker
board and let one player play white and the other black. Play is as
the basic rules (place pentanominoes until no further move is
possible), but let the winner be the player with most squares of his
own colour uncovered at the end of the game.
Torben
Nate Smith
>> BASIC RULES
>>
>> The pentomino pieces are put into a "pool" accessible
>>to both players. Players alternate turns.
>> On a player's turn, he takes a piece from the "pool"
>>and places it in any empty area on the board.
>> The first player to be unable to place a piece
>>on the board loses the game.
>
> This is fairly well known.
>
>
>> NEW INTRIGUING RULE: CAPTURING
>
> As far as I can see, it is possible to have a never-ending game, so
> some mechanism to avoid this should be introduced. You could make it
> illegal to repeat a position.
>
> Another variant of the basic rules is to use a standard 8x8 checker
> board and let one player play white and the other black. Play is as
> the basic rules (place pentominoes until no further move is
> possible), but let the winner be the player with most squares of his
> own colour uncovered at the end of the game.
>
> Torben
this could result in a tie game...but you could have the last
guy to play get 1/2 point for last play.
the X has a unique property, 4:1.
now, let each player give the piece the other player has
to play....
...and we almost have a distant variant of Xong. :-o
- nate
Arthur J. O'Dwyer
On Mon, 11 Aug 2003, Nate Smith wrote:
>
> Torben Ćgidius Mogensen wrote:
For some reason, I did not see Torben's reply to
my original message. If there was substantially
more to it, would someone please re-post? Thanks
a lot. (Alternatively, if it shows up on Google
I'll read it there.)
> >> BASIC RULES
> >>
> >> The pentomino pieces are put into a "pool" accessible
> >>to both players. Players alternate turns.
> >> On a player's turn, he takes a piece from the "pool"
> >>and places it in any empty area on the board.
> >> The first player to be unable to place a piece
> >>on the board loses the game.
> >
> > This is fairly well known.
Yep. Martin Gardner wrote about it circa 1976, and he
got it from someone else, and so on.
> >> NEW INTRIGUING RULE: CAPTURING
>
> >
> > As far as I can see, it is possible to have a never-ending game, so
> > some mechanism to avoid this should be introduced. You could make it
> > illegal to repeat a position.
It is definitely possible to have a never-ending game if both
players are cooperating, just like it's possible to have a
never-ending game of chess. But I don't think such a game is
likely to happen in the real world, just as chess tournaments
probably don't end in stalemates all that often. A chess-like
rule could be added - say, if one player suggests a draw, and
the other player has not won in 10 moves from that point, then
the game is over.
I hate games where you "can't repeat a position." Who has room
in their brains for the past 10 or 20 board positions to avoid,
when you're in the middle of a challenging mind game anyway?
If I wanted to remember positions, I'd play "Concentration." ;-)
> > Another variant of the basic rules is to use a standard 8x8 checker
> > board and let one player play white and the other black. Play is as
> > the basic rules (place pentominoes until no further move is
> > possible), but let the winner be the player with most squares of his
> > own colour uncovered at the end of the game.
Interesting, but probably *much* easier to analyze. I know that
circa 1976 the classic Pentominoes game had been completely solved
up to the 5x5 board, and I would imagine it's up to the 7x7 or 8x8
by now.
What I tried to do with my variation was to introduce the possibility
(absent in Gardner's game and your variation) of games' lasting longer
than 6 moves for either player. I'm a "middle game" sort of player;
I like games that involve moderately dynamic boards. With regular
Pentominoes, the game ends before you can really get into it; and
[therefore] a decent "opening book" probably wins the game right off.
The idea here was to make a game that was not as susceptible to
naive analysis, and to make one that could be played over and over
with lots of dynamism (if that's a word :) and variation.
> > Torben
[re: Torben's chessboard variant]
> this could result in a tie game...but you could have the last
> guy to play get 1/2 point for last play.
>
> the X has a unique property, 4:1.
In addition, the W placed in a corner can cover 3:2, and
force 1:2 to remain uncovered.
> now, let each player give the piece the other player has
> to play....
>
> ...and we almost have a distant variant of Xong. :-o
If the other player gives the first player a piece that
can't be placed, then what happens? (-:
-Arthur
Nate Smith
> I hate games where you "can't repeat a position." Who has room
> in their brains for the past 10 or 20 board positions to avoid,
> when you're in the middle of a challenging mind game anyway?
> If I wanted to remember positions, I'd play "Concentration." ;-)
i agree.
>>>Another variant of the basic rules is to use a standard 8x8 checker
>>>board and let one player play white and the other black. Play is as
>>>the basic rules (place pentominoes until no further move is
>>>possible), but let the winner be the player with most squares of his
>>>own colour uncovered at the end of the game.
>
>
> Interesting, but probably *much* easier to analyze. I know that
> circa 1976 the classic Pentominoes game had been completely solved
> up to the 5x5 board, and I would imagine it's up to the 7x7 or 8x8
> by now.
>
> What I tried to do with my variation was to introduce the possibility
> (absent in Gardner's game and your variation) of games' lasting longer
> than 6 moves for either player. I'm a "middle game" sort of player;
> I like games that involve moderately dynamic boards. With regular
> Pentominoes, the game ends before you can really get into it; and
> [therefore] a decent "opening book" probably wins the game right off.
maybe you could make the board bigger & use the 35 hexominoes???
35*6 = 420, compared to 5*12 = 60, so instead of 49 or 64 you
would maybe need an 20*20 = 400 board. HOWEVER, then this could
possibly result in a lot of trivial middle game moves leading
up to the big crunch at the end.
or open it up to *all* polyominoes.
> [re: Torben's chessboard variant]
> In addition, the W placed in a corner can cover 3:2, and
> force 1:2 to remain uncovered.
>
>
>> now, let each player give the piece the other player has
>> to play....
>>
>> ...and we almost have a distant variant of Xong. :-o
>
>
> If the other player gives the first player a piece that
> can't be placed, then what happens? (-:
>
> -Arthur
well, you would have to give a playable piece,
of course - that was implied. this "giving" is
a quick attempt to neutralize some of the 1st
Player advantage. player 2 gives player 1 the
monominoe. player 1 plays it somewhere and gives
player 2 the dominoe...and so on. the 2 trominoes
and 5 quadrominoes would go next. but maybe there
is a smaller pentominoe appearing before all the
quaddies are gone.
1*1 + 1*2 + 2*3 + 5*4 + 12*5 = 89 squares already,
so a 9x9 might be okay.
;-)
- nate
see Xong: http://users.net1plus.com/greystone/xong/xonghome.html
Arthur J. O'Dwyer
On Mon, 11 Aug 2003, Nate Smith wrote:
>
> >>>Another variant of the basic rules is to use a standard 8x8 checker
> >>>board and let one player play white and the other black. Play is as
> >>>the basic rules (place pentominoes until no further move is
> >>>possible), but let the winner be the player with most squares of his
> >>>own colour uncovered at the end of the game.
> >
> > Interesting, but probably *much* easier to analyze. I know that
> > circa 1976 the classic Pentominoes game had been completely solved
> > up to the 5x5 board, and I would imagine it's up to the 7x7 or 8x8
> > by now.
> >
> > What I tried to do with my variation was to introduce the possibility
> > (absent in Gardner's game and your variation) of games' lasting longer
> > than 6 moves for either player. I'm a "middle game" sort of player;
> > I like games that involve moderately dynamic boards. With regular
> > Pentominoes, the game ends before you can really get into it; and
> > [therefore] a decent "opening book" probably wins the game right off.
>
> maybe you could make the board bigger & use the 35 hexominoes???
That involves cutting and storing 3.5 times as many cardboard
rectangles, for one thing.
The cool thing about pentominoes is that each of the twelve manages
to have a distinct "personality" in the context of the game.
With higher-order polyominoes, I think you lose the flavor of the
pieces; you get ones like
### ## ###
## ### ##
# ## ##
that have a very similar visual "character." I think (IMHO)
the human game-playing mind is most comfortable with a
small number of possibilities - 6 to 20. E.g., values in
a deck of cards, types of chessmen, total number of checkers,
etc. More than that, the mind can't handle comfortably.
Fewer than that, the mind handles trivially. [Just my 2 cents.]
> 35*6 = 420,
35*6 = 210.
> compared to 5*12 = 60, so instead of 49 or 64 you
> would maybe need an 20*20 = 400 board.
Anything from 8x8 to 14x14 would do.
Anything larger than 15x15 would almost certainly
lead to trivial draws (since all the pieces seem to
fit easily onto a 225-square board - I didn't check).
> HOWEVER, then this could
> possibly result in a lot of trivial middle game moves leading
> up to the big crunch at the end.
>
> or open it up to *all* polyominoes.
Xoids again. :)
I've read the rules since my last post, and Xong
looks somewhat interesting. It probably is playable
with paper and pencil (unlike my pentominoes
variation), so that's a point in its favor.
Now the rules are getting fuzzy in my brain again,
though. But I'm trying to keep this thread
pentomino-based. :-)
I'm still interested in getting analytic
feedback on the game. If I have time this
week, maybe I'll post some endgame puzzles
or something.
-Arthur
Maurizio De Leo
> for a Pentominoes-like game they'd like
> to share, I would really like to get a
> computer player (or just an interface) for
> this game.
You can try to implement the game rules in "Zillions of games". I think
there is already some implementation of Pentominoes games which shouldn't
been impossible to modify.
As soon as you have created a "Zillion rule file" the program will start to
play the game and be a valuable opponent for beta testing.
Maurizio
Arthur J. O'Dwyer
On Tue, 12 Aug 2003, Maurizio De Leo wrote:
[I wrote:]
> > Also, if anyone has any source code
> > for a Pentominoes-like game they'd like
> > to share, I would really like to get a
> > computer player (or just an interface) for
> > this game.
>
> You can try to implement the game rules in "Zillions of games".
Hmm... I hadn't heard of that program before. It looks very
interesting! Unfortunately, it's not open-source, nor even
freeware, and unlocking the ability to create new games costs
$25 plus time and hassle. The rules language also looks fairly
clumsy, although I see lots of people have managed to do things
with it. ;-)
One of the Zillions of Games FAQs
(http://www.zillions-of-games.com/supportedFAQ.html) says that
Zillions "doesn't currently support [...] pieces that occupy multiple
positions simultaneously," which sounds like they're saying that
Pentominoes-style games are intrinsically hard to program in
Zillions.
If there exists a free/open equivalent of "Zillions of Games,"
I'd really like to hear of it.
> I think
> there is already some implementation of Pentominoes games which
> shouldn't [be] impossible to modify.
Yeah - two Pentominoes games turn up on Google, both by Karl
Scherer, and using what look like two slightly different approaches.
Both of them are in the "brute force" category, though, with
separate methods to manipulate each of the twelve pieces. AFAICT
the brute force method is the state of the art in polyomino
programming.
> As soon as you have created a "Zillion rule file" the program will start
> to play the game and be a valuable opponent for beta testing.
As soon as I've figured out how to pay an online retailer $25
for the "full version," and written the rule file, the program
may start to play the game, and maybe it will become a decent
opponent.
It sounds like the AI may actually be pretty good, although
(again) from the FAQ: "Zillions doesn't play as well in games
with huge branching factors[.]" I don't know what's considered
a "huge branching factor", but I guess if it can play chess
decently, Capture Pentominoes shouldn't be much of a challenge.
-Arthur
Nate Smith
>> 35*6 = 420,
> 35*6 = 210.
YOW!!! smack me on the forehead! i be stupid.
> Anything from 8x8 to 14x14 would do.
> Anything larger than 15x15 would almost certainly
> lead to trivial draws (since all the pieces seem to
> fit easily onto a 225-square board - I didn't check).
of course, the way they get placed down on the board
in a game condition will be at odds with the way they
get layed down when you are trying to fit the all on
the board.
> I'm still interested in getting analytic
> feedback on the game. If I have time this
> week, maybe I'll post some endgame puzzles
> or something.
>
> -Arthur
another avenue would be to employ 2 sets of pentominoes.
a long time ago, in the 60's, my dad brought home a game
called Pan-Kai. there were 2 sets, in 2 colors. the
game was for the last move. you could wall off a vacant
shape matching a piece your opponent had played, but you
had not yet, and thus secure an extra move at the end.
your opponent would be attempting to do the same. because
there were 24 pieces, the board was expanded to 10x10.
- nate
Nate Smith
> -Arthur
well, i have reams of sheets of Xong games on
paper! ;-) i had 4 colored pencils for playing
red & blue for the legs, green to green out the
killed hexes, and black for edging the pieces &
also drawing them on the margins with the turn
number. i had the small xoids printed on the
sidelines for easy reference, so you just had to
write a turn number beside them at the beginning.
problem is, the Random Xong version cant be done
this way....
well, thank you for taking a look! and i'll retitle
this branch of the thread different, so we can keep
pentominoes going in the main thread.
- nate
http://users.net1plus.com/greystone/xong/xonghome.html
Niels L. Ellegaard
> Hmm... I hadn't heard of that program before. It looks very
> interesting! Unfortunately, it's not open-source, nor even
> freeware, and unlocking the ability to create new games costs $25
> plus time and hassle. The rules language also looks fairly clumsy,
> although I see lots of people have managed to do things with it. ;-)
There is a somewhat similar open-source project named gtkboard.
http://gtkboard.sourceforge.net/
--
Niels L Ellegaard http://dirac.ruc.dk/~gnalle/
Arthur J. O'Dwyer
Thanks! That looks very nice (except the only-runs-on-Linux part,
but I suppose that can hardly be helped, for such a graphics-intensive
application as board games). I will definitely check it out.
-Arthur
Bob Harris
> Thanks! That looks very nice (except the only-runs-on-Linux part,
> but I suppose that can hardly be helped, for such a graphics-intensive
> application as board games). I will definitely check it out.
I wouldn't consider board games "graphics-intensive"; certainly not in the
sense that the video game industry uses the term. Board games may be
embellished with a lot of drawings, but generally the drawing is not time
critical. And for that reason, the "only-runs-on-Linux part" *could* easily
be helped, by writing it something that's platform independent, such as
java. Or I would guess there are several open-source platform-independent
GUI packages out there that would be suitable.
Bob H
Nate Smith
pentominoes in java seems like an much easier project
than the hexagons & 120 degree stick figures i had to
make for the java version of Xong. i may take a look
at that someday....
i added the gtkboard site to my game bookmarks. seems
like a good place.
- nate
Arthur J. O'Dwyer
On Wed, 13 Aug 2003, Nate Smith wrote:
>
> Bob Harris wrote:
> > From: "Arthur J. O'Dwyer"
> >
> >>but I suppose that can hardly be helped, for such a graphics-intensive
> >>application as board games). I will definitely check it out.
> >
> > I wouldn't consider board games "graphics-intensive"; certainly not in
> > the sense that the video game industry uses the term.
No; but the graphic and UI design is most of the raison d'etre for the
game, and it's what the programmer spends most of his time on [especially
if the search tree code is already supplied :) ]. Contrast to
I/O-intensive apps or algorithm-intensive apps.
[then Nate Smith wrote:]
> pentominoes in java seems like an much easier project
> than the hexagons & 120 degree stick figures i had to
> make for the java version of Xong. i may take a look
> at that someday....
gtkboard only intuitively supports rectangular boards. You'd have
to do something like splitting the square cells into triangles and
conceptualizing the game that way. OTOH, if you *did* do that, I
bet you'd get a lot of props from the gtkboard devteam! :-)
I have downloaded the current build, and I'm currently working on
the gtkboard interface for Capture Pentominoes. At the moment,
my idea is to store the state of the board internally as an
array of characters in the format I posted in the first message:
.......
....N..
..wNN..
.wwNL..
ww.NL..
....L..
....LL.
where the lowercase letters represent the most recent move. Then
checking for captures merely entails making a list of all the
84 edges on the board, and looking at the cells on either side of
each edge.
The hardest thing about gtkboard, I think, is that as far as I
can tell its interface is limited to "capture a click somewhere on
the board", which means it'll be a pain to select and place
irregular figures like pentominoes. Maybe it needs a full
user interface, something like the following very bad ascii-art:
--------------
FILNPT | |
UVWXYZ | |
------ | the game |
-| = |- | board |
<| I=I |>|| | ----
-| = |- | | | rm |
------ | | ----
--------------
To remove a piece:
Click the piece to select it.
Click "remove".
To place a new piece:
Click the letter corresponding to the piece.
The piece will appear in the left-hand window.
Click the left and right arrows to rotate the piece.
Click one of the squares on the piece.
Click an empty square on the board.
The piece will be placed with the two squares coinciding.
That's a rather involved interface, and even *more* involved
for the programmer! I'm not sure how to get around this.
Ideas welcome.
-Arthur
Niels L. Ellegaard
> Board games may be embellished with a lot of drawings, but generally
> the drawing is not time critical. And for that reason, the
> "only-runs-on-Linux part" *could* easily be helped, by writing it
> something that's platform independent, such as java. Or I would
> guess there are several open-source platform-independent GUI
> packages out there that would be suitable.
I feel like nitpicking. They did make a gtk+ for windows
But I guess that you are right that it is difficult to compete with
java in terms of 'plug and play'.
Hmm I am getting off topic here....
Niels
Nate Smith
> gtkboard only intuitively supports rectangular boards. You'd have
> to do something like splitting the square cells into triangles and
> conceptualizing the game that way. OTOH, if you *did* do that, I
> bet you'd get a lot of props from the gtkboard devteam! :-)
i'm not sure i follow this - we're talking about pentominoes?
> I have downloaded the current build, and I'm currently working on
> the gtkboard interface for Capture Pentominoes. At the moment,
> my idea is to store the state of the board internally as an
> array of characters in the format I posted in the first message:
>
> .......
> ....N..
> ..wNN..
> .wwNL..
> ww.NL..
> ....L..
> ....LL.
>
> where the lowercase letters represent the most recent move. Then
> checking for captures merely entails making a list of all the
> 84 edges on the board, and looking at the cells on either side of
> each edge.
good! see, unfortunately i probably would have come up with
.......
....2..
..322..
.3321..
33.21..
....1..
....11.
1L
2N
3W
or even
.......
....2..
..322..
.3321..
33.21..
....1..
....11.
1 54 Sssl => move#, start coords, direction(N,E,S,W),
[r]ight, [l]eft, or [s]traight to next square
2 52 Srls
3 15 Elrl
you probably would have enough room to have the 12 guys drawn
off to the side. then you {mouse over} & click to select it.
at this point it is stuck to your mouse pointer & drags along
with it. a click rotates it to the right, a SHIFT-click to
the left (because MAC mice only have 1 button), and then
CONTROL-click flips it over if it is asymmetrical & you need
the other side of the pentomino.
in my java Xong app i have the release of dragging the piece
drop the piece, nestling it into a legal position, so you dont
have to have single-pixel precision in your fingertips.
then you may wish to have a COMMIT MOVE button somewhere to
make the move, as opposed to just dragging it around & trying
it out in several places whiler you drink another cup of coffee.
but gtk may not go for this. ;-)
- nate, getting another cup of coffee
Bob Harris
>> Board games may be embellished with a lot of drawings, but generally the
>> drawing is not time critical. And for that reason, the "only-runs-on-Linux
>> part" *could* easily be helped, by writing it something that's platform
>> independent, such as java. Or I would guess there are several open-source
>> platform-independent GUI packages out there that would be suitable.
and Niels L. Ellegaard pointed out:
> I feel like nitpicking. They did make a gtk+ for windows
>
> http://www.dropline.net/gtk/
That's good news. Personally I'd like to see it for the mac too and any
other platform people might use. At the time I wrote that I hadn't looked
at the gtk website, and was going on the previous poster's claim that it was
for linux only.
Seems like such a package could easily be made platform independent. I've
been to the website but I still can't tell if that's the case or not. it
doesn't seem to be a major stated goal of the project.
Bob H
Bob Harris
>>>> but I suppose that can hardly be helped, for such a graphics-intensive
>>>> application as board games). I will definitely check it out.
and I pointed out:
>>> I wouldn't consider board games "graphics-intensive"; certainly not in
>>> the sense that the video game industry uses the term.
to which Arthur replied:
> No; but the graphic and UI design is most of the raison d'etre for the game,
> and it's what the programmer spends most of his time on [especially if the
> search tree code is already supplied :) ]. Contrast to I/O-intensive apps or
> algorithm-intensive apps.
Yes, a programmer will spend a lot of time on that. But this fact has
nothing to do with the claim "only-runs-on-Linux part, but I suppose that
can hardly be helped". Is there something about linux that makes GUI
programming easier than on other platforms? I seriously doubt it. You've
got a mouse and a window with colored pixels in it. Same as every other
platform these days. Gtk allows you to supply images of your game's
components. Is there some image standard on linux that's not on other
platforms? I'm trying to see what there possibly could be about the graphic
nature of a board game that demands linux and excludes other platforms. If
you know what it is, please tell me.
What I originally thought your statement of graphics-intensiveness meant was
that the code to manipulate pixels on the screen must be tied, in a
platform-dependent way, to the video hardware. From what I can tell at the
gtkboard site, and from what I know from my own experience programming both
fast-action video games and slow-action puzzle/games, there's no *technical*
reason that a project like gtkboard should be tied to one architecture or
OS.
That it is tied to linux seems to be the preference of the guy running the
show, and if that's convenient for him that's certainly his prerogative. I
don't mean to be ragging on that choice. My only contention was with your
claim that it "can hardly be helped". That's simply not true. I could be
helped fairly easily, if that's one of the project's goals.
Bob H
Arthur J. O'Dwyer
On Wed, 13 Aug 2003, Bob Harris wrote:
>
> Arthur J. O'Dwyer wrote:
> >>>> Thanks! That looks very nice (except the only-runs-on-Linux part,
> >>>> but I suppose that can hardly be helped, for such a graphics-intensive
> >>>> application as board games). I will definitely check it out.
>
> and I pointed out:
> >>> I wouldn't consider board games "graphics-intensive"; certainly not in
> >>> the sense that the video game industry uses the term.
>
> to which Arthur replied:
> > No; but the graphic and UI design is most of the raison d'etre for the game,
> > and it's what the programmer spends most of his time on [especially if the
> > search tree code is already supplied :) ]. Contrast to I/O-intensive apps or
> > algorithm-intensive apps.
>
> Yes, a programmer will spend a lot of time on that. But this fact has
> nothing to do with the claim "only-runs-on-Linux part, but I suppose that
> can hardly be helped". Is there something about linux that makes GUI
> programming easier than on other platforms?
No, no! :-) But if you're going to develop a "graphics-intensive"
application (in *my* sense of the term :)), then it's probably not
going to be portable unless you *work* at portability from the get-go.
And the gtkboard people don't seem to have worked at portability.
So yeah, you *could* make a graphical game engine that was nicely
partitioned up into "engine" and "GTk" and "OpenGL" and whatever,
but I wouldn't want to do it.
In short, the emphasis was on the "only" part, not the "Linux" part.
In shorter, I don't see a DOS port. :)
-Arthur
Arthur J. O'Dwyer
On Wed, 13 Aug 2003, Nate Smith wrote:
>
>
> > gtkboard only intuitively supports rectangular boards. You'd have
> > to do something like splitting the square cells into triangles and
> > conceptualizing the game that way. OTOH, if you *did* do that, I
> > bet you'd get a lot of props from the gtkboard devteam! :-)
>
> i'm not sure i follow this - we're talking about pentominoes?
_You_ were talking about Xong. ;-)
Back to pentominoes, now...
> > I have downloaded the current build, and I'm currently working on
> > the gtkboard interface for Capture Pentominoes. At the moment,
> > my idea is to store the state of the board internally as an
> > array of characters in the format I posted in the first message:
> >
> > .......
> > ....N..
> > ..wNN..
> > .wwNL..
> > ww.NL..
> > ....L..
> > ....LL.
> >
> > where the lowercase letters represent the most recent move. Then
> > checking for captures merely entails making a list of all the
> > 84 edges on the board, and looking at the cells on either side of
> > each edge.
>
> good! [...]
Thanks.
> you probably would have enough room to have the 12 guys drawn
> off to the side. then you {mouse over} & click to select it.
> at this point it is stuck to your mouse pointer
Nope, I don't think gtkboard can do that. I think it was the Chess
game that had a comment like "drag & drop isn't working yet," but
even so I think they didn't mean that you could *see* what you were
dragging, just that you should be able to make a move in one mouse
motion instead of two.
> & drags along
> with it. a click rotates it to the right, a SHIFT-click to
> the left (because MAC mice only have 1 button), and then
> CONTROL-click flips it over if it is asymmetrical & you need
> the other side of the pentomino.
Dang! I completely forgot about flipping-over when I wrote up
that ascii-art interface. Add *another* button to flip the selected
piece over a vertical axis.
And AFAIK each "clickable" thing in gtkboard has to be a "cell" on
the "board," so even though the board is conceptually only 7x7, I'll
end up with a board that's like 15x12 by the time the interface is
done.
> in my java Xong app i have the release of dragging the piece
> drop the piece, nestling it into a legal position, so you dont
> have to have single-pixel precision in your fingertips.
>
> then you may wish to have a COMMIT MOVE button somewhere to
> make the move, as opposed to just dragging it around & trying
> it out in several places whiler you drink another cup of coffee.
>
> but gtk may not go for this. ;-)
Yeh. Nice, though. :-)
I don't yet have access to a Linux graphical testbed, but I will
in less than two weeks now. (School. :)) Then I expect to be able
to run what I have so far, and see how it really looks.
-Arthur
Bob Harris
>> Is there something about linux that makes GUI programming easier than on
>> other platforms?
and Arthur replied:
> No, no! :-) But if you're going to develop a "graphics-intensive"
> application (in *my* sense of the term :)), then it's probably not going to be
> portable unless you *work* at portability from the get-go. And the gtkboard
> people don't seem to have worked at portability. So yeah, you *could* make a
> graphical game engine that was nicely partitioned up into "engine" and "GTk"
> and "OpenGL" and whatever, but I wouldn't want to do it.
>
> In short, the emphasis was on the "only" part, not the "Linux" part.
Fair enough. I agree that the gtk people don't seem to have had that
motivation (I wish I were wrong about that). But even beyond the graphics
part, they seem to be using non-standard C. At least one of the routines
mentioned in the "how to write code for this project" page, snprintf (or
something like that), doesn't appear in any of the standard C references on
my bookshelf. So platform portability seems to have left out of the
equation, even in things unrelated to graphics.
If I'm right about that, it's a sad choice on their part. In *my* opinion,
of course. Hard to pick on someone who's providing a nice package for free,
just because it doesn't suit *my* needs.
Bob H
David desJardins
> Yes, a programmer will spend a lot of time on that. But this fact has
> nothing to do with the claim "only-runs-on-Linux part, but I suppose that
> can hardly be helped". Is there something about linux that makes GUI
> programming easier than on other platforms?
No, there's something about Windows that makes cross-platform
programming difficult. Microsoft doesn't have any interest in making it
easy to write software that runs just as well on Windows and non-Windows
platforms. And they have lots of ways to make it more difficult. So,
when the developers are developing on Linux, it's quite hard for them to
write something that works well on Windows too. So they usually don't.
David desJardins
Arthur J. O'Dwyer
On Wed, 13 Aug 2003, Bob Harris wrote:
>
> >> Is there something about linux that makes GUI programming easier than on
> >> other platforms?
>
> and Arthur replied:
> > In short, the emphasis was on the "only" part, not the "Linux" part.
>
> Fair enough. I agree that the gtk people don't seem to have had that
> motivation (I wish I were wrong about that). But even beyond the graphics
> part, they seem to be using non-standard C. At least one of the routines
> mentioned in the "how to write code for this project" page, snprintf (or
> something like that), doesn't appear in any of the standard C references on
> my bookshelf.
snprintf() is standard C99, and (all of my copies of) gcc support it
(even though gcc isn't C99-compliant). But it wasn't in C89, the standard
that most everybody uses. [It's safer than plain sprintf(), which is why
they recommended it.]
But yeah, gtkboard #includes something called <glib.h> and uses functions
like g_strdup(), which look to me like garbage-collection. I sure hope
I'm right about that. ;-) And the Gtk interface stuff is woven into
the getmove() functions pretty tightly.
> So platform portability seems to have left out of the
> equation, even in things unrelated to graphics.
>
> If I'm right about that, it's a sad choice on their part. In *my* opinion,
> of course. Hard to pick on someone who's providing a nice package for free,
> just because it doesn't suit *my* needs.
Yeah, I know how that is. ;-)
-Arthur
Niels L. Ellegaard
> But yeah, gtkboard #includes something called <glib.h> and uses
> functions like g_strdup(), which look to me like garbage-collection.
> I sure hope I'm right about that. ;-) And the Gtk interface stuff is
> woven into the getmove() functions pretty tightly.
glib is a helping library for gtk. You can download a windows version
here:
http://www.gimp.org/~tml/gimp/win32/downloads.html
Arvind Narayanan
> Bob Harris wrote:
>
> > From: "Arthur J. O'Dwyer" <a...@andrew.cmu.edu>
> >
> >>Thanks! That looks very nice (except the only-runs-on-Linux part,
> >>but I suppose that can hardly be helped, for such a graphics-intensive
> >>application as board games). I will definitely check it out.
> >
Unix. And the only reason for that is that I have access only to *nix machines.
Anyone who has gtk running on windows is welcome to try compiling it. If you
need any help please mail me. Thanks.
Arvind Narayanan
Arvind Narayanan
> On Wed, 13 Aug 2003, Bob Harris wrote:
> >
> snprintf() is standard C99, and (all of my copies of) gcc support it
> (even though gcc isn't C99-compliant). But it wasn't in C89, the standard
> that most everybody uses. [It's safer than plain sprintf(), which is why
> they recommended it.]
won't exceed the size of the string. If you resolve never to use string
functions without an 'n' in them, you'll solve most of your buffer overflow
bugs :)
>
> But yeah, gtkboard #includes something called <glib.h> and uses functions
> like g_strdup(), which look to me like garbage-collection. I sure hope
> I'm right about that. ;-) And the Gtk interface stuff is woven into
> the getmove() functions pretty tightly.
Currently getmove_kb() requires gdkkeysyms.h, but adding a trivial
abstraction layer will remove that dependency, which I'm planning
to do soon.
Arvind