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!
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.
Scheme is a good language for learning functional programming. (Haskell is as well, but I would argue that several techniques the poster is likely to learn from Haskell are difficult to use in non-lazy languages, and telling them apart requires experience they probably do not possess. Also, Haskell is very poorly suited to games, and (* dodges rocks* ) seems to me like a less practical language overall .)
Also: Lua is fast (certainly fast enough for prototyping), and has a clear migration path to C / C++ for libraries and the parts of the game that need the raw speed. Something on the JVM (including Java, of course) may better suit the author, since they are probably already familiar with many of the relevant libraries, but I don't have much experience there.