The point about lack of tooling for Babylon.JS is interesting: a lot of times I see people wanting to release games but spending most of the time building tools... sometimes all of the time. It is a delicate balance!
Congratulations on releasing! Very cool project.
Ah we all know what we really want to do - build tools!
A game just makes the journey a tad more interesting.
... this is how you end up making three skeletons of a game engine and never making that game itself, before running out of childhood and having to switch to doing webshit for a living to pay for mortgage.
Ask me how I know.
I’m very glad that you liked it!
I’m a aspiring gamedev and my focus so far has been working bottom up with C and friends. But I do love Lisp and especially Clojure, I’m really hopeful now that Jank is gonna be a full time project this year.
It looks fantastic, but I can only play if down on mouse is up on view.
normal: move joystick up = move eyes up
inverted: move joystick up = push top of head down
This is a fun little romp. Very Quake-esque in terms of mechanics (though the floaty jumps have more of a Tribes feel). Excellent job putting it all together in a Lisp... even if that Lisp is Clojure! I like to think of Lisp as a mind-tool for creatives, a way to turn thoughts into code so quickly it can keep up with the highly iterative creative process for other endeavors and enhance the reach of people working in other digital media besides code. It's probably less relevant in that capacity today than it was in the past, though.
> 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?
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.
Cool game, fast. Someone dominated me for 4 mins and then I decided to switch to Fortnite :)
Same here :(
I'm guessing this wasn't tested (at all?) in Firefox? That's unfortunate.
Edit: I see you mention it in your blog post. I enjoyed it just as much!
Things actual EV drivers rarely worry about: Range.
Things that terrify non-Lisp programmers about Lisp: Parentheses.
Things actual Lisp programmers rarely worry about: Parentheses.
But it's 2025, it was enough to downvote and ignore the GP comment... Even responding with a dismissive https://www.thejach.com/imgs/lisp_parens.png is too much in current year. Another comment mentions paredit/parinfer, I'm not exactly masochistic but I hate tools that automatically type more than indentation for me so I don't use them, but I also basically never think about counting parens.
Instead of (qux (baz (bar (foo x)))) use other tools:
- Big picture: is this code overly procedural? If so, is it possible to make it declarative and functional?
- Line-level picture: one of the thread macros, functional composition, etc. will make this more readable. For example: (-> x foo bar baz qux).
...you do know no s-expression editor makes you count or type those out manually, right? It's all handled by paredit or parinfer, unless you're a masochist.
It's just not something any lisper thinks about.
If you want to have closing parentheses on separate lines the code simply becomes to long.
I didn't understand this when I started writing Lisp, but that style has its advantages and is supported by the editors.
