Hi, thanks for your work! I’m currently evaluating options for a small game project and would appreciate some additional information to help in my decision-making: a. Comparison of GDL vs. libGDX: It would be great to have a section outlining the advantages and disadvantages of using GDL compared to libGDX. b. Details on Feature x.x: Can you include information on what problem feature x.x solves? Examples demonstrating the use of this feature, with and without it, would be very helpful.

Very much appreciate your question! I lost the big picture a bit after cleaning up the code so much. Basically GDL developed as a layer between libgdx and https://github.com/damn/Cyber-Dungeon-Quest. I just thought about it and actually it is difficult to exactly point out the purpose of the library because it does 3 things (maybe more). I will have to think about this more and write it down after some days. 1, Some namespaces just expose a clojure API for some libgdx classes (for example gdl.math.vector for using com.badlogic.gdx.math.Vector2 with clojure [x y] vectors.) You can use those libs in your projects as a helper for working with libgdx, they do not have any state (only gdl.app sets up a state atom to hold the whole game context, which you do not have to use). I would also appreciate if more people would contribute to expanding the libgdx clojure API. This should probably be a separate library. Although libgdx has 1000+ classes so a complete wrapper would be insane! But we could get there bit by bit on a as-needed base. * Then there is gdl.app which sets up some state: loads sounds,textures, sets up gui and world views for rendering in world coordinates, provides the drawer object to abstract away from rendering details * Some extra functionality which I developed like gdl.graphics.animation which just provides a immutable data structure for animations, or http://gdl.dev which provides a refresh-loop integrated with the libgdx application lifecycle. (For example you can press the close button on the libgdx app and it will reload all namespaces without restarting the jvm ) Oh and the simple-test you can start with lein dev.

Oh and 'x.x' is just a component-system, basically multimethods which dispatch on keywords instead of typed objects. It is mainly used in the action RPG for the entities to give behaviour to plain maps. Its usage in gdl will be removed soon as it is not necessary.

Thanks, so if I decide to go with libgdx, it is better to use GDL and extend the API, good to know. And about removal of x.x in GDL - does this mean that GDL as a framework will not be entity-based? I have no experience with larger game frameworks where this is used, so the added value is a bit lost on me...

It is not really a proper framework, see it as just some helper libraries for libgdx. The 'entities' I am referring to are the specific world creatures,projectiles,etc. in my action RPG which has nothing to do with gdl.

I was thinking about x.x… I took it that you want to get the entity-component based system into the clojure game development. Until now, I’ve approached the state by updating one big global atom - I suppose point of x.x is makes this less awkward.

The point is what if you have an entity with skills, animation, movement, etc. And want to call update on each of those components. How do you structure this? x.x basically is just multimethods (defsystem) and defcomponent dispatched on a keyword so the entity can be a plain clojure map. Example here: https://github.com/damn/Cyber-Dungeon-Quest/blob/master/src/game/components/animation.clj In this way in comparison with protocols I don't need to create defrecords or deftypes and just have a map with :animation

Here I have an entity which just plays an animation at a point and deletes it afterwards, it's just a plain map! https://github.com/damn/Cyber-Dungeon-Quest/blob/master/src/game/entities/audiovisual.clj

But this is not part of GDL so you can structure however you like