In the game I'm writing, state is held in a single var *state*.
Actions are reified and represented by maps. So I have a single
function
(defmulti execute :Action)
that operates on *state* and returns a new state object (state is
immutable). So to execute a sequence of actions would look like this:
(defn execute-sequence
  [actions]
    (reduce
      #(binding [*state* %1] (execute %2))
      *state*
      actions))

The advantage of this approach is that running multiple games at the
same time is absolutely trivial, because bindings are thread-local.

I doubt there would be significant overhead as a result of operating
on refs. Since there won't be any contention, every transactions is
guaranteed to work the first time you try it. But the usual rule of
performance optimization applies, i.e., measure.



On Oct 19, 4:38 pm, Adam Jones <[EMAIL PROTECTED]> wrote:
> I'm starting up work again on my Clojure-based game. Up until this
> point I've been doing things the "dirty" way by re-defing a bunch of
> global variables and/or storing the values in the Java objects I need
> to use to get access to the game framework.
>
> This approach is pretty unwieldy, and means I miss out on a lot of the
> cool things Clojure has to offer. So, I need to figure out how to
> handle state from within Clojure. The two ideas that I think will work
> are:
>
> 1. Store the game world as a var, and have the game structured as a
> function from the game world to the game world. Since I need to pass
> control back to Java to handle a lot of the details this would require
> me to store the game world in Java between updates.
>
> 2. Store the game world as a ref and use the facilities of that to
> modify the game state on updates. This seems cleaner in that it can
> all be handled without resorting to Java for intermediary storage. I
> am concerned that using the STM system would add too much performance
> overhead.
>
> I guess what this all comes down to is, between vars and refs, which
> one is the better choice for a program that I don't think will really
> need multithreading?
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to