| Author | Message | ||
| Ingrid Lael (Ingridlael)
|
Hi there, I'm having some problems whilst dealing with the UI and defining moves. Particularly: I want a piece to be able to change the type of any piece adyacent to it to a neutral (say, "block") piece. The problem is that a) the owner of the piece may choose to change any number of the adyacent pieces (even zero). b) I'd like the UI to allow me to click on the to-be-changed piece in order to perform the move. I've tried the following: ((change-type n Block) add-partial) ; add-partial does not work ((change-type n Block) to add-partial) ; idem (cascade (change-type n Block) add-paretial) ;idem The "cascade" and "to" commands got there as a desperate attempt to "guide" the UI into the correct square. Does anyone have any ideas as to how could I code this? Again: I want to be able to change the type of the adyacent pieces by clicking on them and any number of them may be clicked (suppose I terminate the change-type sequence by clicking on the piece in question). Thanks in advance for any help you can provide. Cheers... ...Ingrid | ||
| Karl Scherer (Karl)
|
sounds to me like a case for the add-copy-partial command. It is clumsy (like so many work-arounds in Zillions), since you have to 'undo' the created pieces into the ones you really want to create there, but it could work; not sure though. Give it a try. If it does not work int the same move, store the new piece types in attributes, then have the ?Random player in the next move actually converting the clicked pieces into the correct piece types, using their attributes. ... by the way, for a programming start you might try to programm some easier games; seems to want to do the most complicated cases right away; maybe not such a good idea. Cheers, Karl | ||
| Ingrid Lael (Ingridlael)
|
Hi Karl! how are you? Yep, i thought of that one too ("add-copy-partial"), but i didn't work (maybe you were thinking of some particular way of using it which didn't cross my mind...would you care to clarify?). I think that storing the piece-changes in piece-attributes has the same problem, since the player would have to select which pieces get their attributes changed....having the same problem. Yep, I admit it, it's not the easiest of games around, but I guess that if i get this one going the future ones will be a piece of cake. Besides, I've already put too much effort into it and am not willing to let go now (btw, this is the last issue remaining, then the game will be ready, besides graphics and sound and pretty printing in general, of course). Thanks for your prompt response Karl. Cheers... ...Ingrid | ||
| Karl Scherer (Karl)
|
well, if you have only one possible change per adjacent piece, then simply let ?Random change the ones that have been visited. My idea with using the add-copy-partial only was to move the piece, then hop onto every neighbor you want to have changed, and change-type the hopped-on piece to what you want. If that does not work, change its attribute and let ?Random do the work afterwards, where ?Random checks the attribute set. Example with just one neighbor: (move-type Standard) (s to ... (add-partial-copy Next)) ;main move (move-type Next) ;neighbor-click-move ((go last-to) from e to ...(set-attr...) add-copy) If you have more than one neighbor, you still can use move-type Next, but the move has to include logic to get the sequence right of course. The problem is that partial only works with identical piece-types, so all change-types have to be made by ?Random after wards. Can't see any real problems here. If you are still puzzled, please be a bit more specific what exactly you do not understand. ---------------------------------------------- A second, totally different approach which also should work is the following: In the turn-order list, provide one entry per possible neighbor (for n,s,e,w say four entries), and skip these move as automatic PASSes (option "pass turn" forced) if the player clicks a certain button outside the board (or clicks the same piece twice). To get the forced pass, the button clicking must set a certain piece Pass-remaining-neigbors on a certain extra position zz (say (create Pass-remaining-neigbors zz)) outside the ordinary board, which is then checked by the possible neighbor-click-drops: (verify (empty? zz)). I am pretty sure both are ways to solve your problem. Cheers, Karl | ||
| Karl Scherer (Karl)
|
P.S. In another line of discussion, you mentioned that you has 2 or even 4 ?Helpers as players. There is absolutely no need ever for more than one ?Helper, because things cannot get more random than random. It also slows the system down (because they will appear unnecessarily as independent owqners of pieces), and for this and other easons makes the program more complicated. Instead of several random players as in your turnorder: Player1 ?Helper1 ?Helper2 Player2 ?Helper1 ?Helper2 why not simply have two move-types: Player1 (?Helper M1) (?Helper M2) Player2 (?Helper M1) (?Helper M2) where M1 and M2 are two move-types. Do you understand the idea of move-types? Cheers, Karl | ||
| Ingrid Lael (Ingridlael)
|
Thanks for the prompt response again! :D I'm about to try your first approach (the "add-copy-partial" one) just now. You're right, as you said on an earlier reply on another thread, there are surely no real problems here, is just that i'm still a rookie at this, and I tend to drown on a half-empty glass of water. Seriously, I do. As a matter of fact I'm still a little bit puzzled (although I haven't yet implemented either of your suggestions), so I'll try to totally clarify the issue: The move per se: Suppose your normal chess king could be allowed once every, say, 10 turns, to turn any piece adyacent to him in the eight orthogonal and diagonal directions into a "stone", an uncapturable, unmovable piece. He can change any or none of the adyacent pieces, in any order he wishes. The entire "freezing" process (actually this is just the selection of the pieces to be turned into stones) encompasses a single king move. My whimp: I'd like the player moving the king in such a way to be able to just click on the piece to be turned into "stone" in order to be selected for freezing. Now he should be able of further clicking on the remaining pieces. The player can end this "selection" phase by clicking on the king itself. I hope this clarifies at least my intended purpose. As for the implementation, yes, I'd have a random player actually do the "freezing" (since, as a matter of fact, is not as simple as a mere "change-type"), the selection phase would only set an attribute. On the random players subject: great!, I actually didn't know that they slowed things down. As a matter of fact I initially did things the way you suggested, but then changed it to the "many helpers" approach for tidyness (I know, I know, stupid thing to do). I'll most certainly change it back to the move type approach at once. Thanks for that one!  (just a sidenote: I know that "things cannot get more random than random"; even more, all my random players actually have nothing of "random" in them, since they only have a single move) Thanks a LOT for your help Karl!!! (you'll definitly get included in the readme once I'm done with this!) Cheers... ...Ingrid | ||
| Karl Scherer (Karl)
|
After thinking about my two suggestions, I realised that the first idea is not a good suggestions since you have copies of the king sitting around until ?Helper comes along to clean up the situation. Since the king is not supposed to move into attacked positions, this actually forbids this suggested solution. In many simpler game without the checking condition it will work, but it is still ugly because the player temporarily creates the "wrong" pieces. So I think my second suggestion (via the turn order) is the much better solution. There is a third way which I forgot and which I personally used quite a lot, name the "extra-buttons" approach: Create special buttons at the side of the board where the player can say which neighbors should be changed: make a small graphic with a central dot and other dots (-buttons) around representing the neighbors of a piece. Cheers, Karl | ||
| Ingrid Lael (Ingridlael)
|
Hi Karl!, sorry for the lag. I've checked the first approach and, although it does create a copy of the moving piece in every position this is easily solved by making the stationary pieces move and drop (actually, add-copy-partial) upon themselves a different piece looking just the same (say "to-be-pushed-pawn"). The turn order approach looks simple enough, although there are some issues: a) how well does the ai manage that kind of things? (I was under the impression that it did poorly). I know, I shouldn't care all that much about that in this stage. b) I actually have set pass-partial to false, because i have a loss-condition involving repetition, and pass-partial would affect every move by any piece, instead of just the particular move-type involved. Anyway, thanks very much for your suggestions. Cheers... ...Ingrid. |