agavin

Why? I'm very NOT large studio oriented. I don't think anything stated in my post (which is just part of a larger series I'm writing) is even about studio size. In this particular post I'm just broadly breaking down some of the sub-specialities inherent in the process of programming video games. In a web app you need more network and database programmers, in a video game you need graphics and sound programmers. It's just practical sense. The same guys might do these tasks, but if you like advanced 3D graphics and get a kick out of it -- get a programming job that involves graphics!

It's all of the above. As lead you have to fill in, to do what no one else wants to do, to keep try of all the things that need to be done in the say 48 hours to the next deadline and sort them by priority. But you often have to work just as long as the longest worker on the team if only out of solidarity. It's important that no one can ever say to you: "You took it easy, while I did the work."

This principle is why Caesar, Alexander, and Napoleon were all beloved by their men. They dug in there with everyone else. Slept on the ground. Rode first into battle. All that. It seems silly, but don't underrate it. I can't tell you how many times someone would come to me at 4 in the morning before a deadline and say how much they appreciated that I was there. No one wants to feel used.

All the studios that consistently turn out brilliant games: Naughty Dog, Valve, Epic, Blizzard and many many others are really well run. Working there might often be brutal because of how hard the job is and pressure, but they know the process of making great games and the quality of employees is very very high.

It's less so at the big corporate studios where marketing and big company policy has heavily infiltrated the system.

I'd have to content that my own games (Crash + Jak) are far far less buggy than the typical web or desktop application. We had a VERY low tolerance for bugs. I NEVER EVER shipped with a known crash bug (there were some I didn't know about of course). As entertainment we always felt that the consumer had zero tolerance for bugs. Something like MS Word is riddled with serious bugs that don't get fixed major release after major release. We had a huge staff of in house QA and even more external.

Physics, collision, animation, and certain types of compression also use a lot of math. I also found that just plain gameplay programming in 3D games required a pretty decent command of matrix math and analytic trig.

Scrivener blows the pants off of monolithic WPs like Word for large structured writing (books or longer articles). I have a pretty detailed analysis on my blog as to why:

http://all-things-andy-gavin.com/2011/02/25/scrivener/

For those of you who can't get enough GOT CGI, the SFX company released yet another 3 minute before and after video:

http://all-things-andy-gavin.com/2011/08/05/more-game-of-thr...

Cool stuff.

The titles were pretty amazing, simultaneously being cool and helping to give new viewers some sense of the layout of the world. Like a 3D jacket map.

Haha. I remember joking about the name of this game at the Naughty Dog offices when it was like 3 years late -- I swear it was in the 90s! Perhaps during the development of Crash Bandicoot Warped. Never ever pick a title with the word "forever" in it.

I have some detailed articles on the Making of Crash Bandicoot at my blog:

http://all-things-andy-gavin.com/category/games

or the first of the Crash series:

http://all-things-andy-gavin.com/2011/02/02/making-crash-ban...

Mario 64 wasn't itself written in LISP at all. It's models were built in Nichimen graphics, a SGI based 3D design tool written in Allegro CL.

As far as I know, the games we did at Naughty Dog (Crash 1-3, Jak 1-3 + X), and later Uncharted were the only major console games which large amounts of runtime Lisp. The Jak & Daxter series was 99% written in my Scheme dialect GOAL, including all the assembly. The only parts that weren't were libs talking to Sony's libraries (C++).

http://all-things-andy-gavin.com/category/games/

All of the AI and character control in Way of the Warrior and the first 3 Crash Bandicoot games was written in GOOL 1&2, my first and second generation LISP systems: http://all-things-andy-gavin.com/2011/03/12/making-crash-ban...

I have all sorts of articles on Crash 1 on my blog: http://all-things-andy-gavin.com/category/games/

For Jak & Daxter 1-3 + Jak X I did a new Scheme based compiled language (GOAL) in which 99% of the games were written. I haven't yet done a big write up on that for my blog, but I will one of these days.

The no-OS is certainly no longer valid with the networking services etc. Still, even on the PS2 there are areas where you might or might not want to use the OS, or plenty of ways in which you can tailor your code more tightly to the machine. On the PS3 a perfect example would be use of the SPUs. The best engines have all sorts of functionality offloaded to the SPUs. Rendering, sound, joint processing, collision, particles, etc etc. Offloading each of these tasks is a fairly herculean amount of engineering as you must write elaborate SPU assembly modules (at least several programmer weeks for the very simplest ones) and the way in which the services interact with your main thread become fundamentally different. It would be hard to use these same architectural choices on the 360 and the PS3 as the 360 doesn't have SPUs (but has more regular threads).

I just posted another technical article on the Crash series:

http://all-things-andy-gavin.com/2011/03/26/crash-bandicoot-...

or the HN link:

http://news.ycombinator.com/item?id=2372240

Ultima was so easy to patch that I wrote my own character editor in basic that worked on II, III, and IV (Apple II versions). You'd insert a disk at the programs's request, load a character and could edit virtually any property or inventory item. The Binhex style single byte encoding really did make it a "pleasure" to hack.

There is now a part 7 and part 8.

http://all-things-andy-gavin.com/2011/02/10/crash-bandicoot-...

http://all-things-andy-gavin.com/2011/02/16/crash-bandicoot-...

