[ Help | Earliest Comments | Latest Comments ][ List All Subjects of Discussion | Create New Subject of Discussion ][ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]Comments/Ratings for a Single Item ⇧Earliest ⇧Earlier ⇧Reverse Order⇩ Later Chieftain Chess. Missing description (16x12, Cells: 192) [All Comments] [Add Comment or Rating]George Duke wrote on 2008-06-27 UTCGood ★★★★Joe Joyce writes: '' I would like to discuss design, even though I would expect you'd start by telling me my games are not worth the ether they're printed on. As my entire family rarely to never plays any of my games, having someone tell me they suck is not liable to rattle me too badly. Enjoy.'' --Rococo game Duke-Joyce ongoing. Appreciate Joyce's acknowledging that there is distinct possibility that some, or many, prolificists' CVs (having 15 or more separate) write-ups may be one and all Poor and not worth bothering with. However, not Joyce's: we recently courteously rated Joyce's Lemurian Shatranj 'Excellent'. And Chieftain Chess is highlighted by Joyce's creative comment's analogy to ''this grey band sucks gas right out of the air and fills the storage tank in the head of the piece...then it is empty until the beginning of the next turn.'' This is great writing and analogizing and so justifies our rerating here of another perfectly adequate made-up game for all ages. We do not diverge either from creative upgrading in context of accepted CVPage value-criteria. Claudio Martins Jaguaribe wrote on 2009-05-19 UTCExcellent ★★★★★Joe, I have 3 questions: I- Can a chief divide it's movents? I mean, instead of a 3-0, have a 2-1 or a 1-1-1 movements in his unit? II- What happens to 'orphans'? (Pieces that lost theirs chiefs). Mus they await for rescue from another chief? III- A piece 3 squares away still under the chief control or not? Thanks! Joe Joyce wrote on 2009-05-20 UTCHi, Claudio. If I'm understanding you properly, you are asking if a chief could move 1 piece at a range of 3 squares, or 3 pieces, each at a range of 1 square, or 2 pieces, one at a range of 1 square, and the other at a range of 2 squares. Actually, I'm still working up to that. In the chieftain series, I'm not [yet] using that rule, but I do with chesimals. In the chesimals series, a leader activates 6 to 8 other pieces and itself, as long as they are all touching. But they must be touching, there is no activation at a distance. The top activation range so far is 3 squares, which means 2 [empty or occupied] squares between the leader and the piece to be activated for it to be in range. If a piece is outside the range of any leader, and stays that way throughout the turn, it cannot move. It must wait for a 'rescue' then. I have considered pieces with longer ranges, but generally in the context of higher-level leaders. I'm currently experimenting with leaders that activate 4-10 units, at a range of 2, and this range is 'transmitted' by each unit, so you could have a line of units, with an empty space between each one, and they may all move. Your first question is something I've debated with myself [and a little with Carlos Cetina] for a while. I don't allow it so far because I'm trying to structure the game and it looks very chaotic, besides being rather hard to explain and really hard to figure out and play, I suspect. Okay, I haven't done it yet because I'm chicken. I've been trying to explore this territory slowly and systematically, and keep all the games that come out of it very playable [in a relative sense, of course. When only 10 people in the world play your games, it's tough to claim you're designing for the masses. Much as I would like to. ;-) ] The fear I have is that the game goes chaotic, gets completely out of control. So before I post it, I need to have the game playtested. But apparently it's time to offer Wild Chieftains. The activation rule is changed to read: 'A chief may activate any 1 piece at a range of 3; or 1 piece at a range of 2 and another at a range of 1; or 3 pieces it is adjacent to, in each turn. Thus a chief may activate 1, 2, or 3 pieces in a turn.' This does leave some loose ends. A chief's activation of itself likely should be counted as an adjacent activation, although another interpretation would not count it at all, being at zero range, allowing a range 3, or a range 2 + range 1, or 1+1+1 also. How about the compromise position, of counting self-activation as an adjacent activation, except that a self-activating chief may also activate 1 piece at range 3 or range 2, or 2 adjacent pieces. And if this isn't complicated enough, just when do the chiefs activate the pieces to be moved? The original game allows activation to occur either before or after the specific chief has moved, but now the chief can conceivably be activated by another chief, then activate an adjacent piece, move itself 1 square to come adjacent to a second piece, activating it; then the chief completes its move, moving a second square to end up adjacent to a third piece, which it then activates. The other options are that the chief can activate pieces only at the beginning or at the end of its move, or that the chief can activate pieces at both the beginning and end of its move. I personally prefer the last option, but others may differ. To change topics a bit here at the end, I'll ask this innocent question: would this make the game any harder to program? ;-) As always, questions, comments, and criticisms are welcomed. Claudio Martins Jaguaribe wrote on 2009-05-21 UTCJoe: Thanks a lot! I've been thinking about unit movement. I believe that there is a variant with this concept. You could move the whole block (chief and the adjacent pieces) until achieve a 'combat range', where formation is breaked and pieces start to move on their own, under the chief desire. Thanks! Larry Smith wrote on 2009-05-22 UTCHere's an idea. How's bout applying Shogi drops? Such would count as a move during the turn, and the introduced pieces would be placed in any vacant cell adjacent the activating Chief. Fergus Duniho wrote on 2011-01-19 UTCHere's a preset I've begun working on: /play/pbm/play.php?game%3DChieftain+Chess%26settings%3DAuto So far it doesn't enforce the rules or prompt for extra moves, but I'll get that done eventually. For now, it recolors the board to show which spaces each side may move pieces from, using green hues for the playing side, red hues for the other side, and yellow hues for territory shared by both sides. Joe Joyce wrote on 2011-01-19 UTCWhy, thank you, Fergus. I sincerely appreciate this. Just took a fast look and what you've done so far should help de-mystify the game. I've always thought in concept and design it is quite simple. Just gets complex in play. Might I ask your opinion on how easy or hard computers would find it to be? Fergus Duniho wrote on 2011-01-19 UTCIt should be easy for a computer to play. The rule about pieces being near the Chieftains limits the number of possible moves, which makes things easier for the computer. The only thing that might make it harder for a computer is the size. But not having to deal with checkmate and stalemate also makes it easier for a computer. H. G. Muller wrote on 2011-01-20 UTCI am a lot more skeptical about this. The activation range of the Chieftains is pretty large (a well-placed Chieftain covers a 7x7 area), so pretty much all your pieces can be activated all the time, as long as you have 4 Chieftains. In fact you can have duplicate coverage of most of the board, meaning you could move even both of two pieces standing next to each other. So the activaton rule will not limit your options very much. And multiple moves per turn really blows up the branching ratio. (Compare Arimaa, where you are allowed to only do 4 Wazir moves per turn.) Because of the short range of the pieces, and the necessity to be active in several places at once (for healthy Chieftain distribution), the game really degenerates into a number of local battles. A human would immediately decouple those in his mind. But a conventional search engine would try to play all possible combinations of playing out the battles. Fergus Duniho wrote on 2011-01-21 UTCI was just reviewing the rules to make sure that my Game Courier preset covered everything, and I noticed this: Each chief may activate 1 piece per turn. It may activate itself or another chief. This makes things much more complicated than I first imagined. I was working with the assumption that any piece close enough to one of its Chieftains could move, and moves were limited by the number of Chieftains. But if I read this correctly, the preset would have to keep track not only of which pieces have moved but which Chieftains activated their movement. This will make the notation more complex. Alternately, it will make it much more complicated to calculate the legality of moves, and I haven't begun to figure out what kind of complicated algorithm that will take. Fergus Duniho wrote on 2011-01-22 UTCThis rule would also mean that a Chieftain which moves to activate another piece cannot make its move unless it has been activated by another Chieftain. Ben Reiniger wrote on 2011-01-22 UTCIt seems like the best way to have this work (from the user-end, I'm not sure how much new programming would be needed) would be for moves to be entered as chief-piecestart-pieceend. Then the only extra checks for legality needed would be 1) that the piecestart is within range of the given chief and 2) that the moves for a turn all start with unique chieftains. Is this right? Fergus Duniho wrote on 2011-01-22 UTCThat solution would require programming Game Courier to understand a new kind of notation. Also, it won't work well with Game Courier's ability to let players enter moves with the mouse. I prefer a behind-the-scenes solution that just lets players move pieces with the mouse. It might work like this. When a piece moves, note every Chieftain that could have activated its move. Compare each move with prior moves in the same turn, making sure that there are no conflicts. When there is a conflict, complain that the move is illegal. Greg Strong wrote on 2011-01-22 UTCThis rule would definitely make it more difficult to implement a computer opponent with a high skill level (although I agree with H.G. that it's already extremely difficult.) One of the things you need in a chess program is a way to efficiently store a board position â€“ a snapshot encoded in a number or number. In Chess, for example, this is made more difficult because just knowing the position of all the pieces and whoâ€™s turn it is to move isn't enough. You also need to know what castling rights are still available and if an en passant capture is possible. So this extra information is also encoded into the representation of the position (the hashcode.) With this rule you also need to know which chieftains have activated (although this could certainly be encoded as well, and the cost probably wouldn't be too bad, but it is one more thing to have to program in.) Actually, in Chess (and almost all other variants), there's something even nastier... You need to know, for each position you could later encounter, is it a 3-fold repetition? Or a 50-move draw? So your hashcode also needs to store information about every position back to the last capture or pawn move... This proves to be so costly, however, that it isnâ€™t even done at all (for most uses of the hashcode), and this produces definite bugs! Such bugs are known and very rare and the overall benefit far overshadows the penalty of having the bug. Here's how it works specifically -- When the engine 'thinks', it recursively plays out moves and counter-moves. A huge optimization that can be done is to realize that lots of different combinations of moves play out to the same position! So, when you encounter a position, you look it up in a big table of positions youâ€™ve recently seen to see if you recognize it and if what you learned about it then was 'good enough' so that we donâ€™t have to think about it any more now. The problem is that the hashcode (which locates information in this table) does not include information about past positions, so sometimes you jump to the wrong conclusion and the information really isnâ€™t 'good enough.' For example, last time you saw it you decided it was great. But this time you came here by a different set of moves, you've seen this position multiple times before, and this time itâ€™s not good, it's a draw by repetition. Oops... Ok, I digress. Chieftain Chess. I don't know that this consideration is significant enough to consider changing the rules but I thought I'd throw it out there. And that last paragraph is to show you that even imperfect hashcodes aren't necessarily the end of the world. It just makes it somewhat harder to program because you do have to account for it correctly in actual play (e.g., Chess programs really do need to detect 3-fold repetition correctly when they occur on the actual board; the bug with the hashcode table just makes the computer opponent less smart.) But a computer opponent for this game is really, really tough anyway because of the multiple moves... If human players can't see very far ahead in this game either, it might be ok... But zillions-of-games is, to the best of my knowledge, the only program in the world that plays such games at all at present. I've always considered trying to implement it, but it is just such a daunting challenge. I'd be sailing way off the charts; there's nothing written about how to do such a thing at all unless it's very recent. Joe Joyce wrote on 2011-01-22 UTCVisiting family this weekend, so I'm slow in answering again. Yes, each chief has only 1 order to give per turn, then it's used up until next turn. It's a very restricted game in this sense; that's why I call these variants 'structured multi-move games'. A very definite structure is imposed by the leader rules. I'd thought the game might be difficult for computeres because there are so many different moves, all of which have essentially the same 'value' in chess terms. And given the multi-move nature, the number of possibilities explodes even on turn 2, and except in very restricted circumstances, you cannot calculate a 'most likely' progression of moves even 3-4 moves deep with any significant likelyhood of success. I will say that the game rarely degenerates to 4 separate battles. The chiefs generally work in pairs or larger groupings. H. G. Muller wrote on 2011-01-22 UTCI don't think an engine for this would be hard to program. What would be hard is to make it search deep enough to acquire a reasonable skill. The way I would do it, is to use 4 recursive calls to the search routine for each turn, (or as many as you have Chieftains), doing the negamax flip only once every 4 ply. Each ply would cycle through all pieces, for each piece, cycle through all Chieftains, for each Chieftain that is within range, replace that Chieftain by an 'exhausted Chieftain' (a different piece type, that moves as a Chieftain, but has no activation power) and generate all moves with the piece, and play them out one by one. After moving the piece, you recurse. For efficiency you would keep track of the number of 'charged' Chieftains, and if your move just exhausted the last one, you flip the turn (and score, etc.), and 'recharge' the opponent's Chieftains. I would rely on hash hits to weed out the intra-turn transpositions, probing after each ply. (The turn-phase would automatically be hashed, because the charging and exhausting of Chieftains would alter the hash key.) That is realy all. But now try to reach meaningful depth... Greg Strong wrote on 2011-01-22 UTCVery well thought out, H.G. I see no flaws in that. Of course, not seeing deeply it's not going to play very well. Maybe you could use some sort of plan-oriented play ... Examine the grouping of pieces on the board, decide where you appear to have superiority and focus on moves that concentrate force in this area, heavily reducing or pruning moves that don't. On the other hand, in some circumstances it might be better to find where the opponent appears to have superiority and move in reinforcements, but I would expect this game is won by relentless offense. Very interesting game! Has anyone tried to make a Zillions implementation? Fergus Duniho wrote on 2011-01-22 UTCOkay, I have a plan for detecting conflicts between moves that rely on the activation power of the same Chieftain. I start with a set of all combinations of orders in which Chieftains may be used on the same turn. This is a 24 member set, just 4!, which is not too large. For each move, I identify the Chieftains on the board that could have activated that move. I then remove from the set any combinations that don't allow for the current move. If the set becomes empty at any point, then the move is illegal. If I go through all moves, and the set still has members, then a different Chieftain could be used to activate each piece that moved. This is all I need to know to tell that otherwise legal moves were all legal. It is not important to tell which Chieftain activated which piece, but besides checking the legality of each move, I need to identify which Chieftains can still be used to activate moves. I can do this by checking the place in each combination for the next move. Any Chieftain mentioned in that place will still be good for activating a piece, and its vicinity can be colored. This plan for telling which pieces can move ahead of time would be useful in writing a program to play the game. It might be doable in Zillions-of-Games by manipulating flags or piece attributes, but I don't think I will attempt it. Even if it can be done, I think it would overcomplexify things to the point where Zillions will not play it well. As in Shogi, as it was originally implemented in Zillions, there will be multiple moves it can make in the same turn that will lead to the same position at the end of the turn. This will make it more difficult for it to look ahead. In a dedicated engine, it would be helpful to group together all combinations of moves that lead to the same position and pick just one of them at random as representative of all of them when analyzing the position. Fergus Duniho wrote on 2011-01-23 UTCI must say that non-programmers create the most difficult games to program. Examples include Marseillais Chess, Hostage Chess, and this game. As a programmer, I normally design my own games with an eye to how I'm going to program them. At least the non-programmers give me more interesting challenges than I give myself, and when I'm done there's more cause for feeling satisfied. It now looks like I finally cracked this nut and got a working preset for the game. Please check it out, Joe, and let me know if everything is working okay. Fergus Duniho wrote on 2011-01-23 UTCI have a question concerning another rule: Once a piece has finished its move, it becomes inactive again. It cannot move in a subsequent turn without being re-activated by a chief. Does this allow for the same piece to be moved twice or more in a turn if it gets activated by multiple Chieftains? Currently, the preset doesn't allow the same piece to move twice in a turn. Should I change this? Joe Joyce wrote on 2011-01-23 UTCFergus, looks great! Can't talk. Pieces only move once per turn. Preset handled an ambiguous situation well - saw the gray-background leader icon in that situation - nice touch. Really gotta go now. Thanks. H. G. Muller wrote on 2011-01-23 UTCI am a bit concerned about the winability of this variant. The royal piece is an all-powerful piece superior to a Queen (on 8x8 at least; the large board size might devaluate it a bit), while all other pieces are quite weak (sub-Rook). Have you ever figured out what it takes to checkmate a bare Chieftain? I guess multiple Chieftains could do it, because it gives you the advantage of multi-move as well as their great intrinsic power. But if you also have only a single Chieftain, how many other pieces to you need to force a win? Nicholas Wolff wrote on 2011-01-23 UTCThe secret is in having more moves than your opponent. If you can out-move your opponent, then victory will be much easier. A little harder if you have the same amount of pieces/moves. H. G. Muller wrote on 2011-01-23 UTCWhat do you mean by 'more moves'? More moves per turn (i.e. more Chieftains) or larger choice (better mobility)? I can see that 2 Chieftains against 1 can win, but essentially only by forcing the trade of one Chieftain. Or by stalemating, which is a technique that would not apply in earlier phases of the game. But forcing the trade of a Chieftain is not helpful to get ahead in the number of Chieftains, when you are still equal. Joe Joyce wrote on 2011-01-23 UTCHi, all. Again, no time. Kudos to Fergus for the preset - it effectively does what I do in looking at [potential] moves. You've made it a little easier to play the game. HG, I also am concerned about the possibility of draws here. But 4 chiefs plus 2 men wins against 4 chiefs. I think a 1 man advantage should be enough, as long as you can trap 1 chief. You force a chief for man trade, and that's the game. 25 comments displayed⇧Earliest ⇧Earlier ⇧Reverse Order⇩ LaterPermalink to the exact comments currently displayed.