Live data from Hacker News

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

reader.tymoon.eu

21–30 of 36 posts

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

#21
post #14

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?

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.

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

#22
post #18
post #9

Earlier quoted context omitted.

The Lisp instinct is to make a change in a file and immediately hit C-c C-c in Emacs, at which point the change goes live in the system - no matter if it's a variable or a function that you have changed or something else. You don't need to reload the full module like in BEAM languages like Erlang or Elixir, you can modify a single function or a form without the need to make a version upgrade to the processes running…

Version upgrades are not needed on BEAM anymore than they are in Lisp, you can just reload a module and code will start using the new version.

TIL, that's a big thing! When was that change made?

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

#23
post #18

Earlier quoted context omitted.

Version upgrades are not needed on BEAM anymore than they are in Lisp, you can just reload a module and code will start using the new version.

TIL, that's a big thing! When was that change made?

I don't think it's recent, as far as I know. Versioning, appup / relup, etc. are really for upgrading production deployments live, when you need special instructions to pause processes or update their internal state before loading new code. In development, you can ignore all that and just reload modules directly. e.g. with "r" in the Elixir REPL.

Once that's done any external call (`MyModule.add(1,2)`) will go to the new version of the code, while local calls (`add(1,2)`) stay on the same version.

The Phoenix web framework will also auto-reload any module that has changed on disk when handling a web request in dev mode.

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

#24
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!

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.

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: https://www.kickstarter.com/projects/shinmera/kandria The campaign page has a lot more details on the project and the team, if you're curious about that.

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!

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

#25

This is a nice write up. 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. 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 kin…

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

The other direction is https://nyxt.atlas.engineer/ , which is a CL-driven browser. It's presented as a general-purpose browser, but you can also treat it as a standalone CL with a browser front-end, and I think that's the developer's long-term goal -- a bit like how emacs is a lisp with a text editor front-end.

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

#26

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…

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.

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

#27
post #26

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…

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.

By being lucky enough to have savings, and having a room at my parents' house that doesn't require any rent payments. Without those, it definitely wouldn't have been possible.

Recently I've also received some grants, namely the Pro Helvetia interactive media grant, and the Poland Digital Dragons Accelerator. Both of those only offset a part of the money I had already personally invested though, and the Kickstarter barely makes a dent in anything.

Selling games is such a gamble, too. If the stats are to be believed, only about 15% of games on Steam recoup their investment, let alone making profit. For the next project's funding, I'm going to try and look at some other source like Patreon, to at least offset my own measly costs so I can spend longer in pre-production.

Making games is just really expensive, and any funding source is heavily fought over, or comes with huge caveats attached. I don't think I have this figured out yet either, so all I can say is best of luck!

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

#28

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…

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?

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

#29
post #28

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…

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?

I'm sure Aseprite could be further optimised to press down the constant factor, but it is performing a rect packing algorithm among other things, which is an NP-hard problem.

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

#30
post #14

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?

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…

[deleted]
Post reply on HN