Hmm, interesting, but games usually involve much state and changes to keep up their worlds alive.. how do you abstract over this? For example, if you need to move something, then surely you will call for a change.. right inside the user code that happens all the time.. isn't it so? Just interested in how do you develop the functional philosophy to a really usable extent.. I cannot imagine how to avoid changing Vector3f elements at runtime.. or maybe you just pass the whole changed app-state to each new cycle?
As far as I see, Jonathan and I, too create the wrappers as a side-effect of a personal project. I just think that maybe it is possible to factor out and assemble the code to a separate library and if you need something in your project, you implement it straight to the library and commit. Of course that would require a kind of coordination like never before, but it is a real FTW and is prone to benifits like finding something you wanted to have already being implemented by someone! четверг, 2 мая 2013 г., 2:14:36 UTC+4 пользователь James Reeves написал: > > On 1 May 2013 21:08, Alex Fowler <alex.m...@gmail.com <javascript:>>wrote: > >> So, inspired by the latest talks with locals, I propose starting a >> collective initiative on creating a full-scale wrapper for JME3. >> >> Actually, I am starting to write my Clojure project with JME3 and I feel >> like in a desperate need for a clojuric wrapper. So I started implementing >> wrappers for Material, Texture, Geometry and so on.. but I think that that >> code would be rather universal and there is no point for it to belong to a >> personal project. So I think that we might start a community library >> project on this with those who is interested. Besides that, I think that I >> am a rather newb in Clojure and if I do that on my own, I will not do it as >> good as possible :D Is somebody interested in that? >> > > I have a bunch of code for a game I'm working on, but I've taken a > slightly different approach to the problem than other people seem to have > so far. > > When you develop in a functional language like Clojure, you typically want > to quarantine all behaviour related to I/O, and avoid touching any mutable > values directly. In Ring, for instance, we limit the interaction with the > underlying servlet classes to a single function: the adapter. > > For jME3, I've been pursuing a similar approach. Essentially I'm aiming > for this: > > (run-app (atom initial-app-data)) > > The only point of contact between the jME3 classes and the logic in > Clojure will be that single function. Everything else will happen through > modifying reference to a data structure. > > Right now I've got it working with geometries, textures, a simple HUD, > events, very limited physics, collisions, and I'm currently writing an > interface to NiftyGUI (which isn't easy, as it's not very well designed). > > The work I've done on this so far is part of a game, but could potentially > be factored out. Currently it's very much a work in progress, and I expect > it to take several months before I have anything useful outside of my > use-case. > > - James > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
