I agree with what Laurent said about clojuredev, I've been having great success using it myself, for my clojure/slick creations. My first project was converting Kevin Glass's platformer example over to clojure which gave me a chance to learn slick and Clojure all in one go! Unfortunately, the code I wrote for that is getting to be quite out of date now and probably doesn't work with the latest clojure, but I can at least offer some input based on my experience.
The platformer example is based on a tile grid with some fancy phys2d stuff thrown in for collision detection. For grid storage I started with a vector of vectors, and like you, which I too found far too cumbersome. So I ditched it and decided to go with a sorted map of coordinates to tiles (from the suggestion made in your linked thread actually). Although I'm still not sure this is going to be a "best practice" in clojure grids, it worked really well for me, simplifying access to grid immensely. In your code, moving over to a map would probably reduce the number of functions involved in your matrix generation phase. Also, in order to reduce passing around refs to collections for all the functions, I declared things like the player and the screen in the game's namespace and then later defined them during the game's init stage. Still not completely ok with that solution, but I think it's OK within the context of a slick game. For me the import count reduced as the game grew and I separated it into various files, so I wouldn't worry about that too much. Personally, I've always been a fan of explicit imports so I know what's going on when I reference a class name :) -Matt On Feb 9, 9:14 am, phtrivier <phtriv...@gmail.com> wrote: > Hi everyone > > first of all, this is my first post, so if I ask FAQs or deserve to > RTFM, please tell me. > > I am learning clojure, and trying to adapt some game code written in a > Java framework called Slick. After a couple of beginner's mistake (the > kind you do to learn ;) ), I got a working convestion of a Scoller > example. Still, there are some things that I don't find very elegant, > or where I'm pretty sure to be reinventing some wheel. > > Code is here : > > http://tinyurl.com/dj4l9z > or > git://github.com/phtrivier/clj-slick-tank.git > > * The game is tile-based. I need to build up a collision map ("can the > tank walk on cell [3,2] ?"). Java does it with a two-dimensional array > of booleans. From discussion here > :http://groups.google.com/group/clojure/browse_thread/thread/5eb78c620... > , I choosed to use a vector of vector (i probably should'nt have, but > that's another point). I wrote this : > > (defn blocked? > "Is a position blocked in the screen?" > [screen x y] > (let [i (int x) > j (int y)] > (true? (get (get (screen :blocked) i) j)))) > > (defn make-row-generator > [cell-generator w] > (fn [i] > (vec (map (fn [j] (cell-generator i j)) > (range 0 w))))) > > (defn make-matrix > [w h cell-generator] > (vec (map (make-row-generator cell-generator w) > (range 0 h)))) > > (defn make-collision-map > "Builds a double dimensioned array telling > whether a cell is blocked" > [m w h] > (make-matrix > w h > (fn [i j] > (let [tileId (.getTileId m i j 0)] > (let [res > (Boolean/parseBoolean > (.getTileProperty m tileId "blocked" "false"))] > res > ))))) > > (the 'm' is a slick-specific stucture that holds the tile map). > Am I duplicating some existing library to build matrices ? Is there a > cleaner way to do it ? > > * In a method I check for collisions : > > ;; Movement > (defn try-move > "Try and move a player in the screen given a direction. > Returns a list with the moved player, and a > boolean indicating whether the move was successfull. > " > [player screen dx dy] > (let [new_x (+ (player :x) dx) > new_y (+ (player :y) dy)] > > (let [bxy (blocked? screen new_x new_y) > bx (blocked? screen new_x (player :y)) > by (blocked? screen (player :x) new_y)] > (if bxy > (if bx > (if by > [player, false] > [(assoc player :y new_y), true]) > [(assoc player :x new_x), true]) > [(assoc player :x new_x :y new_y), true])))) > > Will i get used to the nested 'if' blocks someday ? Any way to write > the equivalent of a switch case here, if only to improve > readibility ? > > * Finally, my code starts with a rather ugly > > (ns tank > (:import (org.newdawn.slick Animation > AppGameContainer > BasicGame > GameContainer > Graphics > Input > SlickException > SpriteSheet) > (org.newdawn.slick.tiled TiledMap) > (org.newdawn.slick.util Log))) > > I know there is no way to import org.newdawn.slick.* (as discussed > here :http://groups.google.com/group/clojure/browse_thread/thread/fa00a0ff4... > ). What do you do in programs that need huge list of imports ? I'm > kinda spoiled by the Eclipse way of doing this, which is roughly : > import everything, forget about it, and let you IDE clear up the list. > And at least for development part it make things easier. If I hadn't > had the exact list of import to copy paste in this case, I would > probably have gone bored and depressed by the second class to import > manually (lazyness is not only for evaluation ;) ) > > Thanks for any ideas, sorry if post is too long / newbie-like. > > Cheers > PH --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
