Check out Chess with Different Armies, our featured variant for July, 2024.

[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments by Fergus Duniho

Later Reverse Order EarlierEarliest
Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]
🕸💡📝Fergus Duniho wrote on Tue, Jul 16 12:43 PM UTC in reply to H. G. Muller from 05:53 AM:

Haru's Diagram doesn't implement this game by change of piece type.

I know that already. The alternative you were proposing is what does that.

At least the concept of type change on arrival on each square would cause a more intellegible presentation of the moves (which would become the usual leaps and rides, rather than detour trajectories that stray over the board edge).

That is true. It is much less obfuscated than using a long string of characters for each piece.

The disadvantage in this case would be that it involves so many different types.

I think you are mainly turned off on this conceptual interpretation of the rules by that I happened to call these 'types'. But it is really not different from what you describe, that the same piece acquires a different set of moves when it lands on a square.

Both would work, but the code for each would be very different. For what you are suggesting, you would have to multiply the piece definitions and implement a complex mechanism for changing from one piece type to another. Whereas my Game Courier code has a single definition for each piece, and it simply checks whether movement in a particular direction is allowed from a space before evaluating the rest of the function for how a piece moves.

but the problem with Smess is that you still would need a quite long list to describe how, say, a Numskull could move on all the different squares.

This underscores my original point. You were criticizing the way it has been programmed here as "heavy abuse of XBetza notation." In response to this, I pointed out that both this solution and the one you were proposing in its place were both kludges. While your proposal would be easier to read and use shorter XBetza codes, its kludgy approach to the game would still expand the required code, and it would not really be much of an improvement over what we already have. It's not that there is a problem with Smess. It is that the XBetza code approach to coding games focuses on describing the powers of pieces while neglecting other details that could be significant in a game, such as space attributes. While this one-sided approach works for many popular Chess variants, it will not work for a game like Smess without employing a kludge that somehow shifts information about the board into the piece definitions. Given this, I can accept a kludgy solution, but I'm not inclined to think that one kludgy solution is inherently superior to the other.

🕸💡📝Fergus Duniho wrote on Tue, Jul 16 02:36 AM UTC in reply to H. G. Muller from Mon Jul 15 06:42 PM:

I don't think that 'conceptually' really means much.

It refers to how human beings normally conceive of the rules of a game, particularly for the purpose of playing it themselves with physical equipment. What you have proposed could go on behind the scenes in a computer program, but it would not reflect how people would actually play the game with a physical set. Instead of thinking that a piece changed its type with each move to a square with a different arrangement of arrows, human players with a physical set would normally think of each piece as a singular thing capable of moving in the directions indicated by the arrows on its square.

As far as I am concerned game rules are an abstract mathematical concept: a set of game states acting as nodes of a directed graph that indicate the legal transistions between one game state and another.

I can understand a programmer thinking of game rules in those terms, but most people are not programmers and will not understand game rules in that way. Furthermore, keeping the code close to the conceptual understanding of the rules can make it easier for other programmers to understand. Consider the code in the interactive diagram for this game. It works as a way of allowing a computer program to play the game, but it's about as obfuscated as code can get, and looking at this code is not going to give anyone much idea about how to play. But my own code for Game Courier would give someone who examined it a much better idea of how the game is played.

Any verbal description that unambiguously defines this graph is as good as any other, and concepts like turn, piece, move, cell, type are not more than personal preferences of the person or machine learning the game, to help him remember and apply the rules.

Machines do not have to work with concepts, and they do not have personal preferences. If it works, a machine can be programmed to play a game in a manner very different from how humans would normally conceive of the rules. This might be due to the limitations of a programming language or for the sake of efficiency. But when the language allows it, and it can be done at no cost to efficiency, it is best to reflect a normal human understanding of the game in the code. Such an understanding will normally be common to many people thanks to being grounded in the common experience of playing with physical pieces on physical boards. This makes it normal for people to distinguish between the pieces and the terrain, whereas a computer program, not thinking about the game conceptually at all, could easily merge the pieces and terrain together in a way that humans would not normally do.

🕸💡📝Fergus Duniho wrote on Mon, Jul 15 05:01 PM UTC in reply to H. G. Muller from 05:30 AM:

