Hmm, I posted replies to the previous posters but I might have sent
them directly.  Apologies.  Thanks everyone for the replies, in terms
of the game loop itself, it is more or less dictated by using
processing, so basically there're callbacks for mouse events and for
re-drawing the screen so that's taken care of.

In terms of the data itself, I was a bit wary of using the ID approach
instead of a big massive data structure with everything in it.  I
somehow felt this was making things mutable in a way, but I am
convinced by the replies.  In terms of code elegance, I overlooked how
elegant update-in can be, as opposed to assoc-in, and using a set in
conjunction with judicious structuring of the data, as Meikel and Jeff
suggested, will definitely make things far far more elegant.

Thanks for the replies, this is a great group!

On Jun 2, 10:10 am, Jeff Rose <ros...@gmail.com> wrote:
> I think the type of data structures you use will depend on how you
> need to access the data.  For a GUI it's nice to be able to lookup a
> unit by ID, for example when it's clicked on, so I would probably
> store all units in a map by ID, and then have a separate location to
> ID map as you described.  They could be together in an atom, or
> separate in refs if you want more concurrency.  Using immutable data
> structures you just have to get used to creating new versions every
> time you modify data, but using functions like update-in and assoc-in
> you can probably get at your data pretty easily.  Create a couple
> functions to handle moving location, updating properties, etc., and
> you might find that it isn't ugliness that you are hiding :-)
>
> On Jun 1, 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

Reply via email to