Re: Suggestions on handling state for a game...
I'm still learning Clojure myself, but I've had some good luck using Rich's Ant Colony demo source as a basis for a simple game I am making. I'm not sure how well it follows what might become "best practices" for clojure game programming, but it has helped me overcome some of the initial hurdles of which you are speaking, allowing me to get things up and running. http://clojure.googlegroups.com/web/ants.clj -Matt On Oct 19, 5: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 -~--~~~~--~~--~--~---
Re: Suggestions on handling state for a game...
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 -~--~~~~--~~--~--~---
Re: Suggestions on handling state for a game...
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 -~--~~~~--~~--~--~---
Suggestions on handling state for a game...
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 -~--~~~~--~~--~--~---
