132 comments

[ 3.1 ms ] story [ 216 ms ] thread
No questions today, but just wanted to pass huge congratulations your way. Getting to release is no small feat even when leaning on existing engines, and knowing how little was available in CL makes this day all the sweeter.

Also thanks for the SteamDeck support!

Thanks! Hope you enjoy playing it on the Deck! :)
This looks amazing! I'm guessing you may have answered these questions before somewhere so please point me to the information if so. I'd like to know what development environment you use (Emacs, SBCL and Slime?), what packages you used to create the graphics for the game, and what the game is compiled to. Thanks.
I use Emacs, Slime, SBCL, yes. Since it uses SBCL, game code is compiled to native machine code for each supported platform and architecture.

You can find more info on the dev process here: https://reader.tymoon.eu/article/413 And the source code for the engine, Trial, and the game, Kandria, are both on our GitHub under Shirakumo.

That's fascinating, thanks!
When you write a game for Steam or similar services, do you have to make a specific binary format or follow certain conventions? Or could you basically do anything, in any language, even if it ships with a VM? Could I write a game in Erlang, for example, as long as I have SDL bindings?
All that steam requires is a native executable to launch, and that you load their steamworks library and initialise it, which should be one or two FFI calls.
Hi. I’d be interested on how you feel using lisp impacted the development of the game and the final game structure. Would it be the “same” game if implemented in a more conventional approach? Thanks.
There's a lot of aspects that are extremely Lispy. The best example is our dialogue scripting language, Speechless: https://shirakumo.github.io/speechless

You can run arbitrary lisp snippets to form conditions, branching, and effects in the game. This makes integration and extension very easy, and I don't have to constantly extend some special purpose scripting API to expose new bits.

The heavy use of CLOS is another good example, and of course the interactive development. Shaders, assets, etc can be reloaded while the game is running, not to mention all game behaviour.

Very cool. Is any of this exposed at the user level in any way for modding/experimentation or is that just too unworkable in production? Also, curious if there was a toolchain reason for the lack of a Mac version or is it just too tiny of a market to bother?
Official modding support is coming as the second major post launch update.

Mac version isn't supported because I got tired of Apple constantly breaking things and making them way more difficult, while still having the worst documentation on the planet. I don't have it in me anymore to chase that.

But, if anyone else wants to fix things up, the engine and game are OSS.

This game looks super exciting! Unfortunately, I have a mac :<.

So, I install sbcl, installed quicklisp and then used quicklisp to install your game after cloning and cc'ing into your directory. It looks like your game would work if you (or someone) looked into why your "Harmony" sound engine isn't working (line 28-29 in your package.lisp file). I attempted to load from your github/Harmony directory and this is the error -

