Lisp Game Jam 2018
itch.io
itch.io
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.
I have to do a proper write up some day.
There's quite a lot of them, I don't know how they compare:
https://github.com/bakpakin/Fennel
Also has bundled bindings for OpenGL and other GUI stuff. You can find more there: https://docs.racket-lang.org/index.html
https://github.com/lispgames/lispgames.github.io/wiki/Common...
The basics:
- SBCL: generates fast[0] code. runs well on windows
- Quicklisp: The package manager which lets you install the packages mentioned below
I've got a video here that should help with getting set up on windows https://www.youtube.com/watch?v=VnWVu8VVDbI&t=1s
Then you could try the SDL2 approach:
- cl-sdl2: Bindings over sdl2 https://github.com/lispgames/cl-sdl2
- cl-sdl2-mixer: audio playback https://github.com/lispgames/cl-sdl2-mixer
- Some basic math library like: 3d-matrices, rtg-math, sb-cga
Or maybe an existing engine:
- https://github.com/borodust/trivial-gamekit
Come down to #lispgames on freenode if you need a hand as there is usually someone there who has touched this stuff[1]
I'll also pimp my own stuff while I'm here just in case someone is looking for a lispy layer over gl
- https://github.com/cbaggers/cepl
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.
https://common-lisp.net/project/lispbox/
or
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.
add opengl and you can do 3d games
I found an example of a game created in it: https://deque.blog/2017/03/28/building-a-clojurescript-game-... ( Source: https://github.com/QuentinDuval/triboard/tree/master/src/clj... ) Seems fitting that it focuses on AI.
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)
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.
Potentially I could use Emscripten's HTML5 API ( https://kripken.github.io/emscripten-site/docs/api_reference... ). Although I was hoping for a nicer interface than calling out to a C translation of the JavaScript APIs.
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.
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.
How are these dialects of each other? By this logic, Javascript is a dialect of C.
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.)
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.
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.
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 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.
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.