-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 this is my opinion as well: adding a layer of abstraction at a later point in time is much more difficult than removing one that is just delegating calls, so it often pays off to add one in the beginning just in case. i decided to just skip that because everything is going to be a polygon, even lines and circles can be represented as polygons.
i did what you suggested anyway. Am 31.10.2011 20:03, schrieb Timothy Baldridge: > As far as the mutable state goes, yes, that's probably a better > route, at least for a simple game. However I would recommend > against "everything is a polygon" route. Once again, for a simple > game, this may be fine, but you're now making an assumption: > "everything is a polygon". What if you want a simple laser > point-to-point entity? What if you want a planet that is > represented by a circle? What if you want your ship to be a > different color than the asteroids? By implementing IRender , you get two side effects: > > 1) you can now de-couple the presentation of the object, from the > code that presents it 2) you can have very complex models (multiple > polygons and colors) without having complex render code 3) you can > have entities represented by bitmaps, polygons, circles, arcs, 3d > meshes, etc. > > This is what Clojure excels at...de-coupling, or as Rich put it in > his recent talk "Simple made Easy": don't assume things about your > code. Don't assume that all models will always fit into the concept > of a polygon...don't assume that you'll always want to represent > your models via Java2D. > > Now, I'm not saying that your idea is bad for a simple game...but > for a larger project you may run into problems with this approach. > > If you want a good way to think about this, I'd recommend trying > to design the engine to run on both Clojure and ClojureScript. Have > it support Java2D, SVG and Canvas front ends...even if you don't > implement anything but the JVM version, if you can at least show > that your engine would work on these other platforms without heavy > modifications (massive kodos if you can do this without any > modifications to the core engine at all) then I would say you have > reached a "higher plane of understanding" in when it comes to > Clojure. > > Timothy > > > > On Mon, Oct 31, 2011 at 1:42 PM, Dennis Haupt > <d.haup...@googlemail.com> wrote: no need for "IRender" since > everything has a java.awt.polygon. i just draw it. in a sense, the > polygon is my IRender and it's data is the implementation. > > i was thinking about using a simple type (:asteroid, :ship, > :bullet) for each entity and pick an "advance"-function (input = > complete old game state + one specific entity, output = new entity) > depending on it. -> {:asteroid advance-asteroid :ship > advance-ship} > > i'd like to avoid mutable states as much as possible which means > there will be one atom or agent for the whole world and a > bufferedimage. other than that, i'd like to stay purely > functional. > > Am 31.10.2011 19:03, schrieb Timothy Baldridge: >>>>> In the OOP languages, entity systems seem to be all the >>>>> rage. I suggest stealing ideas from there if you can. >>>> >>>> >>>> In this same vein, I'd recommend thinking about the >>>> following approach: >>>> >>>> First, read up on reify and protocols. Next, create protocols >>>> for the main areas of your engine. Perhaps start with IRender >>>> and IPhysicalEntity >>>> >>>> (defprotocol IRender (render [this])) >>>> >>>> (defprotocol IPhysicalEntity (update-position [this >>>> timespan])) >>>> >>>> >>>> >>>> then for the user ship, you can do something as simple as: >>>> >>>> (defn new-ship [x y] (let [pos (atom {:x x :y y})] (reify >>>> IRender (render [this] (render-ship-model pos)) >>>> IPhysicalEntity (update-position [this timespan] (swap! pos >>>> #(hash-map :x (inc (:x %)) :y (:y %))))))) >>>> >>>> there's bound to be errors in the above code, but you get >>>> the point. The thing I love about the above example is that >>>> we've completely abstracted away the parts of this engine. We >>>> can have entities that implement different protocols, we can >>>> have a separate data structure for each and every entity, >>>> depending on its needs, and everything is abstracted nicely. >>>> Static objects can just implement IRender, and invisible >>>> objects can implement IPhysicalEntity. Extend this to >>>> implement ICollideable (for collision detection), and you >>>> have the makings of a very extensible system. >>>> >>>> Timothy >>>> > > >> >> -- 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 > > > - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOrvt3AAoJENRtux+h35aGpaUP+wRIRAEckRC/QISuwCUzeYm8 p4JBcV5TXmfjRR7bgeQ6yM4mMxkXveUOD/Na+CFAUeUwgTqsVO9fjMgIqtQTtiIU l8bnMluz+61p/Mpbq5yLONaYqmWLpXrKYhgKqiTPojnp4SDwIN0gKYSOYwskoJwJ 3yYLc46j0bY8c4hFS00U9NhnQyAZNx6Vi5RhYRvdKNLLWJ1n3l4xODLxeOh9WO4V Xbzi5XOe7j8eUVoV0Vvzgyi8kgdgq4LMpH4Yd04lmBij8reVuzicLxpT5HTsqlAB zCzxVsKyT/3drJlQv+wrFDc/LiHyjVTg+8/7jH4cP7bpqq5Rzy3UwMB918pGRjF/ D2yfPAsaryjxdFQcbozD4mlxIYOKk2speWmSPkjzlNrpnbVD+hg5H+m/rwUHT7Xc Z8gkmUwp6OKSLf47Twtel8ZQYap9WFSAeKp8nlMXXrK81pfwS5gLN2p7dfvu1saC AWQKwjRW892Ze4SLgpRJu/pq12/kUVLhusx1txY3qah3fj+mDOl0lyiAeZwo4yvp VjsAO32YXxwfXah7715EwZPgmZzvvZB7dMQ+zQTMqC9sfKmHdjNqJVJxQlsX4JD8 cKqqPWxkS3U34l+2AIQPEFM97RmNyj145vzDI0fUfN1vPMXIqGRvZ7U9vLDYaCqE OOBeHzfxS8xl8rMPxYOj =4+MB -----END PGP SIGNATURE----- -- 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