The Xiangqi Pawn can both be considered a single type, with a move dependent on which side of the River it stands, or a piece that promotes to a new type when crossing the River. These are fully equivalent descriptions, because the network of (type, square) transitions trivially satisfiies the condition that no closed loop alters the type, as the move confines closed loops to a rank. I would't say any of those descriptions is not in strict alignment with the rules.

They are functionally equivalent, but they are not conceptually equivalent. Technically, the Pawn in Xiangqi never promotes, because when it crosses the river, its name remains the same, and it is not replaced with another piece or flipped over like in Shogi. But in this case, one could conceive of it as promoting and play the game the same way as other people, because an irreversible one-time promotion adds no further complexity to the game. But with Storm the Ivory Tower, understanding the game as involving promotions would shift too much of the complexity of the game onto the pieces, and while it might provide a way to program the game solely in terms of piece definitions, these piece definitions would not be as easy for players to understand, and they might have to be rewritten for different terrains.

The movement options available to a piece in this game are normally understood as a function that makes use of data about the space it is on. In Game Courier, I have represented this data as an 8-bit number for each space. Each bit represents one of the directions away from the space, and to check whether a piece can move in a particular direction, it does a bitand of the value for that direction with the space's 8-bit number. Doing it this way allows me to completely separate board data and piece definitions, which makes the piece definitions easier to understand and doesn't require them to be rewritten if the terrain changes. Just to illustrate the principle, here is how the Numskull (identified here as R for Rook) is defined:

def R checkride #0 #1 1 1 or checkride #0 #1 0 1 and fn legaldir #0 #1;

If xBetza defined these pieces in an equivalent manner, all it would need is a new modifier, such as a for any available direction indicated by an arrow. This would be similar to modifiers like v, s, f, and b, except the actual directions would depend upon board data instead of being fixed. So, to give the simplest example, the Numskull could be defined as aQ, and in Smess at least, the Ninny and Brain could be defined as aK. This would be in accordance with how the rules are conceptually understood by humans and actually be a useful mnemonic for quickly identifying how a piece can move.

🕸💡📝Fergus Duniho wrote on Sun, Jul 14 10:26 PM UTC in reply to H. G. Muller from 09:34 PM:

I have never used morphing, though I assume it involves changing the type of a piece. What you are suggesting strikes me as no less of a kludge than what has already been done, as each solution handles movement in a way that is not strictly in alignment with the rules. If this were done strictly by the rules, the Numskull would have the same definition in this game as in Smess, and the identity of a piece would remain the same everywhere on the board. If there were a way to define space properties, it could be done strictly by the rules. One way to simulate board properties might be to have an invisible layer with stationary pieces that affect the directions the mobile pieces on the visible board can move. Another alternative would be to surround each space with eight other spaces for each possible direction, put an invisible stationary piece in any direction movement is not allowed, and require each move to go over its closest neighbor in whichever direction it moves. While piece movement would not be in strict conformity with the rules, this would at least separate the piece definition from the particulars of the terrain and avoid the expediency of changing the type of a piece.

🕸💡📝Fergus Duniho wrote on Sun, Jul 14 07:47 PM UTC in reply to H. G. Muller from 10:01 AM:

Is it possible to define properties for spaces, then to define movement in terms of the properties of the space it moves from?

🕸💡📝Fergus Duniho wrote on Sun, Jul 14 02:04 AM UTC in reply to HaruN Y from Sat Jul 13 11:58 PM:

It mostly looks good, but there are a few issues. The pieces are not centered properly, the board is tiled a bit, and you're using the Dumbo image instead of the Fuddy-Duddy image. Also, I'm wondering if there is a way to not have the whole space highlighted when I click on a piece.

Deicide Chess. Members-Only Missing description (16x16, Cells: 256) [All Comments] [Add Comment or Rating]

Since this comment is for a page that has not been published yet, you must be signed in to read it.

Frog/Hannibal/Waffle chess with Gryphon/Manticore and falcon. Members-Only Expansions of Kevin Pacey's Frog/Hannibal/Wafle Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]

Since this comment is for a page that has not been published yet, you must be signed in to read it.

