6 ms·

Creating a Non-Trivial Lisp Game in 2018

149 points by deepaksurti 8y ago

praptak 8y ago
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 8y ago
  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.
mattnewport 8y ago
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 8y ago
  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
drmeister 8y ago
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-physics-engine-to-clasp https://github.com/clasp-developers/demo-expose-bullet-physi...) (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)
- mthom 8y ago
  Wonderful and inspiring work! I wonder if it would be possible to create a similar interop story with the Rust programming language, which also targets LLVM -- ideally without having to redo all the hard work that went into Clasp. I have a Prolog interpreter/compiler I'm developing in Rust right now. One of my aims (eventually) is to compile Prolog to fast native code with it. It would be nice to have convenient access to it from a Common Lisp environment.
  - gameswithgo 8y ago
    Rust can already talk C ABI so I think the dream is already reality.
pmarreck 8y ago
"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 8y ago
  The source, maintained by Sam Hocevar: http://abuse.zoy.org/browser/abuse/trunk http://abuse.zoy.org/browser/abuse/trunk
westoncb 8y ago
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 8y ago
  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.
  - _emacsomancer_ 8y ago
    Still, in cases where one is tied to the Java ecosystem for whatever reason, surely Clojure is better than no-clojure?
    - armitron 8y ago
      I'd still pick something else in that case too since I don't really like the decisions behind Clojure. But hey go for it if it fits the problems that you find yourself solving.
      - maufdez 8y ago
        There's always Armed Bear Common Lisp. which runs on the JVM, if you want to stay in it. And you can also try [Linj](https://github.com/xach/linj https://github.com/xach/linj) which is similar to Common Lisp an transpiles to Java.

149 points by deepaksurti 8y ago

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 8y ago
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.

mattnewport 8y ago

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 8y ago
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

drmeister 8y ago

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-physics-engine-to-clasp https://github.com/clasp-developers/demo-expose-bullet-physi...) (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)

mthom 8y ago
Wonderful and inspiring work! I wonder if it would be possible to create a similar interop story with the Rust programming language, which also targets LLVM -- ideally without having to redo all the hard work that went into Clasp. I have a Prolog interpreter/compiler I'm developing in Rust right now. One of my aims (eventually) is to compile Prolog to fast native code with it. It would be nice to have convenient access to it from a Common Lisp environment.
- gameswithgo 8y ago
  Rust can already talk C ABI so I think the dream is already reality.

pmarreck 8y ago

"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 8y ago
The source, maintained by Sam Hocevar: http://abuse.zoy.org/browser/abuse/trunk http://abuse.zoy.org/browser/abuse/trunk

westoncb 8y ago

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 8y ago
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.
- _emacsomancer_ 8y ago
  Still, in cases where one is tied to the Java ecosystem for whatever reason, surely Clojure is better than no-clojure?
  - armitron 8y ago
    I'd still pick something else in that case too since I don't really like the decisions behind Clojure. But hey go for it if it fits the problems that you find yourself solving.
    - maufdez 8y ago
      There's always Armed Bear Common Lisp. which runs on the JVM, if you want to stay in it. And you can also try [Linj](https://github.com/xach/linj https://github.com/xach/linj) which is similar to Common Lisp an transpiles to Java.