Hacker News new | past | comments | ask | show | jobs | submit login
Lisp Game Jam 2018 (itch.io)
199 points by tosh 11 months ago | hide | past | web | favorite | 70 comments



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/


In a lisp dialect? I thought you went with s7 as an embedde scripting language for C++!


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.

I have to do a proper write up some day.


Thanks man. I wish you the best with your game. Sounds like the total dream job to me. I am eager to read that write up!


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.


Reminds me of Bussard (https://technomancy.itch.io/bussard), a "space flight programming adventure game" written in Clojure.


It’s written in Lua.


Mind if I steal this idea? I've been meaning to learn some elisp for a while and games revolving around fictional computer interfaces appeal to me.


Do share, should you end up with something others can enjoy.


Don't mind at all!


I've had the same idea for a few weeks now. I'm surprised I'm not the only one.


You might be interested in Bussard: https://technomancy.itch.io/bussard


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.

https://twitter.com/e_svedang/statuses/977569718101069824

https://github.com/carp-lang/Carp


This dev does awesome cute little games in Lua in these kinds of competitions, if you need inspiration: https://rxi.itch.io/


Maybe using one of the lisps that compile to lua would be a good idea, since löve is pretty nice to make games in.

There's quite a lot of them, I don't know how they compare:

https://github.com/bakpakin/Fennel

https://github.com/sctb/lumen

https://github.com/leafo/moonlisp

https://github.com/SquidDev/urn


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!


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.


Ludum Dare 41 starts 1 day later. So maybe you could pick their theme! A constraint like theming makes things much easier imho.


Organizer here. We tried a theme last jam and it didn't go so well.


That’s interesting to hear! Usually game jam culture is very receptive towards themes. What did you find didn’t work?


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.


I'm biased but I'd go Common Lisp

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.


To get started quickly with SBCL/Quicklisp/Emacs/Slime on Windows:

https://common-lisp.net/project/lispbox/

or

http://www.iqool.de/lispstick.html


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


Thanks. I haven't used windows for development in years and was not aware they went stale.


To toot baggers' horn, he has a great video series where he does game development in lisp: https://www.youtube.com/watch?v=82o5NeyZtvw&list=PL2VAYZE_4w...


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


there’s lispbuilder-sdl which I was one of the founders of years ago, although it maybe suffering from bit rot these days

https://github.com/lispbuilder/lispbuilder


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.

http://www.lambdanative.org/


Already an example game in LambdaNative: https://github.com/part-cw/lambdanative/blob/master/apps/uSq.... Compile it and run it, or get it from the App stores



Wow, the amount of [STALLED] or [ABANDONED] tags on that list sure was depressing.


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.


Take a look at racket (https://racket-lang.org/), works on windows and is the most beginner-friendly lisp I know.


https://docs.racket-lang.org/games/index.html

Also has bundled bindings for OpenGL and other GUI stuff. You can find more there: https://docs.racket-lang.org/index.html


Huh, cool. I like that they provide a module for traditional card games

https://docs.racket-lang.org/cards/index.html


I'd recommend Fennel and Love2D, if you're ok with picking up a bit of Lua, or if you already know it.


I would suggest SBCL if you're going with Common Lisp, although Clojure + libgdx could be an interesting combination.


Can anyone recommend a Lisp dialect / environment which is suitable for web-based publication, and game multimedia (graphics, audio, control, etc.)?


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.


if you can find bindings to SDL2 it is easy enough to do 2d games

add opengl and you can do 3d games


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.


If you want it to actually run in the browser then ClojureScript is probably what you want.


Thanks, this looks like a good way to interface with the browser APIs.

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.


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

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.


Clojure is pretty nice. Has a fair amount of both backend projects and Clojurescript is very nice for frontend work.


Common Lisp with the Parenscript library; use any JS game framework underneath that appeals.


Does using Arcadia (Clojure for Unity, https://github.com/arcadia-unity/arcadia) qualify?


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.


The discord invite on that page has expired, does anyone have a current invite?


Organizer here. The link on the jam page has now been fixed.



>Must be written in any dialect of Lisp. This includes, but is not limited to Common Lisp, Scheme, Emacs Lisp, and Clojure.

How are these dialects of each other? By this logic, Javascript is a dialect of C.


They are not dialects of each other but all are Lisp dialects. You would not call Scheme a dialect of Emacs Lisp, but both are Lisp dialects.


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.


Whether something is a separate language or a dialect is as much cultural as it is technical.


Like Norwegian & Swedish.


By this logic Javascript is a dialect of Lisp.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: