-----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
