Technical overview of Kandria, a game and game engine developed in Common Lisp

How have you funded yourself (prior to Kickstarter)?

I'm in a similar position to you (indie developer, working on my first project of size that I am polishing with intent to release). I haven't quite been able to square up a way to work on my game full time -- I suspect out of a lack of ingenuity or resourcefulness on my part. You seem to have solved this problem, though.

From the post:

> The same doesn't apply to the player sprite, as Aseprite takes minutes to compile the atlas for the nearly 1000 frames we have.

Why does compiling a sprite atlas for the player take 60ms/frame?

This project looks awesome! I really like art, and it's exceptionally cool that you're using Common Lisp. As someone that often gets lost in the engineering (aka "fun") aspects of building things, my one piece of advice would be to make sure you put enough energy into marketing your game to ensure it reaches as wide an audience as possible and none of your efforts go to waste. Looking on reddit, I see a lot of posts in r/lisp, which is cool, but I'd work towards building as much buzz as you can in the indie gaming community (little teaser videos, etc). I'd also consider posting on the Tigsource forums, as that's a good way to build roots in the indie community. Anyway, looking great, and best of luck with your launch!

What kind of software do you usually create this way?

> Reloading the entire source file was always fast enough

The point is that you might want to keep the state.

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

Have you checked out https://github.com/rabbibotton/clog ? I have only played with a couple of the tutorials, but it seems to be targetting something like that, albeit without an included browser.

Great write-up. Indeed, the journey with Lisp is an interesting one and what you have witnessed seems to parallel many others experiences.

What I found on my journey with Lisp:

- I learnt Emacs well and learnt the beauty of its codebase and the thoughtfulness put into the program. Its' levels of documentation and customisation and being a lisp machine in its own rights was an enlightening experience for me when designing my own software (i.e. document well, document in a standardised way, document thoughtfully (think of what the users would want to know) and providing customisability to end users (which to be honest, dynamic langauges like Lisp excel at because they are much better suited for runtime manipulation and optimisation

- The power of macros to change one's language. Now admittedly, this took some time to get a handle on. You kinda need to be proficient in Lisp before you start doing some super funky stuff and mould your language and program together into one (Ala PG's On Lisp). But having the ability to change the language at _compile_ time is simply, utterly, most imaginably amazing!

- Writing clearer code: Because Lisp has very little punctuation syntax (not to be confused with the syntax of certain special forms), you cannot hide behind boilerplate code as much and you end up having to face your own thoughts more directly in the code you write. It is tough going at the start (who would have thought a _simple_ language would actually be hard to program in well - basically the more complexity in a language, the more restriction to your expressiveness, the more simple a language, the more power to you to fully express yourself by combining orthogonal blocks...speaking generally here as sometimes complexity does help in other ways (e.g. see CLOS))

- Learning from the greats in Computer Science - there is so many good ideas and thoughts embedded into the lisps, that you inevitably learn a lot of good things by immersing yourself in the language and its history (of course over time)

And finally, 'Life Beyond Lisp'. I no longer program in Common Lisp as my main language because I do need some libraries that I cannot do without. But as you alluded in your post on writing better JS after Lisp, I too have significantly improved my programming and code clarity in these other languages, after learning Lisp. Of course, one day I hope to program exclusively in CLOS, but until that day, Swift remains my near friend (at least it has generic functions).

I can wholeheartedly recommend Common Lisp to anyone who has some spare time and curiosity to improve their skills in our profession of computer science. Also (and this is something Lispers don't seem to do that well), try other languages! Learn from them all in my humble opinion. Computer Science is a wonderful thing :)

p.s. Congrats to Kandria on their progress. Truly a wonderful team and their main author is a wonderful open-source lisper.

> it's totally changed how i write js for example

This may be a silly question. But could you give a couple examples of how you implement something in JS now vs. how you would have implemented it 18 months ago?

Could you expand on the REPL bit? Having worked with JS, Python and Elixir, they feel more or less the same. What’s Lisps have that these don’t?

Thanks for that. Are you able to tell us what books got you to where you are now? I've just started Emacs Lisp An Introduction as I'm wanting to dive right into Emacs (coming from a life-long Vimer), but I'd also want to expand to other Lisps.

I don’t believe the Common Lisp specification says anything about threads. For example here[1] is the relevant section of the SBCL manual. As you can see it’s quite low level. If you’re using those primitives then yes you’ll have to manage barriers, synchronization, use atomic operations, or otherwise maintain sanity. The REPL (or SWANK) thread is just another thread.

Edit: I should add that the usual pattern is Bordeaux threads or some other higher level thing.

[1] http://www.sbcl.org/manual/index.html#Threading

All of the contention issues that we've had for ages across all platforms exist in CL. Loading and compiling new code isn't any different than two separate threads calling setq on the same element at the same time.

The reality, though, is that the vast majority of the time when this is done, the system is idle. If you live update your server that's serving 1000 connections and isn't specifically coded to handle this potential event, then, for sure, there can be trouble.

But if you're hot reloading your dev server, with an idle connection, then you're likely to have fewer problems.

However, there's the potential impact of captured state that is not properly refreshed. For example, if you have some long running state that, say, captured a function via #'my-func, then that routine has, indeed, captured the pointer to the routine. But when you redefined it, the symbol (i.e. my-func) is now pointing to the new code, while your existing state is pointing to the old code. Any code that uses the symbol to call the routine will update automatically, but anything that does not, is stuck with stale data.

And that rock potentially sends different ripples through the still pond of your running image. Just something to be aware of.

It's a great feature, just need to be aware of what's going on when you do it. Most of the time, it's a non-issue.

With the threading model of most CL implementations, you really only need locking if you need to change two (or more) places and have the update appear atomic, or if you are doing a read/modify/write. But you would already need such infrastructure in place if you were going to modify them in you program as well.