I don't know how to say this without sounding like a troll, so I'll just come out and say it: the people who have responded to your question so far sound like they know a lot about Lisp or functional programming and rather little about games.
You came to HackerNews, where all the functional programming boosters hang out (myself included) and asked: can I use functional languages for X? What, were you expecting an unbiased answer? To HackerNews, functional programming can do X optimally, forall X.
All languages have tradeoffs, though it sometimes seems like we have yet to face up to the tradeoffs in functional programming. But in truth, functional programming kinda sucks for games, and the more functional it gets (that is, as it approaches Haskell), the more it sucks. Because game logic is all about the one thing that pure functional programming disdains with all its heart: global internal state and side effects. The purer you get the more you have to jump through hoops to manage this kind of stuff. So IMHO you're really asking: can I learn a functional programming language by coding something which functional programming is fairly hostile? And people here are responding: sure, you'll love it! It's perfect for you!
Also note that real game programming is also often about speed and soft real-time guarantees. Sure, games often have a high-level scripting language in which certain gameplay elements are written. Lua, for example, is one popular choice. Variations on Javascript are another. But if you're looking to write a game in a programming language, and need to eek out that extra bit of cycles to do something nifty, most of the languages here are bad bad choices. This is probably not something you care about since you're just looking to learn, which I applaud. But it does tell me that boosterism is in effect when people recommend Lua and Clojure and ABCL and SISC for game programming that they've not considered, and they don't bother to tell you that these languages are quite slow, for an environment (games) where speed really matters.
So if you're trying to learn a functional language by doing a game, I'd pick the least hostile functional language that has highly portable graphics and event support and which is decently fast. Ordinarily I'd say CommonLisp, but ABCL's not there yet. One language in this category is Kawa, a JVM scheme which can be optimized to run at a decent fraction of Java. PLT might be another choice: it's not super fast but has very strong and portable libraries.
I actually recently had to install SBCL on my OS X 10.4 (Tiger) box. Here's how it went:
1. Grab from the Downloads folder.
2. Build.
3. Bombs during building because SBCL now relies on a link symbol which doesn't exist in Tiger. Apparently all Mac Lisp users are require to be 10.5 Leopard users.
4. Swear a bit.
5. Search the web.
6. Find lots of people swearing also, no answers.
7. Try CVS.
8. Build.
9. Bombs during build.
10. More swearing.
11. Start hunting through earlier versions of SBCL.
12. About 10 downloads later (and they take a lot of time each to download and build until it fails), finally find one which doesn't rely on the symbol.
Incorrect. These are signed values. If you subtract a large negative integer from a large positive integer, the result is larger than an integer.