NDI didn't ditch GOAL because I left. In fact they used it for JakX and they also ported it to the PSP (successfully). However, the PS3 development didn't get started on porting it early, so they went with a different tact. Christophe (co-president and lead tech honcho there now) lamented to me on several occasions that they should have ported it to the PS3.

Not that the process hasn't gone well for them -- Uncharted and UC2 are totally awesome, and watching the UC3 trailer gives me goosebumps. Dan (head gameplay programmer) did miss it so bad that he went with Scheme for their scripting :-) There are many ways to skin a cat, and the truth is that as long as you have good people (which they do in spades) and make decent decisions decisively, things tend to work out. Forward progress is one of the most important things.

I would like to add a corollary to this theorem. The best programmers are also willing to work with the annoying technologies -- although they will gripe (healthily) about them. It's all a balancing act.

There is a type of programmer who could be great, but is merely good because they refuse to use or deal with annoying techs. Sometimes, you just have no choice, and brute forcing past the annoying is by far the most efficient solution.

You all know this type. They are the kind of guy that exclusively used the Next (or Amiga), and ran windows in VM Ware on a bleeding edge Debian install in 2000 -- When the software they were being paid to develop was compiled in Visual Studio!

That's the thing. I hate MSFT. I hate Windows. I'll avoid using it. But... if the task requires that a regular PC GUI app be written, I'll use Visual Studio. Although I have been known to ask less PC phobic employees to handle this part of the job :-)

Of course, I also decided for an entire series of Playstation 2 games to forego doing the normal thing (using C/C++) and wrote my own Scheme compiler/debugger/environment. And of course, this quickly spiraled into several man years of work (on my part). It did come out pretty well. We did four games, and they sold tens of millions of copies -- dozens of programmers used the system and it was pretty cool. But boy was it stressful. I really should have figured out a way of solving my problems that didn't require so much custom programming to solve a sub-problem of my task.

My main task was: Program an absolutely fantastic 3D action game in 2-3 years.

I got sidetracked by the theory that "C/C++ sucks for writing highly customized game code" and that the compile/link/run cycle of 10+ minutes made iterative testing (which is the mother of all good gameplay) slow. This is all true, but it's a less focused problem than making a great game.

Avoiding this or that technology, or using this or that more fun one is not the same as getting the job done.

That being said, programming in Lisp, or Ruby feels like walking on water compared to C/C++'s being wrapped in chains and pushed off the boat. You just don't want to stroll off toward Australia when your gig is in Japan.

RSS brings me 90% of my outside information. And by doing it with programs like Reeder that use Google Reader to sync the feeds and what's been read allow me to do it on 3 computers, an iphone, and an ipad without ever seeing the same junk twice

But, it does require some computer savvy to setup and operate. You need programs, you need to sometimes figure out your feed URL's. Good reader has a really weird and lousy interface.

As a computer guy I don't care, but I rarely recommend it to even medium tech savvy friends because I don't see them dealing.

The only programming I'm doing at the exact moment are little hacking projects. But I did a whole bunch of backend "cloud" programming in 2006-2008, and I used Ruby for most of it. This included 90% of the backend for Flektor.com (now deceased -- but successful in that it was cool and we sold it to Fox) and all the backend stuff for Monkey Gods (monkeygods.com). At Flektor I actually started the backend in Lisp. At first ACL. Then they wanted thousands per server -- haha. Then we ported to CMUCL. But there were no libraries, and those we had were buggy. Even the MySql integration was buggy. The last thing you want is a flakey database library.

We switched to Ruby. Sure ActiveRecord was buggy too, but in a totally different way. The bugs didn't crash it, or put weird data into the tables -- they merely generated sloppy or incorrect queries (this was 2006). I could spot these and work around. And there were libraries for a LOT of stuff. Fixing bugs in the libraries was easy too.

Ruby also seems to have been designed as a practical language. There is a bit of distain in the Lisp world (or used to be) for I/O, as if it's dirty. Look at Scheme, it doesn't even have I/O in the spec (or didn't last time I looked). I/O is inherently a side effect, which to the functional thinker is BAD! Well I have news. Writing real programs is all about I/O.

From the late 80s through the early 2000s Lisp was my language of choice. The post author went through many of its advantages -- mostly true. I even went so far as to write an entire compiler and environment (a several man-year endeavor) to design two different runtime oriented dialects called GOOL and GOAL used in 8 Naughty Dog Crash Bandicoot and Jak & Daxter games. All 30-60 FPS action games -- 40 million copies sold. All written in Lisp! (more or less)

Eventually, it was Ruby that got me off Lisp. It does most of what made Lisp great, and the support factor is huge. There are clean standard libraries for everything, the garbage collector is good (the one in ACL is was so awful and dated -- I last used it in '07 -- you pretty much had to turn it off.

I miss the S expressions and the macros. But you can do most macro like things with a good block expression in Ruby, and you can even do auto-generated macro like functions with strings. It just isn't as elegant as Lisp.

The Ruby class system is a bit baroque, but it's actually better in many ways than CLOS, which suffers from being too dated. In Ruby you can do a lot of very cool things with extend and include. It's just a slightly different way of thinking.

The implementation isn't the fastest, but it's good. The Lisp implementations were all clunky and felt like 80s codebases. Oh wait, they are.

Support. The rate of change in Ruby is 1000x that of Lisp. Some new website has an API -- someone writes a Gem immediately. In Lisp you don't even have a really standard networking library!