| Author |
Message |
Ingrid Lael (Ingridlael)
| | Posted on Tuesday, January 17, 2006 - 8:37 am: | |
Hi again.
I'm curious, what approach should I take?
A) create several piece types to distinguish subtle changes in the movement of pieces.
B) give the pieces attributes and let the move logic deal with it.
C) none of the above, but rather recalculate the attributes each time around.
If option A is to be taken I would change the types with a ?Helper, since the conditions are easily checked that way; the main drawback is that I can have around 49 combinations of this "attributes" (and hence, around 49 piece types), resulting in piece type "bloat".
The main question is: does the AI manage attributes or piece type changes better? does this even have an impact in the AI opponent quality? (my guess was that since the AI needs to work harder if these conditions are to be checked during move generation I could releive it from such a burden having a ?Helper do it, since ?Helpers are faster).
I recall reading something about the AI thrashing when attributes and partial moves were involved, though I cannot remember where.
Thanks for your time guys.
Cheers...
...Ingrid. |
Karl Scherer (Karl)
| | Posted on Saturday, January 21, 2006 - 5:59 am: | |
You call it yourself a piece type bloat,
so I would strongly suggest to use attributes,
because they have been designed to store attributes, as the name says.
I cannot see any processing advantage of having 49 piece types.
The main processing time of the AI is used for climbing up and down the search tree and calculating values for pieces.
Looking at the combing of the search tree,
I assume it does little matter whether the machine checks an attribute or a piece type.
Calculating the value of a piece depending on its
freedom of movement can only cost more if you have more piece types.
Independent of these considerations, I would not worry too much about what the AI does.
Rather try to code your program simple and clear
(some people still haven't heard about software engineering).
Cheers, Karl |
Ingrid Lael (Ingridlael)
| | Posted on Saturday, January 21, 2006 - 10:10 am: | |
Yup, simple and clear is nice.
On the other hand: if the freedom of movement is influenced by the pieces attributes, wouldn't it cost the same to have several piece types? I really don't know nothing about how Zillions deals with this sort of things, could someone clarify?
Anyway, I believe you're right and the 49 piece types are already gone (it just didn't feel right to have sooooo much informations duplication, cuz they all basically did the same). Thanks for the reply.
Cheers...
...Ingrid
PS: Karl: you use random players a lot in your solitary games (and I'm already using quite a few in my own) so I guess you're the one to ask: should I use fewer but more convoluted ones, or more but simpler? (I'm coding a two player game, so I'm kinda interested in the performance/AI-penalties in wich it may incurr; not something to loose sleep about, but it would be nice to have none of them). Of course, convoluted does not mean baroque and "unmantainable". |
Karl Scherer (Karl)
| | Posted on Sunday, January 22, 2006 - 4:00 am: | |
The moment you have a random (third) player
in a 2-player game, the Zillions system takes it not as a two-player game, but a 3-player game.
It is really very unfortunate that Zillions does not allow complex moves and we often have to use a random player as a stopgap.
I don't think there is a loss of performance by using the random player, I rather feel that the system has more problems of defining a goal
(before it hits a successful win-condition)
for the two main players because it has to
consider the winning chances for the third man, too.
The Zillions authors are really the ones who should answer this question..... |
Ingrid Lael (Ingridlael)
| | Posted on Sunday, January 22, 2006 - 4:47 am: | |
I see...
I agree, Zillions authors will (and should) have the final word on this matter. btw, where are you guys?
While we're at it: suppose my losing condition for both players is to have a certain dummy piece on a certain dummy position, if a random player, after White's turn, but before Black's, places such a piece in such a position, who's taken to be the winner?
Last one (for now ;)): if the random players have no win/loss/draw conditions, does the system still have to consider the winning chances of him too? (I remember a post by Karl about Zillions not evaluating positions for random players anymore). If such is the case (Zillions considers win chances for ? players), could something like:
(win-condition (?Helper) false)
(loss-condition (?Helper) false)
(draw-condition (?Helper) false)
help at all? (I'm kinda new to this Zillions thing altogether, so my knowledge on the internals of it are totally nil).
Thanks for the quick reply.
Cheers...
...Ingrid |
Karl Scherer (Karl)
| | Posted on Saturday, January 28, 2006 - 5:38 pm: | |
"While we're at it: suppose my losing condition for both players is to have a certain dummy piece on a certain dummy position, if a random player, after White's turn, but before Black's, places such a piece in such a position, who's taken to be the winner?"
That depends whom you made the owner of the piece.
If ?Rand is the owner, there will be no loss message. Otherwise the owner of the piece loses the game.
However, if you said "any-owner man" in your loss-condition I am not sure what the loss-message will be, but there will be one.
Try it out and tell us.
Anyhow, always program as unambiguour as possible,
anyone lookign at your code will thank you!
Therefor having a third (random) player and using "any-owner" in the win/loss condition is not a good idea to start with!
Karl |
Ingrid Lael (Ingridlael)
| | Posted on Sunday, January 29, 2006 - 5:05 pm: | |
OK, I see...
I totally agree, clarity is paramount. I'll try it out an tell you!
Cheers...
...Ingrid |
|