
Asteroids in under 600 lines of Common Lisp (uses SBCL and SDL) - Charles__L
https://github.com/andyhd/asteroids/blob/master/asteroids.lisp
======
prospero
Here's an Asteroids clone I wrote in Clojure a few years back, which has less
than 400 lines and some neat stuff like procedurally generated 3D asteroids:
[https://github.com/ztellman/penumbra/blob/master/test/exampl...](https://github.com/ztellman/penumbra/blob/master/test/example/game/asteroids.clj)

Some of the design decisions are discussed in detail at
<http://ideolalia.com/creating-a-simple-game-in-clojure>

~~~
fusiongyro
The Lisp code used multiple dispatch to handle collisions between objects,
whereas your Clojure code instead uses list comprehensions to generate pairs
of colliding objects by type. I know Clojure also supports multiple dispatch,
so I'm wondering if you could comment on this design decision.

~~~
prospero
The only collisions I care about in my implementation are asteroid/ship and
bullet/asteroid, and they're easier to express directly. The OP's version
appears to have many more types of collisions, which makes multiple dispatch a
more obvious choice.

------
ken
Looks pretty good overall, but there are a few little oddities.

Not to turn this into a design review, but using EQ to test for 0 seems like
it's asking for trouble, and it looks like that * has only one argument.

~~~
andyhd
Thanks for the tip. I didn't realize numbers with the same value could be
different to eq.

------
notJim
It would be incredible to me if someone could write some commentary about this
for the non-lisper. Skimming it now, it seems very familiar to me (as in, I
don't really see anything about it that expresses anything particularly
beautifully), but I might be missing some of the finer points. Overall, I
recognize a lot of familiar code that I've written for games in javascript.
It's hard to appreciate the aesthetics of this, since I'm not familiar with
the language.

~~~
aidenn0
My guess is that the author is new to common lisp. It's the only CL project in
his github account, and he wrote it using vim. Most people who have been using
SBCL for a while will use emacs with SLIME as it is the recommended IDE for
using SBCL.

So I wouldn't expect it to contain any particularly awesome lisp-isms. My
first read made me think it was using multiple-dispatch, but it isn't doing so
in a way that wouldn't also be possible in a language with overloading, as no
more than 1 parameter is ambiguously typed at function call time.

~~~
fusiongyro
I think it's a little disingenuous to expect less of someone for using a
different editor. Good catch on the multiple dispatch though.

~~~
FuzzyDunlop
I think it would be fair to say that the characteristics of the code you write
could change depending on whether you use an editor or an IDE though.

If emacs + slime is to lisp what eclipse is to java, then I think that is what
the GP was alluding to.

~~~
fusiongyro
It makes just as much sense as racial profiling.

~~~
rglullis
To avoid the politics: "it makes just as much sense as Bayesian inference".

~~~
fusiongyro
I suppose that's better. Great Lispers are statistically unlikely to be using
Vim, but the number of people using Vim is so large that merely using Vim
isn't damning evidence that code is poorly written.

~~~
batgaijin
It's not 'great lispers' it's 'programmers reading lisp tutorials'

If you can find one Lisp tutorial that mentions only Vim or even shows Vim and
Emacs as competing setups I would be genuinely surprised.

~~~
idoh
Here is one: <http://ycombinator.com/arc/tut.txt>

"There are 4 parentheses at the end of that call to cons. How do Lisp
programmers deal with this? They don't. You could add or subtract a right
paren from that expression and most wouldn't notice. Lisp programmers don't
count parens. They read code by indentation, not parens, and when writing code
they let the editor match parens (use :set sm in vi, M-x lisp-mode in Emacs)."

------
rwos
This was on /r/programming and now it's here - I'm sorry, but I don't really
understand what this is all about. 600 lines doesn't seem ultra-small to me.
And Lisp - well sure, not too common a language for games, but it's not as if
this was written in a purely functional style or something. In fact, it looks
like pretty standard imperative programming to me - it wouldn't look much
different in C.

Am I missing something here?

~~~
andyhd
I wasn't trying to write it in less than 600 lines, that's just what the OP
used for an interesting title, I guess.

It's just a fun project I did to learn a bit of CL. I translated the code from
a Python game, so it's not in pure functional style. Now that you mention it,
though, I feel like I should try that.

------
justinhj
Nice to see a project using
<http://code.google.com/p/lispbuilder/wiki/LispbuilderSDL> which wraps the SDL
library amongst others and works on Linux, Mac OS X and Windows.

------
spaninispa
great!

it's a nice project, it's free, it's modern, it works, it's an interactive-
graphic-non-boring thing, it's a game!

lisp needs more of this.

party's open: more functional, macro wiser and skinnier ones are welcome.

vim should be welcome too as I run ASTeroids fine under vim+slimv (just like
the terminal) while under emacs+slime it doesn't display some white line
segments here and there... (same sbcl for all)

last thing, I scored 3432 (level 11) with the first coin...;)

~~~
andyhd
Thanks for your support! I totally agree with you - I put the code up on
Github because I figured someone like me might want to improve it or take it
in another direction.

------
rule30
no macros? I'm no expert and I'm asking to experts: macros are one of the key
features of Lisp. Should macros have helped reducing LOC or improving
maintainability?

~~~
sp332
Disclaimer: I'm not a lisper. But according to Paul Graham, _Macros are harder
to write than ordinary Lisp functions, and it's considered to be bad style to
use them when they're not necessary._ <http://www.paulgraham.com/avg.html>

------
swah
"If the browser ran bytecodes instead of javascript..."

------
gawi
Not even using libasteroid...

------
sahat
I didn't know what a beautiful code was, until I looked at this project.

~~~
andyhd
Thanks!

------
prtamil
I just observed , whenever there is a discussion about Common Lisp , some how
somebody would inject something about Clojure. Did anybody noticed that ?

~~~
prtamil
Its simple Logic,

Programmers Those who use C = C Programmers. Scheme = Scheme Programmers.
Common Lisp = Common Lisp Programmers. Clojure = Clojure Programmers.

Programmers Who use Clojure != Common Lisp Programmers.

So Please, please stop posting about Clojure in Common Lisp Posts.

I don't want Clojure solution for Common Lisp problem.

