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...
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.
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.
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.
7 comments
[ 5.3 ms ] story [ 38.2 ms ] threadhttp://news.ycombinator.com/item?id=29335
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...
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.
http://www.lua.org/about.html
http://plausible.org/nasal/
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://www.gamasutra.com/features/20020710/white_02.htm
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.