I have a question if you don't mind. I don't know clojure at all, and I may be misreading things, but from this comment on your site:
Game development is fundamentally an art of state management. States are everywhere, and managing numerous unrelated systems in harmony is a challenging task. While Clojure’s immutability by default offers many advantages, it also introduces complexity. To handle the intricate state management required for game development, I had to create my own abstractions. Writing a custom DSL (domain-specific language) became a necessity, but it wasn’t easy.
And then this comment:
In Wizard Masters, all game data resides in a global game database—a single large hashmap. The fields referenced in the :what block (e.g., :pointer-locked?, :player/ground?) are keys in this global hashmap.
Please don't take this the wrong way but you've essentially just worked around clojures functional immutable style and invented global state in a hashmap, right?
This is a common idiom, and does not necessarily imply mutation.
Even in cases where you often do have mutation, say in databases, the benefits of a functional approach lie having pure functions between mutations rather than one big ball of Xs sometimes mutatingYs via Zs.
Here[0] is a wonderful talk that demonstrates this in practice.
Comments
I have a question if you don't mind. I don't know clojure at all, and I may be misreading things, but from this comment on your site:
And then this comment:
Please don't take this the wrong way but you've essentially just worked around clojures functional immutable style and invented global state in a hashmap, right?
This is a common idiom, and does not necessarily imply mutation.
Even in cases where you often do have mutation, say in databases, the benefits of a functional approach lie having pure functions between mutations rather than one big ball of Xs sometimes mutatingYs via Zs.
Here[0] is a wonderful talk that demonstrates this in practice.
0. https://youtu.be/vK1DazRK_a0?si=tmXr4NxDpZs48Omz