+1 for the pure functional approach with (tail)recursion :)

2011/6/1 Jonathan Fischer Friberg <odysso...@gmail.com>

> 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
>



-- 
László Török

Skype: laczoka2000
Twitter: @laczoka

-- 
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