* (ql:quickload '(harmony cl-mixed-coreaudio)) To load "harmony": Load 1 ASDF system: harmony ; Loading "harmony" ............. debugger invoked on a LOAD-FOREIGN-LIBRARY-ERROR in thread #<THREAD "main thread" RUNNING {7008640253}>: Unable to load any of the alternatives: ("libmixed2.dylib" "libmixed.dylib" "mac-arm64-libmixed.dylib")

I tested the other audio implementations suggested as well and they don't work either. Is there a way to play this game without sound? That might fix the problem. I don't know how much I'm willing to dig into this, because cl-mixed is it's own library and it looks like it would start to become a rabbit hole.

It looks cool though!

The problem is most likely that I haven't updated the included binaries of libmixed in a while. Building that in itself shouldn't be difficult, but no, there's no way to compile or play without the sound library present at all.
This all looks great. I’ll save you the Apple agony and run a vm for this.
The million dollar question, if you had to do a similar game again, would you still pick CL?
I already have a concept for another game. It'll be more ambitious in some respects and less so in others. Of course I'm continuing to use CL.
I was originally a Kickstarter backer when the developer was advertising the game as intended to be open-sourced, but then open-source became a Kickstarter goal so I withdrew the backing.
The source code for the engine, Trial, and the game, Kandria, are both open and on our GitHub under Shirakumo.
That is great, now other developers have a chance to use Kandria as an example for their own projects!
I'm glad to hear that it's open source now. I specifically took issue with advertising that it would be open source before the Kickstarter, but then open-sourcing it became a Kickstarter "stretch goal" implying it would have remained closed if that funding goal wasn't reached. I was on board until that surprise.

Looking at the Kickstarter right now:

"Stretch Goal 3: Modding Support

This goal includes three things in specific:

The game source code will be publicly available! ... The code will be released under a license that prohibits using it for any commercial activities, and requires you to share-alike any modifications you make. The release will also not include any assets, so you'll still need a copy of the official game to play it."

My intention was always to make it available as open source. The stretch goal was there for the rest of the things and to provide some extra incentive.

The license for the code is zlib now, but the assets remain closed. I think that is a fair trade.

Are there any plans to support consoles (ps5, switch)?
I want to investigate Switch support more deeply this year, and we have a potential way to do it. However, consoles are difficult due to their restrictive nature, especially regarding JIT and other techniques like signals and interrupts, which are important for many Lisp implementations.
Congrats on shipping it!

I've been following the progress since I've been learning Common Lisp here and there over the past year or so.

Thank you! I hope you enjoy playing it!
It's looks amazing, congratulations!

I'd love to see the source code. Assuming this is not OSS, I wonder what's a good example of a code base, ideally one that is hackable and could be used for educational purposes?

The source code for the engine, Trial, and the game, Kandria, are both on our GitHub under Shirakumo. It's all zlib licensed.

The code base isn't great for learning though, I'd say. Game development usually does not leave the time to architect things neatly, rewrite large chunks, or document stuff deeply.

This is dope as heck. I used to contribute to the common lisp SDL2 bindings. Great to see a polished game on Steam written in Common Lisp!

Recently saw one in Haskell too. And there have been several in Javascript over the years.

Did you find you had to manually manage the GC? Did you take advantage of CLOS?

I had to do a little bit to avoid insane amounts of consing, but honestly not a lot. And the optimisations I just did after the fact, gradually.

I use CLOS a lot for everything. The event system is literally just an array of handlers and a generic function called HANDLE that takes the event object and the handler object, for instance.

The source code for the engine, Trial, and the game, Kandria, are both on our GitHub under Shirakumo.

Nice! Thanks for sharing!

Update Bought a copy, definitely my jam. Played on the steam deck, noticed that the first time I used an action (move, jump, attack) there was a noticeable pause/stutter but has been smooth as butter afterwards.

PS: are you able to talk about the steam integration? I assume it's a C or C++ library of sorts and fairly straight-forward to extend; curious if you plan on releasing to another platform if it's possible to keep similar "achievments."

Also, kudos on the accessibility settings; changing damage and game speed, etc! Nice.

Hmmm. I might have to take another look at optimisation for the deck, then.

Sure. I use the cl-steamworks library I wrote. https://shinmera.github.io/cl-steamworks/ Their API frankly sucks and getting the integration going was a big pain. However, if all you want is the minimum, like achievos, you can omit all of that and just do a couple C calls.

The engine has abstracted support for achievements and such integrations, so it is possible to integrate with other platforms, too, should we ever release on GOG or EGS.

I always wondered if CLOS multimethods would be particularly useful in gamedev - it feels like it would be most natural to model arbitrary and unpredictable interactions between many different entities. How common is multiple dispatch in practice in your codebase?
Which compiler did you use?

Did you generate an executable machine code image with it?

How are you drawing graphics with Lisp (SDL, DirectX, OpenGL, something else)?

SBCL. Yes. OpenGL, using GLFW for the context wrangling.
Congratulations! Ive been following development with your blog/yt for a bit, so Im excited to finally check it out.
Thanks, hope you have a good time with it!
Congratulations to the entire team from Shirakumo Games!

Developing and shipping a full-fledged video game requires a lot of hard work and dedication. And writing a custom game engine and tool chain at the same time is really a heroic feat. Hats off to everyone, especially to Shinmera!

I've been following this project for a long time and it's so exciting that it's finally been released! Anyone that likes Lisp and/or game development will find plenty of interesting things to study by looking through Shinmera's source code, videos, and articles. Here's a couple of papers that I like a lot:

Object Oriented Shader Composition Using CLOS https://raw.githubusercontent.com/Shinmera/talks/master/els2...

Shader Pipeline and Effect Encapsulation using CLOS https://raw.githubusercontent.com/Shinmera/talks/master/els2...

I've been tinkering with Emacs Lisp for a little bit. I notice some package authors use cl-* macros.. is it worth going in that direction?

...I just looked up where the macros are defined, this is fascinating:

> ;; This package was written by Dave Gillespie; it is a complete

> ;; rewrite of Cesar Quiroz's original cl.el package of December 1986.

Congrats to the Sandra team, sorry about the off topic.

cl-lib is practically indispensable in modern emacs lisp programming. It can be pretty annoying to write some patterns without cl-loop, for instance, which like the real loop macro in CL is stupidly powerful (think, DSL for describing loops).

I'm not sure what you mean by "that direction," but if it implies doing CL, writing emacs lisp won't get you there, even if it might give you a head start from cl-lib, eieio, and general lisp ideas.

Hey, why does it matter if it's made in 'common lisp' ?
Common Lisp is pretty cool, and to my knowledge this is the first major game title using it that is actually released.
Maybe not common lisp, but look up crash bandicoot by naughty dog software for the playstation.

That was an exclusive playstation title, probably the third biggest title in terms of sales on the playstation, and it was written in Lisp.

To my knowledge, Naughty Dog have never fully implemented a game in a Lisp. They used it and custom languages written in Racket as scripting and automation tools.

The game posted here appears to be written in Common Lisp from the engine up.

The first few Jak & Daxter games were written from the ground up in GOAL.
Though all their games written in GOOL or GOAL had their development environments implemented in Common Lisp.
Yeah I know about GOAL and OpenGOAL and all that.
I have a private conspiracy theory that one of the reasons for the recent remaster of The Last of Us is to move all of Naughty Dog's go-forward IP off a Lisp-based workflow. Through at least The Last of Us (2013), ND had been still sneaking in Lisp through the back door: while the engine was in C++, a toolchain in Racket would generate all the entity component types as well as data for various animations, etc. I think there's been a shift in developer talent at ND in the past few years, and Druckmann wants to get rid of all the Racket stuff (because it's hard to find maintainers for it) and stick with a standard C++ workflow.

All of which makes Kandria even more refreshingly welcome.

I'd say that to the end-user it doesn't matter (which is why it's not mentioned on the linked store page), but to the HN crowd it's interesting because lisp is a nifty hacker topic and seeing someone manage to write a game in it is pretty cool.

(It's probably more interesting than all the "X, a clone of Y but in Rust" posts, at least.)

if i've learned anything from HN, it is that the language you write something in is the most important thing you can say about it.
This is an unnecessarily cynical comment, IMO. The title already establishes the value prop of the project as a "Show" entry; it's an action RPG, i.e. game. It's not "I made a clone of a C tool but in Rust" where there is no actual value prop.

It's a bonus that it's written in something a bit more interesting than your average game.

I was going to comment controls looked like the mega hit "Celeste" and then I found this comment on HN, from 6 months ago, by the dev of Kandria:

"I wanted to create something bigger, and had just finished playing through Celeste"

Ah that explains it! Congrats on shipping on Steam!

Yeah, it started out with just Celeste mechanics before everything else happened.

Thanks!

Reminds me of Knytt.

Is it more like Knytt than Celeste ? I didn't Celeste.

It definitely has Knytt influences in there and features a lot of exploration, but there are a lot more platforming challenges especially in the later sections.

There are accessibility options that let you toggle infinite dashes on and off at any time, which lets you bypass most of the challenges pretty easily should you get frustrated.

Been enjoying your open source Lisp libraries, congrats on releasing the game! I'll check it out.
Thanks! I hope you have a good time with it.
Wow, looks awesome! I love these indie sidescrollers.

Will it be available for Linux, maybe on GOG?

It's already available for GOG. You can get it on Steam, Itch, or on our website. All versions are DRM free.
Hm, I can't find it on GOG. Did you mean for Linux? The Itch site says Linux is available, so I'll get it there or on your website.

Thanks!

Sorry, my brain is fried. It's already available for Linux on itch and Steam is what I meant to say.
It even works on Parallels! Goodbye productivity...
Forgive me if this is a dumb question, if I install this through Steam can I hack on it?
Not a dumb question at all.

You need a full copy of the game from Steam or somewhere else to hack the game. You can get the source code here: https://github.com/shirakumo/kandria and hack on it that way.

You can also just look at the asset files in the install folder and mess around with those. Nothing's encrypted.

Great! I just bought it. I'm not really a gamer, I want to learn CL. :) (I just played a bit and I really like it!)
Congratulations to the team! Looks great! I'll buy it later. : )
Congratulations on the release! I've been following the development blog for a fair while and backed the kickstarter and am very happy to see this game finally getting released (and OSS no less).

I've been looking into making my own game using the Trial engine but I was a bit scared off by the warnings about API stability and lack of documentation. Now that Kandria is released, is the API stabilized? And I guess the Kandria source code can work as documentation on how to set things up..

I've started writing documentation for Trial on the parts that are unlikely to change much. The API stability warning will remain though, as I can't rule out that we might have to rewrite subsystems in the future as new needs and better architectures are devised.