| Author | Message | ||
| Pargat Perrer (Pargat_perrer)
New member Username: Pargat_perrer Post Number: 6 Registered: 5-2015 |
Well, folks.... this is to anyone reading this, not just Mats who was responding to my other posts.... It's even worse, much worse, than I thought. Zillions has a feature called <attribute>. It is COMPLETELY BROKEN. None of what is documented about this feature is true. Here's a simple way you can see this for youself: Take the chess.zrf file that comes with Zillions 2.0. Make a backup copy, then make these 2 very easy edits to the actual file, not the backup: Find the main chess game section, i.e. (game title "Chess" ... ) Find the section (piece (name Knight) ... Now just before the (moves ... ) section add this line: (attribute may_move? true) This is all simple stuff. You just gave each Knight an attribute called may_move? and it is initially true. Now... go to the definition of the Knight's move, which is leap2... i.e. (define leap2 .... ) Change that line of code to this: (define leap2 ($1 $2 (verify not-friend?) (set-attribute may_move? true) (verify may_move?) add) ) All you did was add the code "(set-attribute may_move? true) (verify may_move?)" into the leap2 definition. As you can guess, this should have NO EFFECT. The attribute should always be true anyway, but just to be sure, we set it to true just before verifying it. THE VERIFY SHOULD ALWAYS SUCCEED. Now save the file and start up Zillions. Guess what? THE KNIGHTS CAN NEVER MOVE. That's right, the verify statement ALWAYS FAILS. Even though the attribute is true, always. THE DAMN MORONS NEVER EVEN TESTED THIS FEATURE! You are on your own if you are just getting into Zillions. It is pure garbage. This is just 1 of many, many broken features that were probably never even tested. | ||
| Sean Duggan (Dream)
New member Username: Dream Post Number: 107 Registered: 9-2000 |
Cool down, man. The following is the documentation for set-attribute: set-attribute affects the piece that is on the current square after the move is made. <attribute> is an attribute of a piece defined with the attribute construct. Note that it says "current square". After making the two moves in the leap, it tries to set the attribute, but can't because there's no piece there that will take it. It then tries to evaluate and comes up false because there's no piece there that can have that attribute set. If you move your verify to the beginning, before moving, it works. If you put an enemy Knight at your destination it works.  It's an honest mistake. Unfortunately, this program really hasn't been support for over a decade, so there's no easy way to learn except by example and talking on the board. Good luck! | ||
| As Bardhi (Aepasa) New member Username: Aepasa Post Number: 10 Registered: 1-2007 |
"It is COMPLETELY BROKEN" Nope, iT's not! Cheers | ||
| Pargat Perrer (Pargat_perrer)
New member Username: Pargat_perrer Post Number: 7 Registered: 5-2015 |
Sean Duggan, thanks for responding. Yes, I should cool down, but it's difficult when the language has so many 'gotchas' that any reasonable programmer / developer has to just say "This is horribly designed and implemented." For example, if I am allowed to call a macro (set-attribute) and that macro compiles without error or warning, that means I am expecting SOMETHING to happen. So when the authors of Zillions coded up <set-attribute>, they should have made it apply first of all to the piece on the current square, and IF THAT FAILS, then figure out that it is meant to apply to the PIECE THAT IS MOVING. How difficult is that to figure out? Instead of the macro failing to do anything at all, figure out that it is meant for the moving piece! Just figure it out! After all, they figured out that "add" is meant for the moving piece, which means the moving piece is being tracked. It is a known piece of information within the code block. And by the way, the subsequent (verify <attribute>) statement should be a compile error if there is no piece to apply the attribute to. Figure it out! You shouldn't just make the whole code block fail! What kind of mindset did these guys have? These guys are (or were) unprofessional programmers. I completely disrespect them. And this is just one of dozens and dozens of gotchas. Zillions can't even figure out parentheses. Sometimes it wants them, sometimes it doesn't, there's no rhyme or reason to it, and if you fail to provide them 'where needed' (lol), you get an error somewhere else in the code far away from the real error. Just horrible, horrible design. No one designing code like this today, for an app or a web site for example, would keep their job with this kind of garbage. The authors' real crime is that they have just walked away from this product, almost as if they threw up their hands and said "We can't take it anymore, we totally failed to design this properly and it stinks and we are walking away from it" and yet they continue to sell it and make programmers' lives miserable and won't even try and help out. I say to the authors, get back here and clean up your mess! Or else shut down this web site and never sell another copy of Zillions. | ||
| Pargat Perrer (Pargat_perrer)
New member Username: Pargat_perrer Post Number: 8 Registered: 5-2015 |
Sean Duggan and As Bardhi, I have proven now what should be beyond a doubt that set-attribute is broken. If I go back to the from square of the moving piece, and I <set-attribute may_move? false) and then (verify may_move?) the move is allowed! In other words, you can't set an attribute to false! Prove it to yourself: in your chess.zrf file (again make a backup), again give the Knights an attribute of may_move? and give it a value of true. But now change the leap2 definition to the following: (define leap2 ( $1 $2 (verify not-friend?) (go from) ;---- for debugging, make a Queen appear on d4 square ;---- only if we are on the from square of the moving Knight. (if (and friend? (piece? Knight)) (create White Queen d4) ) ;---- Now set the attribute of the moving Knight to false. (set-attribute may_move? false) ;---- The above set-attribute FAILED!!!! (verify may_move? ) $1 $2 add ) ) As you can see, the Knights are now allowed to move even though they should not be allowed because we <set-attribute may_move? false). And to prove there's a bug, I make sure I am on the from square of the Knight when setting the attribute, by creating a White Queen on d4. The White Queen does show up. You guys might as well admit this language is broken. There's plenty of other examples besides this very blatant one. Attributes are useless if you can only set them to true. | ||
| Pargat Perrer (Pargat_perrer)
New member Username: Pargat_perrer Post Number: 9 Registered: 5-2015 |
Actually, the problem is even bigger. Even if the current square is the square of the piece that is moving, you cannot CHANGE the attribute. In other words, <set-attribute> will not change the attribute value! Prove it yourself by giving the Knight the may_move? attribute and defaulting it to false instead of true. Then in the leap2 code I gave above (my previous post), change the (set-attribute may_move? false) to make it set the attribute to true instead. Now the Knights cannot move! The initial value of the attribute is the only value that "sticks". HAHAHAHAHA! I have to laugh even though it is definitely NOT funny. | ||
| Sean Duggan (Dream)
New member Username: Dream Post Number: 108 Registered: 9-2000 |
Reread the documentation. The attribute is set after the move is completed. So yes, if you change the attribute and then try to test it, it will not reflect the changed value. I will agree that ZRF is not always intuitive. I had a similar issue with the parentheses when I started out. It follows a sort of LISP structure, if that helps. That said, it's far from the worst scripting language I've worked in as well. As for the code figuring out when you made mistakes... well, there exist the occasional Do What I Mean system or language, but they're rare because it's all too easy to make one mistake and for a computer system to assume you made a different one. And are they still selling licenses then? I know I bought mine over a decade ago. | ||
| Pargat Perrer (Pargat_perrer)
New member Username: Pargat_perrer Post Number: 10 Registered: 5-2015 |
Sean, thanks again. I know the documentation says after the move is complete, but all that does is take away the power of <set-attribute>. They actually went OUT OF THEIR WAY to prevent the attribute from being changed before the add statement. That is preposterous! There is no explanation for it other than they were wanting to limit what programmers could do. So we cannot use an attribute as a flag to stop us from even doing an add statement. The add has to be done first, which commits the move and exits the code block. Horrible design, horrible implementation everywhere you look in this language. Yes, they are still selling licenses. Mine is only a few months old. The compiler doesn't have to figure out your mistakes, although figuring out typos and parentheses would be VERY useful. But my point was the compiler should know CONTEXT. If you're moving a piece and use <set-attribute> it's obvious that you mean the moving piece. To let you indicate a different piece, they could have allowed a true or false argument to indicate either the moving piece or the piece on the current square if any, with a runtime error if there is no piece on the current square. They could also have required each piece in the <board-setup> statement to have a unique ID, and then allowed an (ID) argument to <set-attribute>. They didn't think of ANY of these things. Wow, I'll take C or C++ over this any time. | ||
| Sean Duggan (Dream)
New member Username: Dream Post Number: 109 Registered: 9-2000 |
{nods} I understand your frustration. Scripting languages tend to be very fiddly, and it sounds like you have some very different ideas than they did about how to notate moves. As it is, the design decision, done consistently over the course of the commands, is that no change is committed until the add. And similarly, all evaluations are done on the current square rather than a base piece. And adding does not exit the code block, incidentally. You can see that pretty clear in the case of the chess moves, which add multiple moves in the same loop. Perhaps we'd be able to help you better do what you plan to do if you explain what you're trying to design? | ||
| Pargat Perrer (Pargat_perrer)
New member Username: Pargat_perrer Post Number: 11 Registered: 5-2015 |
Sean, I'll explain what I'm attempting to do in a later post. That short little thing you wrote -- "no change is committed until the add" -- woke me up to just how this thing was designed (and the design is still bad). Why couldn't the authors make that little statement somewhere very prominent in the documentation, with a few examples including <set-attribute>? I also found out this is the case with <change-type>. The type of the piece doesn't get changed until after the add. If the authors had thought to stress that point, it could have saved plenty of time and frustration for countless game authors, I'm sure (since I'm one of them). But to show that the design is bad... Do you know the SQL database query language, and in particular Transact-SQL? I am no expert in it, but I believe the goal there is that blocks of SQL commands can be done in sequence, and at the very end everything is to get committed to the database. I believe there are intermediate commits to the database... but if any step fails, even the very last one, the entire sequence is 'rolled back' and the database is guaranteed to be in the same state as before the Transact-SQL block began. This allows, for example, the SQL developer to commit say an insert of a new record into a table, and then somewhere else in the transaction block, query that table and expect the result to include the inserted record. However much work it took to accomplish that, it is priceless and virtually necessary for Transact-SQL to actually work properly. This to me is how Zillions should be designed: if a move is a series of steps and doesn't get committed until the very end (the add statement), it should be expected that a <set-attribute> during the move should be reflected back in a (verify <attribute>) statement even if it occurs before the add statement. Instead, these guys (to save work, I assume, or because they couldn't figure out how to do it) decided they'd let the <set-attribute> statement to COMPILE, but it would do nothing unless the add statement had been done! The very least they could have done would have been to make it fail to compile if it appeared before the add statement. Or they could have just made it work... but then they'd have to roll it back if the add statement didn't happen. I guess that must have been their problem, but if Transact-SQL can handle it, these guys should have been able to. So for what they did, I have to totally disrespect them. By the way, how do you get that the add statement does not exit the code block? In the zrf files I've looked into, the add statement seems to always come at the end of the code block. I thought only add-partial and add-copy-partial continue the code block? Finally, I should probably ask a few questions about you since you are taking time to respond to my posts. Have you been doing Zillions games for over a decade? What kinds of games have you done, and what motivates you to use Zillions despite its many problems? | ||
| Sean Duggan (Dream)
New member Username: Dream Post Number: 110 Registered: 9-2000 |
Unfortunately, we don't have them to ask. The programmers have moved on to other projects, although Jeff Mallett answered some questions back in 2013 on this message board. I used to be really big into ZoG a decade ago. I wasn't great at them, but I was decent, and I kept active on www.chessvariants.org (username of "fuzzy"). I mainly played Chess variants, although I dabbled in programming a few other ones. As to why I used ZoG... well, it was, and to some degree still is, the only real option out there if you don't want to programming in the Artificial Intelligence yourself. As to how I found out about "add", it's in the documentation, the Zillions Language Reference available via the help menu. It's discussed both in the entry for "add" and in the introductory topics on designing a game, particularly "The Internals of Movement" which states "It is important to keep in mind the difference between generating a move and playing it out on the board. In a moves or drops block you are setting down the logic to generate moves. Moves will be generated whenever Zillions needs a list of moves in a given position. When a move is generated by an add it is placed on list of legal moves. It is not actually played on the board at that time and it may in fact never be played. This is important because inside your move generation logic you will be querying the state of the board, e.g. is the current position occupied?, and you must realize that changes in your move logic will not have been applied at this point. A capture you are making as part of the move, for example, will not have taken place yet. The move that is being generated as legal may very well never be played out, in which case the capture will never occur." Other than that, I learned a lot by studying the existing games and copying what they did, then trying to modify it. There was a fellow named Fergus Duniho who wrote up some more advanced documents on the limitations and tricks of ZoG, but I lost my copy of those documents several computers ago, and he seems to have moved on to other areas. There's also Axiom, which is a port of Zillions of Games to a Forth-based language, I think partially piggy-backed onto the Zillions engine. I never really did much to it. Oh, and there's a basic development page that may answer some of your questions. | ||
| Edward Holzman (Edholzman)
New member Username: Edholzman Post Number: 5 Registered: 6-2005 |
I haven't written any ZRF code in a looong time, but it worked well for me and many others for many years. So just what is all of your bellyaching and trumpeting of your own ninja-like programming skillz supposed to accomplish, Pargat Perrer? If you have your own totally awesome and flawlessly composed scripting language for generating abstract games with a built-in AI, then please offer it up. Otherwise, constructive comments and actually developed improvements would be better received. | ||
| Greg Schmidt (Gschmidt2)
New member Username: Gschmidt2 Post Number: 182 Registered: 1-2007 |
In regards to the suggestion that Zillions move generation actually work like a transaction based system, it's not the same model. You see, when generating a move, the "add" doesn't commit the ACTION of the move, but rather the GENERATION of the move (code) itself. The actual board state update doesn't occur until and unless the move is applied (i.e. executed). Think of it this way, the "add" causes some code to be generated that may or may not be executed later. This could be for several reasons. For example, move generation may be performed for no other reason than for generating a mobility metric. Another example is that the Zillions engine may reorder (prioritize) and prune moves based on whether captures occur in the move. That is another case where some generated moves may never actually get applied (executed). In the case of attributes, "add" will cause the generation of code to set or clear the attribute, it does not actually set or clear the attribute, that would occur later only if and when the engine decides to apply the move. So once again, it's wrong to say that "add" causes a state update on the board, it doesn't, it causes a move to be generated such that when and IF it is ever executed it will have a specific effect on the board state. Once you wrap your head around this concept, it all starts to make sense (and the ZoG help file does a decent job of explaining it if you read it carefully). Now you might suggest that while generating the move, the board could be tentatively updated to reflect the partial update state so that things like pieces and attributes would appear in the same state as they would IF the move itself were to have been executed. (once again, the add does not commit the board state update, but the move generation itself). The reason why the ZoG authors did not do that is because the additional overhead of performing "tentative" board/attribute updates (which BTW would also need to be undone whether or not the "add" was performed) during move generation would slow down move generation to the point where the engine would be significantly weaker. If you've ever watched the node counter during the search you will see that they did an excellent job of making move generation efficient. Board game developers understand that one of the hallmarks of a strong engine is an efficient move generator. I strongly believe the ZoG authors made extraordinarily good decisions which account for Zillions amazing playing strength, especially considering that it's a generic engine. | ||
| Pargat Perrer (Pargat_perrer)
New member Username: Pargat_perrer Post Number: 12 Registered: 5-2015 |
Well, if nothing else I've managed to get some action on this site! @Edholzman The bellyaching (no trumpeting) is because there IS NO TOTALLY AWESOME AND FLAWLESSLY COMPOSED scripting language for blah blah blah. Exactly what do you mean by "worked well"? Did you write TicTacToe or some similar simpleton game? But even if you wrote something more complex, consider all the kludges and hacks you had to code to make it all work. My chief complaint is that the authors abandonded this project despite it's promise, chasing after more lucrative ventures, and continue even now to sell it despite its design flaws. Allowing a statement to compile yet do nothing: that is a MAJOR DESIGN FLAW (barring a no op statement, of course). Internally to the engine, these statements have to be kept in a queue, because if the add is encountered, all the do-nothing statements actually get executed. In today's computing, this queuing isn't necessary, and the C++ STL proved years ago that copying state into memory is and WAS perfectly acceptable even circa 2000. These guys just didn't learn that. @Gschmidt2 Yes, I was asking that the developers allowed for an in-memory copy of the game state to be manipulated and queried by move generation code. An undo function is a piece of cake, just use the Command design pattern along with a LIFO data structure. A programming intern knows these things. Of course, this is 2015 and Zillions was done about 13 years ago as far as development goes, so some allowances can be made. What I think people like Ed Holzman are so proud of is that they solved the problems by using hacks and kludges, which makes them feel clever. But it exposes the design as flawed. Now you speak of move generation speed, and in 2002 this would have been a big concern. So ok, more allowances. And I'm sure this is the heart of the issue, generic engine capability versus generation speed and playing strength. So for 2002, maybe they did do a good job on that tradeoff... it's just that they left it behind and in 2015 it looks now like a Commodore 64. They should have continued on at least part-time and with their knowledge of the internals, they could have improved things (including design) immensely. Imagine the possibilities if there were an in-memory copy of the game state that move generation was maintaining! Memory is relatively cheap now, this engine could be truly awesome in capabilities. If you all want an example of great design, look no further than the C++ STL. Very generic, yet very very fast and robust. Complex, yes, but consistent and extensible. This is my last post, as I don't want to get deeper into senseless argument. No one is maintaining Zillions and that is a shame, that's what it all boils down to. Have fun 'overclocking' your Commodore 64, lol. Meanwhile, Ed Holzman, maybe I just WILL write a new scripting language. Never thought of doing it before, but I'm motivated now and more than capable. | ||
| Greg Schmidt (Gschmidt2)
New member Username: Gschmidt2 Post Number: 183 Registered: 1-2007 |
You missed (or avoided) the point. A tentative image of the board could be kept up to date during move generation (which BTW would ALWAYS have to be discarded regardless of whether "add" occurred or not - do you understand the reason why?) and there's no need to mention whatever design patterns may support that because that completely misses the point. Just because there are common ways to implement something, doesn't mean it should be implemented. The point is that a viable board game AI system designed in 1998 or 2015 wouldn't go through that overhead during move generation as it would add way too much unnecessary overhead to the engine and thereby greatly reduce its performance. Rather than even consider that, you just want to write off the developers as idiots, which they most certainly are not. Both are accomplished and award winning Chess programmers. In regards to C++ STL, do you really expect the Zillions developers to require that anyone who develops a game purchase a C++ Integrated Development Environment (IDE) and learn C++ and STL? If they had done that, I'm sure you and many others would be complaining that you have to buy it and learn something which professional programmers are trained in. Unless you are saying that the Zillions developers should have implemented their own version of Microsoft's Visual Studio for C++ to be included in the package which is an absurd expectation. As of this writing, there are 2358 free games that hundreds of game developers (some who are non-programmers) have developed. That's nothing to sneer at. And since you claim to be "so capable", until we see the end all be all game scripting language from you that beats Zillions Chess hands down, it looks to us as if you are just complaining about things which you don't fully understand (e.g. the mechanics and efficiency requirement for move generation). As you say, it should be based on C++ STL and contain a complete modern IDE (Integrated Development Environment). And if it can't outperform Zillions at Chess and other games, then don't even bother showing it to anyone. | ||
| Sean Duggan (Dream)
New member Username: Dream Post Number: 111 Registered: 9-2000 |
*sigh* Well, so much for that. I understand his early frustration — it sounds like he missed the parts of the documentation, and started off on the wrong assumptions — and I suspect that after that, he just got stuck in a vicious cycle of feeling he needed to defend his prior statements. On the plus side, this got me back to looking at Zillions. It's been a few years. | ||
| Jon Steven Nelson (Jonn99)
New member Username: Jonn99 Post Number: 7 Registered: 1-2014 |
The ZoG devs split 'n' quit, they've allowed this copyright 1998-2003 macro-language monstrosity to rot and decay and get all the old and new .zrf authors frustrated and disappointed. | ||
| Sean Duggan (Dream)
New member Username: Dream Post Number: 112 Registered: 9-2000 |
*facepalm* At least the resident troll waited until after the querent left. | ||
| Mark Lefler (Markl)
Moderator Username: Markl Post Number: 6 Registered: 3-2001 |
Us "ZoG devs" are still around. Just concentrating on other things, for example, Komodo Chess: www.komodochess.com. It would be great to continue developing Zillions, but there is just not enough time in the day. We are proud of how many of you game developers keep coming up with clever ways to use ZoG. Thanks, Mark Lefler | ||
| As Bardhi (Aepasa) New member Username: Aepasa Post Number: 11 Registered: 1-2007 |
Hi Mark, Any chance to "delegate" some Time? Cheers, Astrit | ||
| Greg Schmidt (Gschmidt2)
New member Username: Gschmidt2 Post Number: 184 Registered: 1-2007 |
Thank you for your message Mark, it's always great to hear from you and best of luck with komodo chess. I know I speak for the vast majority here when I applaud your efforts along with Jeff's which produced such an amazing achievement as Zillions (please ignore the inane comments of the misguided few who would say otherwise as they will never get it). Also, thank you for your words of encouragment to the ZoG developers. 2358 games and counting!!! Best Regards, Greg | ||
| Pargat Perrer (Pargat_perrer)
New member Username: Pargat_perrer Post Number: 13 Registered: 5-2015 |
Now I have to post again because of how my previous post was hacked by Greg Schmidt... @Markl Why not open source the Zillions engine? Can you really be selling enough in 2015 to justify keeping it proprietary and hidden and forever unchanged? Zillions game designers may be a niche market, but your product had a great vision, why not allow it to be improved by developers who DO have the time? I sincerely hope you will consider this. And yes, game developers did come up with 'clever ways' to use Zillions, but it should offend your sense of pride to know these 'clever ways' are kludges to compensate for bad design lacking even the most primary needed features such as a debug environment or the provision of variables. If you disagree and want to claim that the design 'had to be' this way for technical reasons, well, we can't verify that without seeing the source, but my experience with languages like Python and my own parser / compiler designs from years ago tells me it is not the case, but rather shortcuts were made that were never fixed. @Gschmidt2 What a laugh! WHERE did you get the notion I want C++ STL to be part of Zillions? I merely said STL was an example of great design. Wow, no use discussing anything with you. And you keep rambling on about performance and discarding things... are you a noob? Up until C++11, the STL was copying and discarding like gangbusters and it was STILL giving great performance (now with C++11, even better with move semantics and copy eliding). So you see, I avoided your point because it was irrelevant. With your kind of thinking, we would never had HAD a C++ STL. Instead, we had an STL that worked just fine thank you very much even in the '90s, and only in 2011 did it get a major performance boost. That's how things should be done. A game authoring program without a debug environment... without variables....with restrictions on commands because there is no state machine acting on a copy of game state to enable them... is an incomplete, insufficient design. Period. The fact that people have kludged their way around this is a testament not to the cleverness of the design, but to the perseverance and dedication of the game authors. They found back doors to do what they should have been able to do easily all along. Imagine Python with no debugging capability, not even print statements or variables, would you call that a good design? Oh, 2358 games. How many of them work as advertised? Being interested in double move variants, I tried both versions that come with Zillions: Double Move Chess (Capture) and Double Move Chess (Checkmate). Neither of them works as advertised, and in fact, they both do the exact same thing. Another developer bites the dust... I can only imagine how many of these busts there are. Plus a lot of these games are no more involved than TicTacToe. But wow, 2358. Quantity over quality, that's your measure of success, just as you put performance ahead of working properly. As I wrote to Sean Duggan, what was needed with state-changing commands was a notion of CONTEXT. In the context of your move generation block, <set-attribute> should have a piece on which to act, and if it is possible for programmer error to cause no piece to be found using standard assumptions (the piece is the moving piece, or by a provided true / false parameter it could be a piece on the current square, which allows for runtime error) then throw a runtime error or exception. Otherwise, at least in the CONTEXT of a debug environment the <set-attribute> should produce an effect that is verifiable AND that plays a role in determining what subsequent commands do within your debug environment. Changing state should not be limited to being done after an <add> statement. If you need an undo stack, you provide one, very easy. This is how good programmers program. I'm sorry you don't get it. Performance is secondary to correct operation and design. You optimize for performance AFTER you have correct operation and design, not before. | ||
| Pargat Perrer (Pargat_perrer)
New member Username: Pargat_perrer Post Number: 14 Registered: 5-2015 |
Incidentally, a few more Zillions bugs that seem to have been around forever: (1) in the rules for standard chess, the King-shift macro: if you begin by issuing the attacked? command, it will (on my system) always return false even when the King is in check. I see plenty of references to this problem in many of the threads here, and some people say it works on their system. It seems to be indeterminate whether it will work properly or not. (2) in the same rules, the 0-0 and 0-0-0 macros, there are several line doing (set-attribute never-moved? false) before the add. This does nothing according to the documentation, and I've noticed during some chess games where the computer should castle but doesn't. There's an inordinate number of games where the engine never castles. I believe the authors expected these lines to be executed and they aren't so quite sure castling is a bug in Zillions. I'm sure I could find plenty more if I had the time. | ||
| Sean Duggan (Dream)
New member Username: Dream Post Number: 113 Registered: 9-2000 |
Can you explain what you mean by your post being "hacked"? They look the same to me. That's odd. The double-move variants are distinct on mine. The easy test for the difference between Capture and Checkmate variants is to determine whether you can move your King into a position where he can be taken. That test passes on my side. If the second move would put the King into a situation where he can be taken with the next move, that move is not valid. As regards the "attacked?" bug, I'm not entirely certain what you're referring to. Searching for the keywords of "attacked" and "bug" in the posts, I come up with 5 posts, one of them being this post and another by you. The only one that refers to a bug is this one which references a bug with "not-attacked?". I'm not certain what to say on castling... it sounds like your plaint is that the computer doesn't pick it as often as you think it should. I'll freely admit that I'm a novice chess player, but it always seemed to me to be a very conditional move. It's entirely possible that the algorithm just doesn't rank it as highly. As for set-attribute, why wouldn't those be doing anything? They're setting that attribute for each of the squares, if there were a rook there at the end of an added turn. As for the rest of it, well, I don't think you can deny that you've been very hostile on the topic. I really do understand your frustrations. I'd like a debug mode too. There are a number of options available in the Authoring mode. Exporting the pre-processing often sheds a light, particularly if you're looping. As for your idea of context, I still feel that your problems largely stem from that you have a fixed idea of how the engine should work and you're very frustrated that it instead works in a different way. Zillions does not set information on a piece until it is added. It does not retain board-state for the moves such that they affect future moves. The reasons for so doing are alluded to in posts above, namely that it's an aspect of how the move-pruning algorithm works. I know their algorithm definitely works better than the versions that I cobbled together back in school and I suspect that things like not trying to maintain the state of the board, and being able to sort and eliminate duplicate moves are a major aspect of it. *sigh* I have to head off to work, so I can't really go on longer at the moment, but I'll just say that you need to cool down and stop attacking people, and rather ask questions. While it may not be literally true that you get more flies with honey than with vinegar, the principle of it is sound when it comes to human interaction. You have a community here willing to help, but people tend to be less willing to help when the person they're trying to help is spewing insults and suggesting that the problem lies everywhere but in their code. | ||
| Greg Schmidt (Gschmidt2)
New member Username: Gschmidt2 Post Number: 185 Registered: 1-2007 |
Sean - you wrote "Zillions does not set information on a piece until it is added". By "set information" , if you are referring to the board update, then actually it doesn't occur with the "add", it MAY occur LATER when and if the move is ever APPLIED. Just a clarification. Regarding being "hacked", I have no idea what was meant by that, but given P's ranting, it's not worth any further attention. P's posts should carry about as much weight as Jon Nelson's. He really should apologize to Mark & Jeff for his comment: "These guys are (or were) unprofessional programmers. I completely disrespect them." This is just one example of his knee-jerk non researched comments. If he had done any research at all he would have learned that these guys are award winning Chess programmers. What a shame that the only way he thinks he can get his point across is by criticizing everyone else and trumpeting his own supposed genius. Well P, guess what? It's having the opposite effect since you've made it quite clear that no one can have a rational discussion with you. | ||
| Greg Schmidt (Gschmidt2)
New member Username: Gschmidt2 Post Number: 186 Registered: 1-2007 |
Sean - One more thing... Bravo on your post. I concur wholeheartedly with what you wrote. | ||
| Pargat Perrer (Pargat_perrer)
New member Username: Pargat_perrer Post Number: 15 Registered: 5-2015 |
Sean, I didn't set out to be attacking people, they attacked me first. It started with Ed Holzman implying I was "trumpeting of your own ninja-like programming skillz" -- where did I do that? Nowhere! I even said regarding an undo stack that any programmer intern could do that. Then Greg Schmidt comes along and his first post is ok, but when I point out he's overemphasizing performance, he gets defensive and counterclaims I want the C++ STL to be part of Zillions -- total rubbish he fabricated to make me look bad. So ok, they want to play hardball, I can play hardball. Now it's Greg Schmidt looking bad! And I notice he didn't offer up anything in response other than ad hominen attacks. I guess he at least knows when the jig is up. My coworkers (all at least as credentialed as I am, no one less than Ph.D level in math or CS) are getting quite a chuckle out of Mr. Schmidt's posts and all of his rash assumptions. In fact, there's somewhat of a contest here to see who can find the funniest "Schmidtism". Looks like he's been a long-time poster here, and that is really the worst kind of authority -- one who becomes a 'legend in his own mind' by sheer uncontested longevity on a forum such as this, one who thinks he 'knows it all' and fails to realize (by lack of being challenged) he doesn't even know the fundamentals. Meanwhile, he assumes I'm some no-name loser. No one can have a rational discussion with me, he decides! Ha ha, would he be surprised! I could name names, but... well, poor Greg, I really shouldn't pile on at this point. By the way, if you Google me by my name here, you'll find virtually nothing because I prefer NOT to be circulated on social media. And in fact Greg Schmidt, I am well aware of Mr. Lefler and Mr. Mallett (there goes another of your rash assumptions) although I have never had direct dealings with either. Reputation alone doesn't dismiss what Zillions is (incomplete and flawed design) and what has happened with Zillions in the past 13 or so years (nothing despite major frustration for game authors and their need to resort to kludges). But Sean, you seem much more reasonable and at least open to thinking differently, if we can just ignore Mr. Schmidt and his hero worship of the Zillion authors, maybe we'll get somewhere. As for apologizing for the remarks I made, well, I only regret limiting their unprofessionalism to the programming profession. As businesspeople, they also earn my disrespect. But I do praise their vision in even creating such a product, and the longevity of it is testament to their dedicated base of users. This makes their abandonment of the product all the more worthy of criticism. What happened to the authors' original dedication? And I ask again, can't they at least open source Zillions and let developers loose on it? So enough about that, it is what it is and it is NOT what Greg Schmidt says it is. Let's ignore him, Sean. This whole schpiel you and Greg keep spouting about move-pruning and performance is utter nonsense. Copies of state CAN be made in memory not just for moves made, but for moves that COULD be made, and the cost is virtually negligible for performance. THE C++ STL IS LIVING PROOF OF THAT! Sean, you write that I got trapped by some false assumptions, but not the ones you mention. My false assumption was that since the actual game board and pieces are the only ones we have access to, our move logic code including commands like <set-attribute> would change this one-and-only state, and somewhere in the internals there would be an undo stack to trace state back when needed. When I saw that state was NOT changing, I thought it has to be a bug or something the authors did deliberately to prevent us from changing state... and then finally I drew the astounding conclusion that the Zillions authors made the design decision to hide away the tracked state, thus preventing developer debugging and making lots of other things much more difficult than need be. This is why Zillions developers go to such riduculous lengths to track state, all of which are anti-patterns. But it's more than just debugging that is prevented. As I showed with <set-attribute>, I as a developer cannot set an attribute of a piece, such as may_move?, to false, and then use a conditional later in the same move generation block that queries that piece's may_move? attribute... because the piece that got changed is somewhere in the engine internals, and the only piece I have access to is the real game piece. My conditional will give an incorrect result. So instead I have to resort to something like dummy positions and dummy pieces... truly pathetic. [ And I just found this comment from Jeff Mallett way back in 2003 "(If using "dummy" things sounds kludgey, it is, and it's one of my top priorities to obviate it with a better system.)" (from the thread that has subject "How Can I....?") HaHa!!! Taking a long time, huh, Jeff?] The truth is that copies of game state must be made in the engine internals, and the authors decided not to give programmers access to it. Evaluation of a line of moves has to take place on a terminal position, with all its characteristics in memory. So all that Schmidtism about performance and discarding changes is just Greg Schmidt missing the point. Whether this is done using bitboards or some other optimized technique isn't important, what is important is that we the developers are not given any access to the tracked state. But somewhere in memory state IS being tracked, IS being changed, and those changes ARE being discarded, and so Greg Schmidt and his proclamations can just be dismissed. He thinks the developers have somehow invented a new way to evaluate lines of play in board games without tracking state, and he bends over to worship the developers as gods! That's what really has my co-workers and I chuckling. As you should know, even today's computers are truly dumb and have to be told EVERYTHING about state. They don't LEARN anything. There is no neural-network CPU that can learn patterns like the human brain, i.e. by changing connections between thousands or millions of neurons... although we are working on it! Your word 'hostile' is a bit strong, but I have been critical of the Zillions authors for their treatment of the project. I'm known for 'wearing my heart on my sleeve', as I think they say in America. I'm not going to stop being that way to people who engage in bad programming / design practices, including creating an API that forces users (game developers) to use anti-patterns and kludges, or who start a business and then abandon their customers. These guys did all of this. Oh, about the two double-move variants. I gave the wrong ones: it's the Double-Move Chess (Checkmate) variant and the Marseillais Chess variant. Both variants state that the first move of a double move may not give check. In fact, both variants allow this, and if you look at the source there is nothing special there to even try to prevent it. As for the castling thing, I suppose only the authors could tell us whether it's a ranking issue or a genuine bug. | ||
| Greg Schmidt (Gschmidt2)
New member Username: Gschmidt2 Post Number: 187 Registered: 1-2007 |
Sean is correct, you're posts are hostile. Sean wrote: "but people tend to be less willing to help when the person they're trying to help is spewing insults and suggesting that the problem lies everywhere but in their code." I'm curious to know what you PhD co-workers have to say about that? I attacked you, really? Go back and read the thread. I first challenged your criticism of Zillions, not an attack, but a "let's see you do better" sort of challenge and then you launch a full blown attack on me by making ridiculous assertions such as "there would have never been a C++ STL with thinking like mine. And you then make the claim that I am a noob who also hacked our post (as if that even makes sense). What's up with that? You call the creators of Zillions unprofessional programmers who deserve no respect on their own forum. I stand by my previous statement, you still owe them an apology. Oh and regarding the efficiency of C++ STL, have you ever benchmarked it? While you can argue that it's a nice design, it's inefficient when compared to writing custom algorithms. The problem is that they sacrificed performance for generality. Have you ever written a game search engine such as a Chess program? I somehow doubt it. If so, please tell us where to find it so we can play it against the Zillions Chess engine. If not, the challenge for you to write a custom Chess program that outperforms ZoG's general game engine playing Chess. That should be an easy task for you since you're such an expert at how game search engines should be written. | ||
| Greg Schmidt (Gschmidt2)
New member Username: Gschmidt2 Post Number: 188 Registered: 1-2007 |
"The truth is that copies of game state must be made in the engine internals, and the authors decided not to give programmers access to it." FALSE. Game state is updated only when the move has been applied by the search engine to explore a new state, but NOT when the move is being generated which is what your major complaint is. So no, the Zillions engine is not hiding some state update during move generation and preventing you from accessing it. | ||
| Pargat Perrer (Pargat_perrer)
New member Username: Pargat_perrer Post Number: 16 Registered: 5-2015 |
He's still typing! Yes... benchmarked C++ STL (and others: Rogue Wave, Boost, etc) on many platforms, under many environmentals from clusters to standalone devices. Our results are not for disclosure, but let's just say they far exceeded expectations. Yes, a price is paid for generality... but a very small, almost negligible price, as has been proven by C++ itself, making Soustrup a legend in computing circles. The only case where STL wouldn't be recommended is for embedded RTOS for military or medical devices where every clock cycle, every memory R/W, every stack frame is critical. For those kinds of systems, you usually see assembly or C modules, no C++ at all. Zillions does not fall under this category. Can a chess engine gain a few ELO points by being coded in C with custom algorithms and containers? Yes... but the inflexibility the engine is stuck with means that any new feature warrants a complete rewrite because refactoring is actually more work. But if you're Komodo or Stockfish or Houdini striving for the pinnacle of chess rating, go for it. Zillions is nowhere near that level, and was meant as a game developer's tool, which means design flexibility should have been paramount. It may well have been that the critical error of the authors was developing for speed rather than flexibility, which would explain a lot. And then there was no going forward, and no going back -- stuck in neutral. The fact that they are doing Komodo now speaks to this, indicating this may indeed have been the design error they made. You can type what you like, Greg Schmidt, but I'll take Jeff Mallett's admission of guilt over anything you spout. Jeff Mallett admitted Zillions is kludgey, said in 2003 it was his main objective to change that, and did NOTHING. Nada. Zilch. I see through the clever little ruse you attempted. You speak of 'game state', i.e. the one-and-only state of the actual game being played. Of course, that only changes when a move is played. Obvious. But the quote of mine that you try to portray as false was referring to COPIES of game state -- mutable copies that developers need access to for debugging, and that in the engine internals ARE being changed during move generation. Are you dense? How is Zillions going to know whether a generated move multiple plies ahead from the current game position -- i.e. that single game state you are referring to as if that is the only thing Zillions needs and everything else is magic! -- is even legal or possible if it isn't updating a mutable copy of game state? I wrote a C++ chess engine in high school, it played above 2000 ELO level despite not being particularly optimized, and it used alpha-beta algorithm which acted on changing copies of game state. The techniques of storing this state can be optimized (bitboards are a prime example) but the programmer needs access to it to debug and further develop. Zillions authors deliberately declined to provide that access. For you to declare that such state doesn't even exist internally in Zillions is ignorant and preposterous. Zillions is not a neural network feedback engine. If it was, every user would have to train it to learn chess from nothing, feeding it pgn files by the tens of thousands. Instead, it merely parses scripting language to determine the rules of the game it is playing. This is nothing but code generation, extremely limited by the fact the language has no notion of variables, of numbers, nor of querying nor setting state on the internal changing copies of game state during move generation. Anyone who knows anything about turn-based game coding would realize that my statement about mutable copies of game state used internally by the engine must be true. It is also obvious that Zillions does NOT provide access to any of that. And once again, Jeff Mallett himself indicated that the kludges this makes necessary were at one time his top priority to obviate. SOMETHING caused that top priority to never get acted on. Either a design that was so inflexible as to need complete rewriting, or perhaps more monetary rewards in moving on to something else entirely... while leaving Zillions on the market for game developers to kludge around with. Either one makes their legacy extremely poor in my book. | ||
| Sean Duggan (Dream)
New member Username: Dream Post Number: 114 Registered: 9-2000 |
I'll admit that I'm a wee bit confused about the discussion of the STL as being in any way optimized since all that it is a template library, that implementation varies over systems, but that's beside the point. Pargat, I'm really not certain where you're going with all of this. If you're looking for a refund, you probably could have gone that route a long time ago. If you were looking to have attribute explained, well, we did that. If you're looking to try to win an argument, you're not getting any traction here. If you're just looking to be disruptive and throw insults around while trumpeting that you could do better, well, that's where you've been pegged here. That's really the only thing you've achieved here. I would like to believe that you are sincere and passionate about board game development, but you're coming off as a troll, plain and simple. So, if you are dissatisfied with the product, ask for a refund. If you believe you can do better, do so (as I pointed out above, there are other projects such as Axiom). If you're just interested in trying to raise yourself up by insulting a decade-old program and insisting that the developers are complete idiots because they didn't think the way you do... don't. I'm really sorry. I try to be a patient person, to see things from the other person's perspective, but it depends on the other person being willing to be reasonable and you've shown that you have no interest in that. I'm sorry for that and I'm sorry for you. I wish you good day. | ||
| Pargat Perrer (Pargat_perrer)
New member Username: Pargat_perrer Post Number: 17 Registered: 5-2015 |
You actually think I'm so shallow as to want a refund? I'm a software engineering professional. What passed muster 15 years ago complete with bugs and bad design is now worthy of nothing but scorn. It is an insult to the profession. Would you buy Windows ME in today's market? I'm insulted that these bozos still sell this crap and that there are still a couple of holdouts hanging onto it like its manna from heaven. Wake up! This isn't the '90s. If we don't demand professionalism from people, the profession suffers. Zillions is an anachronism. It is now nothing but a child's toy, and should be priced accordingly with warnings "For ages 5 to 12 years". I'll bet these authors point to their web site and say to their peers, "Look, it's still up and selling!" Well, yeah, because no one tells the new visitor who wanders here what a piece of sh#t it is. THE AUTHORS HAVE ABANDONED THE PRODUCT AND SO SHOULD EVERYONE ELSE. | ||
| As Bardhi (Aepasa) New member Username: Aepasa Post Number: 12 Registered: 1-2007 |
"THE AUTHORS HAVE ABANDONED THE PRODUCT AND SO SHOULD EVERYONE ELSE." Me No! Cheers, Astrit | ||
| As Bardhi (Aepasa) New member Username: Aepasa Post Number: 13 Registered: 1-2007 |
"THE AUTHORS HAVE ABANDONED THE PRODUCT AND SO SHOULD EVERYONE ELSE." Me No! Cheers, Astrit | ||
| Andreas Speiger (Andique)
New member Username: Andique Post Number: 20 Registered: 11-2007 |
After a long time, i worked on "AstralChess" again. So, i took a look in the discussion board and found this thread. I didn't read the whole posts here. But i think, for this problem was already asked and has been answered. A few threads above. Look at: "Major bug with adding an attribute?". regards from germany! | ||
| david bennett (Dpoly)
New member Username: Dpoly Post Number: 3 Registered: 4-2017 |
There is nothing like Zillions out there, that I know of, but it is showing its age and it has a few issues. Do you think there would be interest in a new or updated version, perhaps on newer technology? | ||
| Sean Duggan (Dream)
New member Username: Dream Post Number: 119 Registered: 9-2000 |
@david: It would be a nice thing. Unfortunately, such things require work, and that's hard. :-D More seriously, most of what Zillions does is relatively elementary in terms of building and pruning search trees, or parsing a rules file to determine legal moves. The big catch (and, as I understand it, the major proprietary knowledge of the company) is getting that "value" for a given square / move for an arbitrary game. I think ZoG calculations are largely based on mobility, but I could be wrong. Axiom was a decent stab at making something new, and I think it partially side-stepped things by requiring users to provide their own value function. | ||
| david bennett (Dpoly)
New member Username: Dpoly Post Number: 5 Registered: 4-2017 |
Hard work is just fine, I've got lots of time, the question is would you use it (or even help in building it)? Compiling the language file into something that runs fast is slightly beyond elementary, I think. If the aim is more than a few thousand positions per second, some hard work and clever tech is required. Yes, I've given some thought to how to set sub-goals and I think there probably is no general way it can be done. Yes, I think Zillions probably has special code to deal with particular games (such as Chess) and it may well involve mobility and move types, but what is good for chess may well be bad for some other games (or even Chess variants like Losers). For me the answer is the Axiom route, opening up more parts of the game for an author to exert control, rather than leaving it to the generic AI. |