Heya, I'm the author of the article. I've been working on Kandria full time for close to two years now, and on-and-off for some years while I was doing my Master's at ETH. The engine it's running on, Trial, is a few years older still, and initially just started out of the good ole university boredom and curiosity. Games is how I got into programming when I was about 6, and that particular fever hasn't left me yet it seems, ha ha!<p>Kandria itself started as a "more serious" attempt at a game after I'd been making jam games with Trial for some years. I wanted to create something bigger, and had just finished playing through Celeste, so I just set out to replicate its mechanics in my own way. You can still find some demos of those very early days on my YouTube channel, if you're curious. In any case, the project went through several big changes until it turned into what it is now. During the pandemic in 2020 I finally decided to drop out of my Master's to pursue the project full time. At that point I also brought on a couple more people to help with the writing, art, and sound.<p>We're currently also running a Kickstarter to get us some extra funds for the project. It ends on Thursday 14th, 12:00 CEST, so there's not that much time left in it. If you'd like to support our work, please have a look: <a href="https://www.kickstarter.com/projects/shinmera/kandria" rel="nofollow">https://www.kickstarter.com/projects/shinmera/kandria</a>
The campaign page has a lot more details on the project and the team, if you're curious about that.<p>In the article I primarily cover the programming parts, giving a surface overview of the technologies involved and at least giving a brief hint at the methodology I employ to create games. I'm sure I've left out a lot of details that you might be curious about, so if you have any questions, please feel free to ask and I'll try my best to answer!
This is a nice write up.<p>The dark side is that they've put years into developing the core infrastructure to empower their Lisp game journey. Ideally that's all usable by others to "stand on the shoulders", so to speak, but that's always a challenge.<p>I honestly have never had to work on a "running image" of any consequence. I've never worked on anything more than a few thousand lines of code. I've never needed any kind of source level "step" debugging. The ability to redefine a function quickly, I just throw in some prints to figure something out.<p>Reloading the entire source file was always fast enough to now warrant hunting down any of the more interactive mechanisms available. This is all across using simple vi, or emacs, or even LispWorks.<p><pre><code> (defun l () (load "src.lisp"))
</code></pre>
Just save the file, and type that.<p>All that said, my current low level fantasy is something akin to Electron, only with Common Lisp. First class DOM, first class event hooks, into a CL runtime that you can deploy cross platform. Dunno if that exists or not.<p>I'm sure at some point my codebase will grow to the point where I would need to "level up" and become more intimate with SLIME, packages, system definitions, etc.<p>I've just not crossed that threshold yet.
>> One thing I do have to mention though is that the workflow in Lisp allows me to create these support libraries much faster than I can in other languages.<p>I'm at that stage in my lisp journey (~18 months) where i know enough to be dangerous to others around me, i.e. i'm still a lisp n00b but have completed a few lisp & scheme books and written enough projects that i feel fairly productive. BUT i haven't reached, never mind come out the other side of, the "trough of disillusionment" yet. So everything lisp is unreasonably tainted with a positive glow in my mind.<p>TL;DR i still think lisp is pretty awesome. It's my newest hammer and everything looks like a lisp-shaped nail these days. So i have to be deliberate and careful not to over-use lisp but it's totally changed how i write js for example. It's infected my brain.<p>Here's the thing - that workflow statement by the OP is a fair chunk of the attraction to lisp for me. Before lisp i "knew" what a REPL was - i've been using python since i switched wholesale from Perl in the 00's, i thought you couldn't teach me anything new about REPLs, even quasi-REPLs like Jupyter were entirely familiar and "basic" to me. If you're a lisper, you know i was wrong about that, if you're not a lisper you're probably wondering what's the big deal.<p>The other chunk - and i'm only really scratching the surface so far - has been macros. I think so far i prefer the non-hygenic type, but i haven't gone through Let over Lambda yet (although the book is on my bookshelf and is only 2 titles away from being started)<p>For me, lisp opened my eyes to a way of working that i just wish i could fully replicate in other languages. Lisp has made me re-appreciate python and js in different ways now.<p>If you want a really short version - Brett Victor's famous inventing on principle talk sums it up for me (he was using JS there, so there is hope...)
I'd really like to understand how live reloading works a bit better, especially when editing variables that some running thread depends upon. Is there an overall strategy here? Do I implement locking around variables that I intend to play with at runtime?