

Purely functional (retro) game programming. - euccastro
http://prog21.dadgum.com/25.html

======
euccastro
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.

<http://news.ycombinator.com/item?id=29335>

~~~
palish
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.

Good luck. :)

~~~
jcl
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):

<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.

~~~
brlewis
Since scheduling / shipping on time was their #1 thing that went right,
apparently the bottleneck didn't cause them too much grief.

