I'm beating my own drum here, but the gameplay code for my game Galactology is 90%+ done in a Lisp dialect (l2l with LuaJIT underneath), clocking at 51K lines currently. It has been a huge productivity boost since I switched from C++ two years ago, but I do miss some level of typing and static checking.
http://thespatials.com/
I originally did. This was fine when the scripting was just doing data setup in advance, and it wasn't being run per-frame as game logic. When I started The Spatials V3 (aka Galactology) I also started doing real time game logic in s7. After enough code it became clear that the fastest purely interpreted scheme wasn't fast enough to be put into a soft real time path (the game grew up to hundreds of systems, in the ECS sense).
So I made a 6 months long gameplay development freeze last year and I converted all the s7-flavored Scheme code into the l2l Lisp dialect with a custom transpiler (which had to be aware of all the s7-ism plus my own s7 reader macros), and replaced the C++ binding layer with sol2. This resulted in a ten-fold increase in performance when the game is limited by logic perf (it's not visible with an empty new game). LuaJIT is alien technology for all I know.
If I had time and energy to participate, one fun idea I have would be to make an Emacs Lisp game that's some kind of mystery sci-fi thriller based on coding: like, an Emacs environment that simulates the workstation of an engineer on a Mars base, with incoming emails from mission command, a fake Unix shell with space base commands, etc. Kind of like an "epistolary interactive fiction adventure" with a hacker angle.
Man this sounds awesome! Sadly it would be a ton of work to do right for a small audience that would appreciate it or you would have to bastardize the concept so much for the masses that it would end up little more than a ‘cockpit with tons of shiny buttons’ like you get in most flying games.
Something maybe of interest to HNers to keep an eye on: I noticed that the creator of the Carp language tweeted about getting Carp ready for the Lisp Game Jam.
Organizer here. If you have any more questions, need help choosing a Lisp or graphics framework, or just want to chat with other participants, the IRC channel and Discord server linked on the jam page are nice resources with helpful folks. Good luck!
This looks like it could be fun. I don't know Lisp, but I might be willing to learn one just for this jam. Can someone recommend a Lisp version that works on Windows and is easy to setup? Simple 2D graphics like SDL will be enough for me.
Main downside of Common Lisp is that Emacs or Vim are pretty much a requirement to get a nice development environment, without which you are pretty much in 'writing Java in notepad' territory.
[0] for some definition of fast that I don't want to belabor this comment with.
Lispbox is very old (though worked good enough at the days; I actually started with it). The current "Lisp environment in a box" thing is Portacle - https://portacle.github.io/.
I couldn't get anywhere with those last time I tried (2013). LispStick doesn't seem to have been updated since 2014 and LispBox has had no commits since 2010. Have you used either of these recently?
For those wanting to go this route I'd recommend Portacle which can run on off a usb and includes git
I tried atom-slime and it worked pretty well. But, the community generally uses either vim or emacs: Oni might work, since it’s just an electron wrapper around neovim
Racket and clojure being already cited, there is also LambdaNative which is a scheme specifically for developing cross platform applications (it's based on gambit scheme). it has a binding for opengl and a GUI built with that binding.
Why that? People write a lot of experimental code. There is nothing wrong with that. One could remove them from the list, but the state is documented and you can choose to use them or not. Note also that the language does not change too much, so relatively old libraries might still work - the surrounding platform changes faster and is probably more of the actual limitation.
Please please please pick a theme. Even a vague, open-ended one will provide some creative tension and give "reviewers" a starting point when reviewing.
I think Clojure/ClojureScript can work. But its not going to be bare metal. So either a JavaScript engine, or a Java based one.
LWJGL, jMonkeyEngine, libGDX are the three top Java game engines you could use with Clojure which have been used for real games.
There's also the Arcadia project, which lets you use Clojure instead of C# to script the Unity engine.
For JavaScript targets, you have Phaser, pixi.js and EaselJS as good options.
I'd recommend you go straight for interop with a Java or JavaScript game engine. The Clojure/Script wrappers are mostly immature, and don't add much benefit.
If your just interested in art, generative stuff, controllers, etc. You can look at Quil (processing for Clojure/Script) and OverTone (Clojure interface to supercollider)
That's always my problem when I look at lisp for game programming. If I say "I want to write a standalone 3D iPhone game using C#", there are plenty of sites that'll show me exactly what tools are out there, how they work together, and how to write/debug/package a complete game.
With Lisp, I often end up in the weeds looking at tools and tech that may or may not still be supported. I have a hard time figuring out a well-established set of tools that'll get me a first-class playable game in Lisp.
If anything I'm going to watch this game jam just to see what everyone's using and how good the results look.
You can always just use a C library directly through the FFI if there isn't an obviously good Lisp option for what you're doing. You're probably not the only person trying to do whatever you're doing in Lisp, though, and asking on some online forum for Lisp users usually yields good suggestions.
> which is suitable for web-based publication, and game multimedia (graphics, audio, control, etc.)?
ChickenScheme uses continuations to transpile to C. So it supports interfacing easily with C libraries, and it supports binary distribution (Which in my exprience is difficult in most lisps/schemes).
You can use it out of the box with something like SFML or whatever.
As far as I can tell, SFML wouldn't be appropriate. By web-based publication, I mean using the APIs supported by browsers (Canvas, WebGL, Web Audio API).
i just started learning Common Lisp a couple of weeks ago. Coming from a strong OO programming background, i can honestly say it is a completely different mind-set.
So far, i like it a lot, but i wouldn't consider myself anywhere near proficient enough in it to make a game. Looking forward to seeing what the products of this Jam are.
> i just started learning Common Lisp a couple of weeks ago. Coming from a strong OO programming background, i can honestly say it is a completely different mind-set.
You might not see it much in beginner materials, but idiomatic Lisp code tends to be fairly object-oriented, using the Common Lisp Object System (CLOS). CLOS is still a bit different from OOP in a language like Java, though: it's a much more powerful object system.
If your only qualifier for something being a dialect of "Lisp" is having lots of parentheses, and a bunch of stuff that basically every high level language has these days, like first class functions and garbage collection, sure.
I wouldn't consider something a dialect unless they were similar enough that most code that works in one works in the other with minimal modification. Old Lisp code does not work in Scheme. A lot of it does however work in Emacs Lisp and Common Lisp.
So Scheme being in a Lisp "family"? Sure. But not a dialect.
> I wouldn't consider something a dialect unless they were similar enough that most code that works in one works in the other with minimal modification.
I agree, but Scheme passes this test more than you might think. When it originally appeared, it really didn't stand out from the crowd of Lisp 1.5 successors that much at all. It even piggybacked off of its host Maclisp implementation, directly calling Maclisp functions extensively from Scheme, to provide any functionality that there wasn't any point re-implementing (ie, most of it). It was basically just a Maclisp package.
Modern Scheme still has a lot of features in common with Maclisp of this time (and by extension Common Lisp), like DO (although Scheme's do has slightly different semantics because it's a macro over tail recursion rather than gotos; subtle differences like this are to be expected between dialects), and it's still based off list structure in exactly the same way that Lisps always have been, so there's still CONS, CAR, CDR, RPLACA (renamed set-car!), RPLACD (renamed set-cdr!), NCONC (renamed append!), and so on.
Scheme's lexical scoping also made it back into mainline Lisp, and was a pretty big contribution to Common Lisp. A lot of features like CLOS, SETF, and DEFMACRO (none of which were in Lisp 1.5) are very commonly provided by Scheme implementations.
Using the historical argument, there's no question at all that Scheme is Lisp. The majority of ancient Lisp programs can be run under modern Schemes with simple compatibility packages. When all the other Lisps either merged into CL or died, though, Scheme continued to be actively used, and as time went on the Scheme community shared less and less code with the mainline Lisp community. Some people argue that with the modern state of things it's not really useful to talk about Scheme as Lisp now, because they kind of "left" Lisp and went off on their own, philosophically. Scheme definitely began as just another Lisp, though.
As a side note, Scheme originally offered ASET (SET) but not a SETQ equivalent (they hadn't adopted the ! convention yet), saying: "Those of you who may complain about the lack of ASETQ are invited to write (ASET' foo bar) instead of (ASET 'foo bar)."
> and a bunch of stuff that basically every high level language has these days
Macros are not something "basically every high level language has", in fact only lisp languages seem to have them, to a point I would call it a key feature of a lisp dialect. And I mean homoiconic, highlevel, written in the same language, macros (not C pre-processor, or Turing complete templates).
Multimethods and metaobject systems are both common features of lisps you rarely find elsewhere (and python's meta object system only barely counts FWIW).
Reader macros, signals, and slime/repls (ones that don't suck anyway) are also common features rarely seen elsewhere.
They are Lisp languages. The syntax is similar, but the languages listed hardly have anything common with each other. They aren't even all on the same side of the classic functional/imperative divide.
Whether something is a dialect or a language from a shared lineage is a difficult distinction, even in natural languages.
Shanghainese is called a Chinese dialect, but it is a Wu language. It is not a dialect of Mandarin (aka the Beijing dialect), but it certainly is a dialect of a common "Chinese" language, even though it is a descendent of a language family that is not most closely related to Mandarin.
Even speaking of a functional/imperative divide is not necessarily a useful property when talking about Lispy languages. Where would you put Scheme (it's neither fully on the functional side nor does it feel at home on the imperative side). You could just as well make a distinction between Lisp 1 and 2 languages and use that as the primary discriminator.
The term "dialect" is fuzzy when applied to different spin-offs from a common pool.
(I do agree with you that they have not much in common, but often they were lifted from the same soup of ideas.)
>Shanghainese is called a Chinese dialect, but it is a Wu language. It is not a dialect of Mandarin (aka the Beijing dialect), but it certainly is a dialect of a common "Chinese" language, even though it is a descendent of a language family that is not most closely related to Mandarin.
That's the problem isn't it? A language is assumed to be a dialect of another language just because it uses the same script, regardless of its origins or how mutually intelligible it is. Reminds me of how Russian nationalists don't consider Ukrainian or Belarussian separate languages, but dialects of Russian just because they're written in Cyrillic. Might as well say that English, Hungarian and Vietnamese are dialects of Latin, just because they all use Latin script.
Same with Lisps really. People see the parentheses and assume all of these languages must be very similar, even though they really aren't.
>That's the problem isn't it? A language is assumed to be a dialect of another language just because it uses the same script, regardless of its origins or how mutually intelligible it is.
Is that really the reason? Does it follow then that Vietnamese is a Chinese dialect before it adopted a modified Latin script?
I think origins does matter, apart from shared script.