Weekly Links #49: code complexity edition

With all the stuff on my mind this weekend, I basically forgot to work on my newsletter at all. But better late than never.

Continuing on the topic of programming languages from last time, Shamus Young argues in The Escapist that videogames need their own programming language. And while he makes some excellent points as always, I think he's misplacing the blame. Like here:

[The C programming language] was created in a world where software was less complex than it is today. Your typical AAA game of 2014 will be thousands of times more complex than entire operating systems of 1972. Consequently, the language is focused on saving memory and CPU cycles, and not focused on helping the coder manage terrifying levels of program complexity.

Well, see? That's your problem right there. Modern software is insanely complex. More complex, in fact, than anything else the human species has built. No machine with moving parts ever has millions of components. NONE. It would fall apart the moment you turned it on. But in software we make it happen just because we can — the worst possible reason.

Or so we think. How many hours of your life have you lost to crashing apps, crashing operating systems, lying servers, flaky networks?

Look at it this way: WordPress, the software powering No Time To Play, has nearly 330K lines of PHP code at this point. By way of contrast, the most complex systems I worked on had 15K lines each — an intranet and a professional e-commerce platform, respectively. Go figure.

At least the WordPress team focuses on stability first. And updates still break websites with alarming regularity. What can you expect from software 10-20 times as complex as WordPress, and written in lower-level languages to boot?

(As an aside, you might point out that lines-of-code is an iffy metric for software size and/or complexity. But I say other metrics are even more iffy. Each line of code is one operation the program performs. It doesn't get more simple than that.)

Speaking of that: sure, higher-level languages help. Automatic memory management does, too — it's one reason why I code in Java despite my misgivings. And plenty of games do use scripting on top of a smaller native code kernel, as Shamus Young suggests. It really matters.

But ultimately, we need to simplify. We need to do less. Check your greed and settle for the 80% of features you can get with 20% of the effort. Accept that there's a limit to everything, or else accept that things will get exponentially worse from now on.

On a related note, a Kotaku write-up points out that better graphics wouldn't add anything to a Final Fantasy VII remake. More generally, a well-documented article over on Gamasutra explains why more realistic graphics make games less immersive. It's the same stuff I've been writing about for years, so I won't insist. Suffice to say, someone who can quote from Chris Crawford and Johan Huizinga with equal ease earns a lot of points in my book.

Last but not least, via Techdirt we learn that EA now regrets the way they've been treating game studios. What do you know, the ultra-short-term thinking of corporations is coming back to bite them in the ass after all? Who would have guessed... apart from just about everyone who's been warning about this for a long time?