I would say:

1. Make a function that, given a sequence of units and the next move,
returns an updated sequence given the move.

2. Make a recursive function that takes a sequence of units(*). Put in the
function body code for drawing the current board, and a query for the next
move (or something similar). Then recur using the function in 1, with the
move resulting from the query and the sequence from input (*).

(defn update-units [units move]
    ...)

(defn game [units]
   (print-board)
   (let [move (ask-user)]
      (recur (update-units units move))))

(game *start-position*)

Jonathan

On Wed, Jun 1, 2011 at 11:12 AM, yair <yair....@gmail.com> wrote:

> Hi,
>
> I am writing a little board game in clojure, mostly to educate myself
> about how to organise and implement a larger-scale program than my
> usual tiny little snippets.  The program has a central data structure
> of units which are placed on a map.  Each unit has some information
> like a name, movement points left, strength, and it's current location
> on a 2D hex-map.  Units are implemented as maps, so a unit can look
> like
> {:name "Fighter 1" :movement [3 12] :strength [4 4] :location [1 2]}.
> I hold the units in a map from locations to the sequence of units on
> that location.  There is an atom that holds this map, so any change to
> the data means basically creating a new map and resetting the atom.
>
> So, when a unit moves, for example, I need to remove it from the
> sequence at it's old location, and add it to the sequence in the new
> location, and change it's location value and it's movement points
> value.  In Java, this would be pretty straightforward.  But with
> immutable data structures, it is quite clunky.  I have thought of some
> alternatives:
>
> 1. Continue doing what I already am, perhaps write some functions that
> hide the "ugliness" and get on with it.
> 2. Give each unit object an ID and hold a map from location to unit
> IDs and from ID to the actual unit object, but that is kinda like
> making immutable objects all over again.
> 3. Using mutable data, like Java's lists, maps, etc.  This is of
> course extremely ugly and I would have to be strongly persuaded to go
> down this route.
>
> So, does anyone have any better ideas or is this type of program
> always going to have some impedance with FP and immutable data?
>
> Thanks
>
> --
> 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

Reply via email to