
Creating a Non-Trivial Lisp Game in 2018 - deepaksurti
https://defungames.com/2018/12/creating-a-non-trivial-lisp-game-in-2018/
======
drmeister
My group is developing Clasp (github.com/clasp-developers/clasp.git). It's a
Common Lisp implementation that interoperates with C++ and uses llvm as the
backend. It's something you might want to look at because it could change your
options in the following ways:

(1) Clasp interoperates with C++ - C++ libraries like graphics and physics
engines can be easily exposed within Clasp Common Lisp. (See
[https://github.com/clasp-developers/demo-expose-bullet-
physi...](https://github.com/clasp-developers/demo-expose-bullet-physics-
engine-to-clasp))

(2) Clasp uses llvm as the backend - it generates llvm-ir from Common Lisp
code and uses link time optimization to link C++ and Common Lisp generated
llvm-ir.

(3) Clasp uses the Memory Pool System garbage collector, which can be
configured to minimize GC pause times to a programmer-defined level.

(4) Clasp generates debug info and can be profiled with standard tools like
dtrace and C++ functions, Common Lisp functions and GC functions are all
profiled against each other.

I'm a professor of Chemistry at Temple University - I'm developing Clasp to
design molecules and materials - but it could be applied to a lot of other
problems.

Caveat: Clasp is not yet as performant as Steel Bank Common Lisp, but it uses
the open source and highly configurable Cleavir compiler developed by Robert
Strandh and we have incorporated inlining and are currently incorporating type
inference.

If you want to see a little bit more - I have a 25 min talk up on youtube that
I presented a couple of weeks ago at the 2018 llvm developers meeting
([https://www.youtube.com/watch?v=mbdXeRBbgDM&feature=youtu.be](https://www.youtube.com/watch?v=mbdXeRBbgDM&feature=youtu.be))

~~~
gameswithgo
Does clasp still support all the metaprogramming features of lisp while using
llvm, and how does it do it?

~~~
armitron
Given that clasp is a Common Lisp - that passes 97%+ of CL ANSI tests on par
with other CL implementations like SBCL - then answer is obviously yes.

You need to go into more detail about why you think llvm would make a
difference. Common Lisp is usually compiled to native code and the compiler is
- unlike most other languages that compile to native code - exposed and
available at runtime. When you program interactively in a natively-compiled
Common Lisp implementation like clasp or SBCL or ClozureCL, your code is
compiled to native code on the spot. You can even customize the code
generation via compiler macros. LLVM is just another compiler backend that can
slot in so in that regard, conceptually it's seamless.

------
praptak
See
[https://news.ycombinator.com/item?id=1998321](https://news.ycombinator.com/item?id=1998321)

 _" I even went so far as to write an entire compiler and environment (a
several man-year endeavor) to design two different runtime oriented dialects
called GOOL and GOAL used in 8 Naughty Dog Crash Bandicoot and Jak & Daxter
games. All 30-60 FPS action games -- 40 million copies sold. All written in
Lisp! (more or less)"_

~~~
ineedasername
That's pretty interesting too! Although I think the advantage of the game here
is that it's not only written in Lisp (or CL as the case may be) but the
client is actually going to be open source, and it sounds like they're
incorporating a (subset?) of the Lisp language as a component of playing the
game.

------
pmarreck
"Abuse" by Crack.com way back in 1995 was powered by Lisp, as I recall (and
also moddable via it):

[https://www.mobygames.com/game/dos/abuse](https://www.mobygames.com/game/dos/abuse)

[https://everything2.com/title/abuse](https://everything2.com/title/abuse)

~~~
nsajko
The source, maintained by Sam Hocevar:
[http://abuse.zoy.org/browser/abuse/trunk](http://abuse.zoy.org/browser/abuse/trunk)

------
mattnewport
Of all the code that might have to be written for a non trivial game, a
skeletal animation system doesn't strike me as particularly difficult. Curious
why that was called out specifically as something not to try and implement
yourself?

~~~
deepaksurti
I agree that skeleton system is not very hard to implement. Anecdotally, one
of the first CL based apps I wrote were to implement Quake MD5 (.md5mesh and
.md5anim) parsers to do skeletal animation.

I think he might be categorising it as hard for the following: \- Defining a
simple, easy to navigate data structure with the bone and weight mappings
across vertices, to do the math for pose calculation \- Having a highly
compressed binary format for animation data, which is definitely hard but
required for good FPS \- Doing it on CPU or GPU

------
westoncb
The article talks about one of the primary motivations for using Lisp being
that it's 'fun,' which is a comment I've heard about Lisp elsewhere, and which
makes sense to me since I've noted a difference in funness between other
languages.

So that's pretty appealing to me, but I haven't quite found the right Lisp to
use. It seems like Clojure (probably ClojureScript actually) would be the most
practical for me to use on some projects—but I'm curious whether others have
found Clojure/ClojureScript to have that same element of fun Lisp is sometimes
known for.

~~~
armitron
Clojure is practically tied to the JVM and the Java ecosystem (ClojureScript
is different enough to count as a different language so I'll focus on
Clojure).

To me that's not fun. It's also limited by design to fit the development model
Rich Hickey wanted for his consultancy. It is nowhere near as encompassing or
paradigm agnostic as Common Lisp. Moreover, you can take old Lisp code that's
40+ years old and run it today on top of Common Lisp with no/minor changes.
Clojure breaks compatibility with Lisp code in many different ways. For me
these reasons are enough not to consider Clojure a Lisp.

~~~
dustingetz
if by limited we mean full ecosystem compatibility with jvm and javascript,
then yes, Clojure is limited. Which 40 year old CL codebase is it that i am
trying to run?

~~~
armitron
The decisions behind Clojure worked out well for Rich Hickey and his
consultancy but they don't fit the programs that I find myself writing all the
time (compilers, assemblers, virtual machines, tight control of code
generation and memory operations and so on). I can do all of that - and more -
in SBCL and it's a pleasure to use as the I don't have to bend myself to work
around language shortcomings. Common Lisp gives me a multitude of programming
paradigms and an enormous arsenal of approaches to use. When working in
exploratory domains, that I do all the time, nothing else comes close. Here is
an example of using SBCL for exploratory lowlevel programming by Paul Khuong
[1].

I've written _performant_ and _lightweight_ TCP/IP network stacks in Common
Lisp. Clojure is just too constrained.

As far as old Lisp code goes, it's everywhere - if you care to look -. The
lambda papers, McCarthy's original papers, the CMU CL repository (still of
practical use today), vast archives of Lisp code from MIT and so on and so
forth. Not to mention useful frameworks like Screamer [2] which is close to 30
years old and Maxima [3] which is even older.

[1] [https://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-
assembl...](https://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-
code-breadboard/)

[2]
[http://nikodemus.github.io/screamer/](http://nikodemus.github.io/screamer/)

[3] [http://maxima.sourceforge.net](http://maxima.sourceforge.net)

