| Author |
Message |
Joshua Taylor (Archmageomega)
| | Posted on Saturday, December 17, 2005 - 3:38 pm: | |
Water War at Zillions I'd like to know what you think about this game. Specifically, do you think the capture mechanic works well, or if it should be done some other way? (I intended to add variants for different capture styles, but I had trouble getting it to work. Specifically, I was thinking of allowing more than one enemy in a sandwich capture, using reversi type captures and using checker like captures.) |
Joshua Taylor (Archmageomega)
| | Posted on Saturday, December 17, 2005 - 4:06 pm: | |
Oh yeah, there was something else. I've got a problem with this game that I'm having trouble fixing. The problem is with the empty pieces of the boats. There are several conditions where the empty boats need to change sides so that the player can move a boat he now owns. I'm having trouble keeping up with who owns the boat under certain circumstances (like an enemy leaving a contested boat). One solution I tried was to have a random player swap out all the empty boats each round, but this slows the AI down too much and polutes the move list. Any suggestions? |
Joshua Taylor (Archmageomega)
| | Posted on Sunday, December 18, 2005 - 2:55 am: | |
I remember now. I know a perfectly acceptable way of doing this, but for some reason, Zillions won't load the rule file after I fix this. I think the code might be too big. Can anyone help me with this? |
Mats W (Kålroten)
| | Posted on Monday, December 19, 2005 - 2:10 pm: | |
If this idea is strategically viable, then it should be eternally developable. You could simulate the sea battle of Salamis where the Persians had bigger and more powerful ships but who lost to the smaller and more maneuverable ships of the Greek. This is the most important sea battle in history. Western civilisation would have been nipped in the bud if the Greek hadn won this battle. You could have a much bigger board and implement islands where the men could go ashore and embark on a ship on the other side of the island, etc. |
Joshua Taylor (Archmageomega)
| | Posted on Monday, December 19, 2005 - 3:35 pm: | |
Islands sound like a lot of fun, and not too hard to implement. However, if the problems I'm having are related to code size, I can't add anything else any time soon. This is already the third time I've rewritten this game. (The first too made the AI run too slowly to play well.) |
Joshua Taylor (Archmageomega)
| | Posted on Thursday, October 12, 2006 - 12:15 pm: | |
Just out of curiosity, but does anyone know why this game crashes Zillions when I add a few more rules? As it stands, I can't fix this game because the code needed to update the ownership of the boat pieces exceeds some limit in Zillions. Also, if someone wants to take the idea for the game and try to rewrite it themselves (possibly with islands) I wouldn't mind. (Just give some credit for the original idea. ) |
Karl Scherer (Karl)
| | Posted on Saturday, October 14, 2006 - 10:11 pm: | |
Re: Water War rewrite Hi Joshua, thanks for the invitation. I just had a look at the zrf and I am willing to rewrite it. I am sure there are many ways to heavily simplify it. Do you have an email address so I can send it to you for testing when ready? Cheers, Karl |
Karl Scherer (Karl)
| | Posted on Sunday, October 15, 2006 - 4:14 am: | |
Hi Joshua, following your invitation, I have now thoroughly rewritten the game "Water War": - I have been able to reduce "Symbols in Stack" and "Processed file size" by about 33 percent. This eliminates all size problems for a while. - I have reduced the number of 'add' commands drastically (in guy-move macro from 48 to 8) - I have strongly simplified the code by introducing the piece attribute 'man?'. - I added islands which the men can walk on - I added sounds - I also added some nice graphics (2 alternative piece sets now) - of course I have credited you with the invention and the first implementation of the game. The game is available from my website http://karl.kiwi.gen.nz as soon as I can upload the program there. If I don't hear from you, this program will be published as version 1.1 of Water War next weekend. Cheers, Karl |
Keith Carter (Keithc)
| | Posted on Sunday, October 15, 2006 - 10:06 pm: | |
Hello Karl, I downloaded version 1.1 of Water War. The zip file is much larger than most found on the Zillions site at 2,323kb. The board graphic 16x16-2 is 24 bit color and is 488kb. If changed to 8 bit color it becomes 164kb. There is a second board graphic that does not seem to be used. 32x32.bmp is 1,838kb and if changed to 8 bit color would reduce to 614kb. Is the 32x32 board part of a planned variant? If I reduce all the non-piece graphics to 8 bit color and drop the 32x32 board the zip file goes from 2,323kb to 437kb. |
Karl Scherer (Karl)
| | Posted on Sunday, October 15, 2006 - 11:08 pm: | |
Hi Joshua and Keith, I just uploaded the newest test version (still V1.1) of "Water War" on my web site: - I have added a multiple-capture variant - I have added two variants on the 32x32 board (The associated setup is preliminary only and might still be changed by Joshua). - program even more simplified - Its size is now down from 2.2MB to 700 KB. Here is a tip which might help other authors, too: Instead of programming (if (on-board? x) x (if friend? ... )) it is shorter and will be faster processed if you write: (if (friend? x) x .. ) I am pretty sure this does the same. Any comments? ----------------------------------- Variants often need slightly different code from the default variant. One easy way to achieve this is to introduce a parameter associated with the macro that contain the board definition; the parameter being a position defining the only position of a "variant zone" vzone. In the code you program (if (in-zone? vzone a2)... ; code for variant 2 ... and so on. Cheers, Karl |
Joshua Taylor (Archmageomega)
| | Posted on Monday, October 16, 2006 - 12:03 am: | |
Hey. I downloaded and looked over the game. Thanks for taking the time to fix it up. Unfortunately, there is at least one bug in the game still. If a white man steps onto an empty black boat, it won't allow the boat to move in all the directions it should be able to. (For example, if the man lands on the top of an up-down boat, the boat can't move downward.) Also, the 32x32 board seems a little big now... I think it needs a smaller tileset to work. Plus the starting positions should be a little different. Two I can think of are boats on either side of a central island, or men on an island guarding against men in boats. (A wall piece might be an interesting twist, but may just complicate things.) Really though, without a lot of people trying stuff out, it'd be hard to just make up good starting positions. Maybe later someone can work out a good set of rules for a drop start. (Drop boats then drop men, or something.) |
Mats W (Kålroten)
| | Posted on Monday, October 16, 2006 - 12:26 am: | |
This is a very interesting concept. and beautifully implemented, but there are two bugs: (1) If a piece enters between two enemy pieces then the opponent can capture it in the next move by moving a piece somewhere else on the board (a piece which is completely unrelated). This is clearly wrong. (2) If a piece (x) enters between two enemy pieces and one of the two enemy pieces is subsequently captured, then the opponent can capture the piece (x) by moving a piece somewhere else on the board. In this case the piece (x) isn't even enclosed by two enemy pieces. See game below. By the way, would it be possible to use "change-type" instead of capturing the boat segments, thus avoiding the segments moving over the screen? Mats ----------------------------- Zillions Save Game File Version 0.02 HC RulesFile=Water War.zrf VariantName=Water War 1. BR c5 - d5 EBH b5 x c5 BL a5 x b5 1. BL l9 - j9 BH m9 - k9 BR n9 x l9 2. BR d5 - c4 BL b5 - c6 White BD c4 White EBV c5 White BU c6 2. BL j9 - h9 BH k9 - i9 BR l9 x j9 3. BR e8 - g8 BH d8 - f8 BL c8 x e8 3. BL h9 x g10 Black EBL h9 Black BD g10 4. BR g8 - i8 BH f8 - h8 BL e8 x g8 4. BH i9 x j10 Black EBH i9 Black BD j10 5. BH h8 x h9 White EBH h8 White BL h9 5. BD g10 - f11 EBU g12 - h11 Black BL f11 Black EBH g11 Black EBR h11 6. BR i8 x i9 White EBR i8 White BH i9 6. BR p5 - o4 BL n5 - o6 Black BD o4 Black EBV o5 Black BU o6 7. BL g8 x h8 White EBL g8 White BH h8 7. BR j9 x i8 Black EBR j9 Black BR i8 8. BR d10 - g10 BH c10 - f10 BL b10 - e10 8. EBR h11 - i11 EBH g11 x h11 BL f11 x g11 9. BR c12 - e12 EBH b12 - d12 BL a12 x c12 9. BL g11 x h11 Black EBL g11 Black BH h11 10. BR e12 - g12 EBH d12 - f12 BL c12 x e12 10. BH h11 x i11 Black EBH h11 Black BR i11 11. BR g10 - i10 BH f10 - h10 BL e10 x g10 11. BR i11 x j12 Black EBR i11 Black BU j12 12. BR i10 x i11 White EBR i10 White BR i11 12. BL l8 - j8 BH m8 - k8 BR n8 x l8 13. BH h10 x i10 White EBH h10 White BR i10 13. BR o7 - n8 BL m7 - n6 Black BU n8 Black BV n7 Black BD n6 14. BH i9 x j9 White EBH i9 White BR j9 14. BD n6 - n5 BV n7 x n6 BU n8 x n7 15. BR i11 x j11 White EBR i11 White EBD j10 White BV j11 15. BL m10 - k10 BH n10 - l10 BR o10 x m10 Black EBR j9 |
Karl Scherer (Karl)
| | Posted on Monday, October 16, 2006 - 3:43 pm: | |
Hi Mats and Joshua: Mats, none of your complaints I could verify. In your example, 15. BL m10 - k10 moves a black man from m10 to k10, which together with the black man on i8 (see move 7) sandwiches the white man at j9 diagonally. This and only this moves deletes the white man at j9, and this is correct. You might have forgotten that diagonal capture is allowed. "moving a piece somewhere else on the board", as you claim, does NOT have the same effect, and it shouldn't. So everything works fine here. ------------------------------------------ Joshua's remark, however, is correct, and I will fix this (ready in a few hours). I will post another message here when it is done. Joshua, I suggest you then download V2.0 and change the board setups to your liking before sending them to Zillions for publishing. Cheers, Karl |
Karl Scherer (Karl)
| | Posted on Monday, October 16, 2006 - 5:22 pm: | |
Water War V2.0 ready Hi Joshua, V2.0 now fixed, on my web site. The ownership problem you mentioned was not easy to fix. Indeed, your original game had also unsolved ownership problems which caused bugs in the game. Try for example the following in your original version: (x pB8) (x pC8) (x pD8) (x pE6) (x pD6) (x pC6) (x p96) (x p95) (x p94) (x p99) (x p9A) (x p9B) (White BR pA6) (White BR pB8) (White BLR p96) (White BLR pA8) (White BL p86) (White BL p98) 1. BR pA6 - pB6 BLR p96 x pA6 BL p86 x p96 White EBL pB7 Now after moving the top white boat, a black man is captured, but since you make the captured empty boat piece your own, the black boat cannot be moved to the left by Black. Hence I had to invent something more sophisticated without spending too much coding. The current version should work fine under all conditions. Note, however, that after turning a boat with one empty boat end this boat end has the 'wrong' ownership, but this problem is automatically amended by the system during any next move. Apart from this uncritical exception, I have changed the code so that the ownership of all empty boat pieces changes after every move. Feel free to send me any program problems which might still occur. Cheers, Karl |
Joshua Taylor (Archmageomega)
| | Posted on Tuesday, October 17, 2006 - 12:31 am: | |
Yeah, I knew about the problem in my old code, but couldn't fix it since the fix required enough code to exceed some limit in Zillions. (I vaguely remember using a dummy player to change all the empty ship pieces, but I was trying to find a better solution. There might not be one though. I think my solution was to check for ownership at each move, but that takes way too much code.) Anyway, I'll take a look at the update. As for the 32x32, it might be best to just leave it as a blank board for the moment. I don't have any good ideas for a starting position (and the 32x32 board doesn't fit on my screen anymore). |
Mats W (Kålroten)
| | Posted on Tuesday, October 17, 2006 - 7:03 am: | |
Ah, diagonal interception! Sorry, I missed that. Now it works so good so I can begin to test this game. For historical reasons 'ramming' the side of another boat with the stern should be rewarded, if possible. The man sitting at this position could be removed by approach capture. In ancient sea warfare ramming was a most important tactic. Moreover, how about introducing a variant where the men move like kings in chess? I suspect that this is possible, because there is so much strategical maneuvering involved so one could resort to simple capture methods. Mats |
Joshua Taylor (Archmageomega)
| | Posted on Tuesday, October 17, 2006 - 11:40 am: | |
The men already move like kings, but only if they have somewhere to move to. (Or did you mean capture like kings? That might work, but it's hard to capture king-like-pieces with other king-like-pieces.) I was actually thinking it might be better if they moved like queens. Generally speaking, there's not that much room to move anyway. (This would need some major testing to figure out which worked better.) Ramming doesn't sound like a bad idea, but I don't want to make the rules too complex. (Maybe it could be a variant or something.) Actually, until this gets playtested (a lot) I have no idea what will work well. Karl, I was playing around with the board configuration (16x16) and made the file below; however, after giving the computer 3 minutes to think of an opening move, it said 'Too many moves generated'. Is there anything that can be done about this? The other thing is, the AI plays this way too defensively. I set it to run on the initial configuration with 3 min per move and after 100 turns, it hadn't done anything. (It mostly just spun it's ships around.) This is the board that generated too many moves. (It was a save file, but that was way too big.) (define bset-16x16-test (board-setup (White (Mland a1 b1 c1 d1 e1 f1 g1 h1 i1 j1 k1 l1 m1 n1 o1 p1) (Eland a2 b2 c2 d2 e2 f2 g2 h2 i2 j2 k2 l2 m2 n2 o2 p2 a15 b15 c15 d15 e15 f15 g15 h15 i15 j15 k15 l15 m15 n15 o15 p15 h3 h4 i4 i3 m4 m3 n3 n4 c4 c3 d3 d4 c14 c13 d13 d14 h14 h13 i13 i14 m14 m13 n13 n14 h5 i5 h12 i12) (EBD b3 e3 g3 j3 l3 o3 b12 e12 g12 j12 l12 o12) (EBV b4 e4 g4 j4 l4 o4 b13 e13 g13 j13 l13 o13) (EBU b5 e5 g5 j5 l5 o5 b14 e14 g14 j14 l14 o14) (EBL e9 j8) (EBH f9 k8) (EBR g9 l8) ) (Black (Bland a16 b16 c16 d16 e16 f16 g16 h16 i16 j16 k16 l16 m16 n16 o16 p16) ) ) ;board-setup ) |
Mats W (Kålroten)
| | Posted on Tuesday, October 17, 2006 - 2:22 pm: | |
I meant capture like kings. If that doesn't work, then one might consider adding intervention capture to supplement the interception capture. Many alternatives could be tried out. Win condition could also be conquering of certain territory, now that islands are added to the game. Mats |
Karl Scherer (Karl)
| | Posted on Tuesday, October 17, 2006 - 2:50 pm: | |
Hi Joshua, glad you agree that the game now is working properly. Re: the system doesn't play well: The Zillions machine (like any computer) is not good in playing complex games with many pieces and many small moves which have little effect. I found myself often planning 20, 30 moves ahead because it takes many moves to maneuver a ship to a certain position and also move the men in between, especially when there is only one man in the boat. Hence the search tree is much too deep for a brute-search. Chess works with brute search because there area only a few pieces, half of them with quick, powerful moves. The conclusion is imho that the concepot itself is not very "Zillions-friendly". Having said that, from the aforementioned it is clear how we can make it more interesting, namely a combination of some of the following: - faster boats (maybe up to 3 steps independent of the number of men in it?) - fewer men - faster men - additional types of capturing - maybe introduce a KING whose capture ends the game Because of the slow men and boats, the 32x32 board doesn't make the game more fun to play than the 16x16 boat. With too many men and/or boats we easily get the "too-many-moves-generated" message, so I suggest we do not increase the number of men or boats. I will experiment a bit with the above ideas and maybe add them as variants. I will keep you posted. The game definitely is worth developing, but needs more development work put in. It has to be sped up in my view, so that it is not too boring to play (even with the computer doing only defensive moves, it took me 240 moves to win). Cheers, Karl |
Joshua Taylor (Archmageomega)
| | Posted on Tuesday, October 17, 2006 - 9:38 pm: | |
I agree that speeding up gameplay would be a good thing. As best I can tell, letting the men move like queens would have the least impact on gameplay (as well as the least increase in speed). I don't think letting the boats move full speed all the time would be too good, but increasing the boat speed (either x2 or +1) probably wouldn't speed things up much. Having different sized boats (a 2 unit boat that moves 2 per guy, for example) might speed things up, but that'd complicate the code way too much. Actually, I don't remember many games that use custodian captures (if that's the right word) but I think it usually makes the game fairly slow. On the other hand, king-like captures don't work too well for games with just one piece type. (And because of the boats, multiple piece types would be very complex.) I think the best thing to do would be to find some better capture rules (possibly in addition to custodian captures). At the moment, I can't think of what that might be though. As for the AI, does that setup really generate that many moves? I usually only get 'too many moves' if there's an infinite loop somewhere. I suppose speeding up game play would make the AI play better, but it'd also make 'too many moves' happen more often. |
Joshua Taylor (Archmageomega)
| | Posted on Wednesday, October 18, 2006 - 12:53 am: | |
I just finished a game using queen moves (without changing the captures). It took me 130 moves to beat the AI (30 sec, expert, small). It played better than it was with single moves, but it also generated more 'too many moves' errors. I think that sped the game up more than I expected (since the boats tend to clump up in the middle). I still think there should be one more way to capture enemies though. (What about stepping onto a boat with one friend and one enemy would capture the enemy? Or ramming maybe?) |
Mats W (Kålroten)
| | Posted on Wednesday, October 18, 2006 - 1:01 am: | |
I agree that creating a mini version of this game would be interesting. Then one could test the very principle behind this game. Now it plays so badly so it's not easy to test it. But is the code really implemented efficiently? Why is it doing all these captures all the time? When moving a boat one needn't do captures. To move a two segment boat to the south one only needs to code like this: s (verify empty?) cascade n n (verify (piece? twotype)) from s add When I look at this game it doesn't appear much more complex than chess, except on the strategical plane, where it is more like go. But I am certain that Zillions could play it better. Mats |
Joshua Taylor (Archmageomega)
| | Posted on Wednesday, October 18, 2006 - 4:31 pm: | |
Well, you can capture by moving a boat, so you still have to check for captures on all three boat parts. As for strategic depth, it would be similar to several other games, except, in this game, the board can be altered. Karl, I was wondering, how complex would it be to rewrite the boat movement rules to say that a boat has one move per man on it, and turning counted as one move (instead of all moves)? I doubt it'd really be worth the effort unless it was a simple fix though. (I'm gonna have to make a physical copy of this game to experiment with...) |
|