This series reminded me of Palish's interest (one year-ish ago) in how to apply functional programming principles to making games. Hopefully, this will be of interest to others here.
Heh. Looking back on it, that thread has some pretty valuable content.
What I've realized since then is that the only way to truly master something is to immerse yourself in it. Learning something from someone over a chatroom is fundamentally suboptimal. It does have its advantages... Well, one advantage, which is that you can ask questions. But the disadvantages of learning from a chatroom simply outweigh any benefits. The details of a technical subject will always remain elusive, and you'll only acquire common knowledge.
My favorite way to become immersed in a new concept is by reading its reference manual from cover-to-cover. I'm currently working through the OpenGL 2.1 specification: http://www.opengl.org/registry/doc/glspec21.20061201.pdf
In the past, whenever I was reading a reference and ran into something I already knew, my eyes glazed over and I'd usually skip ahead. But one time, pretty much on a lark, I sat down with the .NET design documentation and paid attention to every word for as long as possible. I got pretty far, but what was surprising was how much useful knowledge I'd acquired. It was nice to be able to apply that knowledge at work the very same day. A lot of the internals of the framework became much less mysterious. It's like the difference between a car owner and a car mechanic... An owner knows operation fundamentals, but a mechanic can tell you the source of that rattling noise.
Yesterday, a friend was having trouble with his computer engineering course. I wanted to help, but he said "You'd have to learn 68hc11 assembly." I searched for a reference, found one ( http://www.owlnet.rice.edu/~elec201/Book/6811_asm.html ), and carefully read through it in one hour. It was fun to show him some abilities of the 68hc11 that he wasn't yet familiar with. But the point is, no new concept is out of reach. Learning it just requires effort and patience.
About Lisp: I recently read the LispWorks documentation ( http://www.lispworks.com/documentation/index.html ). Based on a few experiments, high-performance games can be written in Lisp. (I'm not sure about other languages. Scheme is still far too slow to author a game engine in, unfortunately.) That seems to have big implications for the game industry, very similar to how Viaweb redefined the way in which websites were created. Naughty Dog Software is the only big game studio that has written a large game in Lisp. The other significant Lisp-based game is Abuse. And that's it, past a smattering of text-based adventure games. There is a lot of unexplored territory.
Imagine developing a persistent online game. You'd like to implement a new gameplay ability; perhaps just a minor balance tweak. Traditionally, doing so would require either a modification of server code (in which case the server would need to be restarted, forcing every player to reconnect) or an edit of a server-side database (to adjust "damage tables", etc). But if you're developing the game in a dynamic language like Lisp, you can simply write the exact algorithm you have in mind and deploy it instantly. No restart required.
That's a server-side change though. What about the game clients? Let's say you want to implement the logic: "When a vehicle's front bumper hits another player, the text 'Splatter'd!' appears on the screen." Again, with traditional game development you'd make the change to the game client (which is probably written in C++), test it, then "deploy" the new game client. If the gameplay change is significant, every player would get booted from the server and be forced to download the new client. If it's not significant, the player isn't booted but he doesn't see the new change until the next restart. But if your game is built with a high-level language, you could simply modify the game client and send the modified code to the server. The server would then transmit that modification to every player, who would then see the change instantly.
To an extent, that kind of dynamic development is already happening. The studio that created Eve-Online is taking promising steps - they rely heavily on Python, for example. My personal favorite at the moment is Lisp, because of the idea that it could be possible to write every single component of a large-scale game in a single programming language. LispWorks and Franz Allegro CL are capable of generating very high-performance code. Because of that, I believe game programming can attain an efficient, powerful, and flexible development cycle.
The only way to realize this dream is by learning every capability of both the computer and its programming tools. Hence, I read OpenGL and LispWorks manuals in my spare time. :)
Some tips to efficiently acquire knowledge:
* Implement what you read. When you run across a new function, you'll read it and feel like you've learned it. But the seductive urge to move on should be suppressed. Write a program that actually uses the new function or capability that the manual is describing. Doing so will solidify your knowledge of the details and give you a handy mini-reference to turn to when you need to remember how to accomplish something specific.
* Devote large chunks of time to reading and experimenting. Make sure your study time is distraction-free. Learning a big new system is just as intense as creating one.
* Avoid the temptation to skip around. This one isn't an absolute, but if you do skip around then it's very important to revisit the text and carefully read what you previously skimmed. And related to that...
* Don't move ahead until you have a firm understanding of every concept presented so far. I've moved ahead prematurely a few times, and it's very easy to become lost or miss a subtlety of a more advanced concept.
* Don't get frustrated. Your advancement will require a lot of patience.
* Don't ask for help. Learn to rely on yourself to solve problems.
* Force yourself to not deviate from the task at hand until it's done. Avoid Reddit, News.YC, etc, even if you're only checking them. Little distractions add up and suck time, and they break your train of thought.
* Do get some sleep. 8 hours a day is vital.
* Make it fun. Every domain has interesting problems, but they're usually hidden just out of sight.
* Never give up. This one's corny but true. It's surprising how many times you'll accomplish a task just before you were about to give up on it.
The developers of Vendetta Online (http://www.vendetta-online.com) used to use Lisp for some of their server-side components but have since switched to Erlang.
Don't leave out the free Lisps - CMUCL and SBCL are also capable of generating very fast code. Scheme can be fast too - Chez and Icarus are known for speed, and there's always Stalin if you're willing to deal with a static program or add your own interpreter.
I found it interesting that, in Naughty Dog's postmortem of Jak and Daxter, their Lisp-inspired language was #5 on their list of "what went right" and #1 on their list of "what went wrong" (although the ordering might not indicate importance):
While they loved the runtime flexibility of the Lisp-ish engine, their compiler developer -- "one of the top ten Lisp programmers" -- turned himself into a giant bottleneck, since no one else could understand his code well enough to help him fix the bugs in it. They also found it difficult to interface the language with existing C/C++ game utility libraries.
It doesn't have the mindshare that Lua does, nor the history, nor the testing frankly. But honestly (and yeah, I'm biased) Nasal is a cleaner, simpler, more robust and overall better language than Lua, especially for people mor e accustomed to the perl/python/javascript notion of how scripting languages should work.
http://news.ycombinator.com/item?id=29335