I cannot say for sure whether this is something that would interest you but I'm currently writing a library just for this reason...That is, developing games in Clojure. I am sort of giving emphasis to board games but I don't see why one could not build tetris or sudoku or monopoly etc etc...My goal is for the end-user to be able to express an entire game, show it up on screen and genetically train a 'brain' that learns how to play the game the game *on its own* (no human knowledge is required upfront) in an afternoon or 2 ! The lib is almost ready and I've coded chess and checkers already with it...It goes without saying that my main approach is purely functional (apart from the GUI)... However, I'm exposing 'fast' versions of some core functions (that deal with native java arrays instead of clojure vectors) just in case a consumer wants them (i am advising against that though)...if you want to have a look just search for "Clondie24" on github...
Jim ps: my chess implementation is just over 120-130 lines of code and checkers is even less so in a sense I feel like I've succeeded in what I was trying to accomplish... the moving rules of each game are completely de-complected form the actual game (coded in core.logic) which means that at least for chess, calculating how a piece should move is simply a hash-map lookup (super-fast)...the only calculation needed when you actually play is walking the move to check if it collides with anything...Traversing the tree of moves is done with a fork-join based minimax implementation using reducers... Yes it is naive (exhaustive search - no heuristics), but because it is parallel I can get to level 4 in less than 8-9 seconds and level 6 in less than 40 seconds...These are not generally reasonable timings if you want to do evolutionary training but I plan to train on a cluster rather than a single machine.... On Tue, Oct 30, 2012 at 11:41 AM, nicolas.o...@gmail.com < nicolas.o...@gmail.com> wrote: > The usual approach to this kind of things is to have a Functional > representation of the world, that contains the game logic. To have > pure functions that modifies the world with the time and inputs of > players. > And everytime you want to render a frame to call a render function > that does all the work. > > It is not clear whether you can have maximal performance with this > approach, in Clojure, on the JVM, but you can surely do something > decent. > > This kind of appraoch is used in How To Design Program, v. 2. This > link shows the idea in Racket (another Lisp variant) > but it could give idea on how to do that in Clojure: > > http://docs.racket-lang.org/teachpack/2htdpuniverse.html > > They also did a free book: > http://world.cs.brown.edu/ > > As a rule of thumb, the idea with FP is always to pull out effects > towards the spine of the program and keep the remainder pure. (This > is, of course, not a law and should be adapted to practice) > Here instead of mixing your game logic and your rendering, which put > effects everywhere, you work only on pure data and at the very top you > use your data to draw a world. > > -- > 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 > -- 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
