First of all, thanks all of you for your helpful and often enlightening
comments....
On 13/06/12 08:13, Tassilo Horn wrote:
But probably that's not a good approach. When mutating the positions in
a move, there's no way back. If everything was immutable, i.e.,
updatePosition would return a new piece with different coords (as vector
or map), then your game engine could try abritrary many moves (creating
new worlds/game boards) ahead of time to judge what moves lead to
success, and then perform the best (or a good) one, i.e., alter the ref
representing the current board with the board where one piece has moved.
Now, you can't plan because when trying out a move, you've already
changed the world.
Yes indeed , I thought about the issue you're describing and I decided
to resolve it by using the Command design pattern...In other words,
moves are also records that satisfy the Command protocol which says
there should exist an "execute" and an "undo" method in all
implementors...that way, each move knows how to execute itself but also
how to undo itself and return to the starting position...As you said, I
will need a way to try-out moves during the minimax/alpha-beta recursion
in order to choose the best leaf node...However changing a piece's
position does not 'change the world' but rather builds a brand new one
every time by looking at the pieces' positions...ok as an implementation
detail I've got an atom holding the current-board and I'm resetting it
after every move. I'm also keeping a history of every new state of the
board (conj-ing it in a different vector atom via a watch) for debugging
later on....that mutation inside piece is the only non-functional
detail...everything else I am indeed returning new boards, new pieces
(promotion, death etc)...
If convenience of calling into your code from Java is important, you
might want to investigate definterface -- it accepts type hints for
parameters and return values (attached to the method name in the
latter case) and it actually promises to create an interface.
Noted.... :-)
Not really -- only primitive type hints actually prevent the function
from accepting a non-matching argument:
Ok I did not know that either!!!! if non-primitive type-hints do NOT
prevent non-matching arguments then how is the compiler able to optimize
them? I thought the whole point with type-hints was to let the compiler
know what's coming in a function. If that is not restrictive then what
is the point? my precondition is back anyway cos I did not need the type
hints after all!
Thanks a million guys...
Jim
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
