On Oct 20, 1:38 am, 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.
>
Hi Adam,
In such a scenario, I would probably go with option (2) that
you outlined. A good example is available here:
http://en.wikibooks.org/wiki/Clojure_Programming#Mutation_Facilities
The approach would be to define your game as a clojure
namespace with pure functions that take the entire game state
and return the update state. This will make the functions
and the game easier to test and debug. (corresponding to
the private functions update-role and delete-by-name in the
employee example above).
There can be a thin wrapper (your main application) that
manages state using refs and the library functions defined
above (corresponding to update-employee-role and
delete-employee-by-name in the employee example).
The main game loop can probably be built around the
wrapper functions that work with refs to handle state.
> 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?
Even if the program does not need multi-threading it
would be nicer (and easier) to go with refs and pure functions. The
reason being that it would be easier to test and debug
you code. Also, should a need come to make it multi-threaded
at a later date, that would be a trivial change in your code.
Note that the employee example doesn't use threads.
I think the re-defing approach is ok for simple experiments
on the REPL but would make programs more difficult to
maintain as they grow in size.
Performance should really be a problem with refs. A good
essay by Rich on Clojures approach to state is
http://clojure.org/state
Parth
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