Secret Intelligence Chess. (Updated!) A game of secrecy, disinformation, and detection. (8x8, Cells: 64) [All Comments] [Add Comment or Rating]
🕸💡📝Fergus Duniho wrote on Wed, Jul 10 06:44 PM UTC in reply to Fergus Duniho from 04:14 AM:

I combined my thoughts from last night with what was the alternate description for the Spy I had yet to try out and wrote up a new alternate description of the piece. While writing it, I covered one detail with more precision that should also apply to the current version. A spy cannot capture a piece that could capture it, which for the Pawn means it must avoid moving as one of its own Pawns when capturing one. This was coded incorrectly in this case, and I fixed it in the code of the current games. Fortunately, this bug had not led to any illegal moves.

🕸💡📝Fergus Duniho wrote on Wed, Jul 10 04:14 AM UTC:

I am having concrns that the spy is too powerful. It is a very mobile piece that can very easily avoid capture. So I'm thinking of allowing it to capture on an attacked space, limiting its inability to move to an attacked space to empty spaces. This would give its intelligence a degree of fallibility. With this change, I would increase the attacking ability of the Decoy by not limiting the pieces its knight move can capture, which would let it check the eneemy king. I may try this in a new settings file, since I don't want to change the rules for ongoing games.

🕸💡📝Fergus Duniho wrote on Tue, Jul 9 08:53 PM UTC:

I added some Alfaerie pieces to this page and to the preset. Since I don't have a custom Alfaerie piece for the Decoy, I used an equesrex. Since I don't have one for the Spy, I used the spider. Like a spider knows what is happening on its web and how to move safely along it, the Spy gets intelligence on what is happening on the board and how to safely move on it. Also, spider starts with the same syllable as spy. But if someone designs some custom piece images for these, I might use them.

Secret intelligence chess[Subject Thread] [Add Response]
🕸Fergus Duniho wrote on Tue, Jul 9 01:47 AM UTC in reply to wdtr2 from 01:24 AM:

I just fixed that. I think a bug (which I hope I got rid of) introduced an almost duplicate move in the movelist without any encryption of the piece label. Removing that line fixed it.

About Game Courier. Web-based system for playing many different variants by email or in real-time.[All Comments] [Add Comment or Rating]
🕸💡📝Fergus Duniho wrote on Tue, Jul 9 01:04 AM UTC in reply to Daniel Zacharias from Mon Jul 8 10:43 PM:

Now when I try to move in any game other than secret intelligence chess it says You may not move one of your opponent's pieces or similar

I added some new code today for which I neglected to include $nopreview as one of the conjuncts of the condition, figuring that it wasn't necessary to do that. But apparently it was necessary, for adding it allowed making a move to work properly. The code is supposed to change $submit from "Send" to "Preview" when $moves is empty, and it looks like it was doing that when a player was confirming a move. So now it looks like this:

if ($nopreview && empty($moves) && ($submit == "Send"))
    $submit = "Preview";

This was in conjunction with using the Test rendering method to test changes to movepiece.js that would prevent moves started by clicking on an empty space when $nopreview is true, as allowing this type of move could cause moves to be accidentally made, and when $nopreview is true, they can't be undone without editing the log and the database.

