End of an Era

Crawford's work is worthy of study, as is the causation for why he experienced external failure. It embodies the "simulationist" aesthetic of game design: given enough modelled parameters, something emergent and interesting will happen. This was a trend of the 20th century: computers were new and interesting, and simulations did work when you asked them to solve physics problems and plan logistics. Why wouldn't it work for narrative?

But then you play the games, and they're all so opaque. You have no idea what's going on, and the responses to your actions are so hard to grasp. But if you do figure it out, the model usually collapses into a linear, repeatable strategy and the illusion of depth disappears. You can see this happening from the start, with Gossip. Instead of noticing that his game didn't communicate and looking for points of accessibility, he plunged further forward into computer modelling. The failure is one of verisimilitude: The model is similar to a grounded truth on paper, but it's uninteresting to behold because it doesn't lead to a coherent whole. It just reflects the designer's thoughts on "this is how the world should work", which is something that can be found in any comments section.

Often, when Crawford lectured, he would go into evo-psych theories to build his claims: that is, he was confident that the answers he already accepted about the world and society were the correct ones, and the games were a matter of illustration. He was likewise confident that a shooting game would be less thoughtful than a turn-based strategy game because the moment-to-moment decisions were less complex, and the goal should be to portray completeness in the details.

I think he's aware of some of this, but he's a stubborn guy.

This is evident in his description of programming in his later years:

Time and time again I would send my friend Dave Walker an email declaring that Javascript (or something else) was utterly broken, incapable of executing the simplest program without errors. Dave would ask to see the source code and I would present it to him with detailed notes proving that my code was perfect and Javascript was broken. He’d call me, we’d discuss it, and eventually he’d say something like, “Where did you terminate the loop beginning at line 563?” There would be a long silence, followed by the tiniest “Oh” from me. I’d thank him for his help and hang up. A week later, I’d be fuming again about another fundamental flaw in Javascript.

Many of us are stubborn and will work hard and long, without much positive external feedback, under the assumption that our vision is correct and the audience, if one even exists, is wrong. Much fundamental progress has been made this way: Faraday, Einstein, Jobs, etc. But of course many times one simply is wrong and refusing to see it means throwing years away, and whatever else with it (money, relationships, etc.). It's a hard balance, especially for the monomaniacal without much interest in balance. Finding out how to make solid (public, peer-reviewed, evidence-based, whatever) incremental progress towards the paradigm shift seems to be the way if one can manage.

That quote about JavaScript is... huh. I do not understand how you can even begin coming to the conclusion of "JavaScript [is] utterly broken, incapable of executing the simplest programs without errors" when obviously, JavaScript (which I do not like, by the way) is productively used on a large scale (even back then), and constantly under scrutiny from programmers, computer scientists, language designers... it's just baffling.

It reminds me of when I was around 10 years old or so, maybe slightly older, and playing around with Turbo C (or maybe Turbo C++) on DOS. I must have gotten something very basic about pointers (which were new to me at the time) wrong, probably having declared a char* pointer but not actually allocated any memory, leaving it entirely uninitialized, and my string manipulation failed in weird and interesting ways (since this was on DOS without memory protection, you wouldn't get a program crash like a segmentation fault very easily, instead you'd often see "more interesting" corruption).

Hilariously, at the time I concluded that the string functions of Turbo C(++) must be broken and moved away "string.h" so I wouldn't use it. But even then I shortly after realized how insane I was: Borland could never sell Turbo C(++) if the functions behind the string.h API were actually broken, and it became clear that my code must be buggy instead. And remember, I was 10 years old or so, otherwise I don't think I would have come to that weird conclusion in the first place.

Nowadays, I do live in this very tiny niche where I actually encounter not only compiler bugs, but actual hardware/CPU bugs, but even then I need a lot of experiments and evidence for myself that that's what I'm actually hitting...

>I do not understand how you can even begin coming to the conclusion of ...

Obviously he's not serious, he's playing the part of the out of touch old man.