There is now the issue of whether any logs were damaged by this bug and are in need of repair. [EDIT: As far as I can tell, this bug stopped moves from being recorded, and the recent logs all seem fine. But if I'm wrong, let me know.]

Minishogi Gold and Silver / 5五将棋 金銀. Members-Only Super-aggressive version of Minishogi on a 5x5 board. (5x5, Cells: 25) [All Comments] [Add Comment or Rating]

Since this comment is for a page that has not been published yet, you must be signed in to read it.

Featured Chess Variants. Chess Variants Featured in our Page Headers.[All Comments] [Add Comment or Rating]
🕸📝Fergus Duniho wrote on Sun, Jul 7 02:03 AM UTC:

I commented out the nomination for Deconstruction Chess, because its page is still pending approval.

🕸📝Fergus Duniho wrote on Sat, Jul 6 07:47 PM UTC:

Since I got rid of the ibids, I put the nominated games in alphabetical order. While doing so, I found two games that were nominated twice. I consolidated each into one with the second nomination as a second.

🕸📝Fergus Duniho wrote on Sat, Jul 6 05:32 PM UTC:

I have now reformatted the Nominations & Seconds section, and I have checked it for errors. The information about games is not complete, though.

🕸📝Fergus Duniho wrote on Sat, Jul 6 04:42 PM UTC:

So that I can better check against introducing errors, here is what was on the page before I started editing:

🕸📝Fergus Duniho wrote on Sat, Jul 6 03:14 PM UTC in reply to H. G. Muller from 07:59 AM:

Can't we present the nominations as a table, with columns that can be ticked for eeach of the facilities that exist for it?

Yes, it would be much easier to read that way. [EDIT: I have begun working on this. I will prettify it after all the data is tabulated.]

I suppose the information we list now is not completely up to date either;

Yes, after a while, I focused only on games that were seconded.

Vanguard Chess. Game Courier preset for Vanguard Chess. (16x16, Cells: 256) [All Comments] [Add Comment or Rating]
🕸Fergus Duniho wrote on Fri, Jul 5 04:38 PM UTC in reply to Daniel Zacharias from Thu Jul 4 04:49 PM:

I'm seeing this error

Syntax Error on line 287

A variable name should not begin with a digit.

Can you be more precise about where you see this error? I did not see it when I checked the preset for this game.

About Game Courier. Web-based system for playing many different variants by email or in real-time.[All Comments] [Add Comment or Rating]
🕸💡📝Fergus Duniho wrote on Thu, Jul 4 09:02 PM UTC in reply to Daniel Zacharias from 07:21 PM:

The Secret Intelligence Chess invitations do not work. If I try to look at one it says I need to be signed in to view it.

Okay, I have fixed that. I hadn't made an exception for invitations. Once you accept an invitation, anyone who is not playing should see the message you saw, but the players should not.

Vanguard Chess. Game Courier preset for Vanguard Chess. (16x16, Cells: 256) [All Comments] [Add Comment or Rating]
🕸Fergus Duniho wrote on Thu, Jul 4 07:15 PM UTC in reply to H. G. Muller from 05:38 PM:

I did find a solution: use "if + 0 #cnt:" instead of "if #cnt:". Apparently dereferencing a variable with value 'undefined' produces a text string, but using it as an arithmetic operand treats it as 0.

When you place a hashtag in front of a variable name, it will return the value only if it recognizes the name, and it will otherwise return a string literal of the variable name with a hashtag in front of it. To get around this, use "if var cnt" instead.

Featured Chess Variants. Chess Variants Featured in our Page Headers.[All Comments] [Add Comment or Rating]
🕸📝Fergus Duniho wrote on Thu, Jul 4 01:38 AM UTC:

I have made Chess with Different Armies the featured variant for July, 2024. It was previously featured 20 years ago.

I know I get caught up in my own projects and don't remember to do the featured variant until the last minute or later. It would help to have more nominations of eligible games or for people to work on adding support for games that are not fully eligible yet. Let's start thinking about what we can do for next month now.

🕸📝Fergus Duniho wrote on Thu, Jul 4 01:21 AM UTC in reply to A. M. DeWitt from Wed Jul 3 07:43 PM:

My plan is to put the supporting links in square brackets to separate them from the name, and add a legend explaining what .

Okay, you could try that.

Under the current rules for featured variants, I'm not sure if Seireigi qualifies. It satisfies rules 1, 2, and 4 easily, but I'm on the fence for if a "fairly strong computer" clause in rule 3 is satisfied. It depends on whether you consider Jocly a fairly strong computer oppoenent (Ludii plays terribly, so no need to consider it).

I just played my first game of Seireigi against Jocly, and I beat it easily. It played very poorly, which is to be expected given that this is coded in JavaScript, and Shogi-like games are already more difficult for a computer program to play thanks to drops greatly increasing the moves to consider.

🕸📝Fergus Duniho wrote on Tue, Jul 2 11:03 PM UTC in reply to Daniel Zacharias from 10:05 PM:

How does Chak not qualify?

While it has an interactive diagram and can be played at, it has no record of past games. If keeps records of past games, I haven't seen them. There is no record of past games on Game Courier, because Chak isn't on Game Courier.

25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.