Skip to main content

Game Development Is (Not) For Everybody

Submitted by kmeisthax on Mon, 01/28/2013 - 01:30 in Rants

One of the more frustrating facts about the game industry is it's core conceit of being a fundamentally elitist, hierarchial space where the voices of people not actively participating in "serious" game development are marginalized or dismissed. The word serious is in scarequotes particularly because it's a meaningless distinction based on social class rather than on any form of merit. A game developer isn't "serious" because they create better games, they're "serious" because they have the utterly useless distinction of having a licensing agreement with a console manufacturer or a distribution agreement with Steam. It's not a mark of merit or achievement but a class signifier for how much a stale, fetid social hierarchy values you.

I've chosen "serious" in particular because it's rooted in the bureaucratic nonsense that console manufacturers use when deciding what indie games they'll allow on their platforms. Game console manufacturers go to great lengths to protect their systems from the evils of open development, and that includes policing what developers are allowed to develop software for their systems. In order to get access to the average game console development SDK, you need:

  • Commercially zoned office space
  • Financial data proving you possess a minimum amount of liquid capital
  • Adequate security systems to protect the SDK
  • Proof of a game already in development
  • Preferrably, a past ludology with high Metacritic scores, publisher backing, and anything else to prove your "seriousness"

This is just to start: there's plenty of other bureaucratic nonsense, arbitrary fees, and other bullshit along the way. The purpose, like any other rigid class hierarchy, is to enable a very small group with large amounts of power or influence to control others with that power and influence. The purpose of classes is to artificially divide people by making them invest their identity in a system that doesn't even need to exist. The class of game console manufacturers is extremely small; only three companies control this space. Below them is the class of "publishers", then the class of "retail developers", and then the class of "downloadable developers". Each class going downwards is bigger; thus, being in a higher class confers a greater sense of exclusivity and investment in your identity in this hierarchy.

So you'll notice that all of these classes are ultimately "licensed developers". Below these are the outcaste of this development hierarchy: those who don't possess secure office space and enough capital to buy their way into the system. These are the people who, officially, aren't allowed to make games that run on a particular system at all, and are technically prevented from doing so. This creates a need for a hacking community to open the system up to unlicensed development. But this doesn't actually fix the problem. Most game developers aren't actually interested in writing homebrew software; if they aren't licensed on a particular platform they'll just move to another one that will accept them rather than try to hack around the system. (This used to not be the case, but console developers have gotten better at breaking unlicensed software and they now have the DMCA to beat people with.)

The one thing system hacking does enable, though, is breaking license authentication, i.e. pirating games. This isn't because there's anything inherit in license authentication that requires closed development, it's because the console manufacturers design the systems such that hacking the system for homebrew gives you 90% of what you need to pirate games. Compare this to things such as the anti-piracy systems for movies, where a Blu-Ray player will happily accept video on a BD-R, but commercial titles can license better DRM technologies to prevent users from copying the movies off the disc. It's not the best system - I don't like anti-piracy systems at all, mind you - but it at least ensures that we don't get this tacit agreement between homebrew developers and pirates that crops up every time someone finds a security vulnerability.

So recently news got out that the 3DS might have been hacked, and while no hacks are actually available in the wild, independent developers are already afraid that it will mean the death of the 3DS as a platform for independent games. This is complete nonsense, of course (PC is arguably flooded with independent games despite being extremely easy to pirate on) but the nature of the class hierarchy ensures that developers will think that open development leads to piracy.

There's bigger effects than this though. The hierarchy of game development has a parallel hierarchy of game development tools, because tools vendors also have to get licensed as well. At the base you have a very small set of tools provided to you by the console manufacturer - their SDK, which is mostly a middling C compiler, a crappy C++ compiler with loads of bugs (who the hell still uses Metroworks!?), hardware documentation, some standard file formats, and an API to call into the system/hardware with. That's it. If you want anything more, you have to find tools elsewhere. Now here's the fun part: because it's a proprietary SDK, there's a class division in tools, too. "Professional" tools like Unreal Engine have official ports to every platform on the planet, because Epic is a licensed developer for all of them, and thus it's easy to use Unreal Engine in a game on a closed platform.

The story with tools not made by licensed developers is different. They generally can't maintain ports for closed platforms because there's no public SDK; the work required to port the tool you want to use falls directly on you. And not everything is made to be easily ported. SDL is a simple abstraction layer around various platform dependent APIs which makes porting games easier; it's designed to be ported and it has ports to absolutely everything with a public SDK. But if I want to use Python, I have to spend a lot of my development time porting the Python runtime over to my target platform. Worst off, this useless makework gets duplicated over and over again with each new developer that uses the technology. You can't necessarily contribute the port back upstream because game console manufacturers want their SDK to be secret, and they don't let you release code that calls their APIs.

The result is a form of tools elitism, where developers using hard-to-port tools are seen as somehow inferior or less skilled. This is obviously untrue; Minecraft was written in Java with LWJGL but it's still a very good game. But Java is a very heavy technology not designed for portability, so it has a reputation of being a bad game technology when it's really just the case that nobody uses it.

There's a problem with this though: the tools that are the easiest to get to (C and C++ compilers) are also the crappiest to develop software in. C was designed in a simpler era and has plenty of stupid limitations that don't work in this day and age; C++ is an extension to C that adds a large amount of generalized abstract nonsense to the technology. In either case, making a game with C or C++ is very difficult if you don't understand every bit of the technology. It's not newbie-friendly. You could use any other language, but again, if you can't port it you're not a "serious" game developer. Likewise, there's plenty of game-making software out there designed to be pre-built engines for certain kinds of games. But, again, they're very heavy technology with no official support for certain platforms, and thus they aren't suited to "serious" game development.

This forms another way that prospective game developers are shut out of the marketplace. The expectation is that before you make games, you're supposed to learn these really difficult to understand, low-level technologies, or spend a bunch of money on the small handful of really expensive tools that are available for these stupid closed platforms. It's all absolutely crap and only exists to keep people out of game development.

Why does this matter? Because games are supposedly art now, at least as far as the US Supreme Court is concerned (and only because a corporation happened to be on the right side of the debate for once). And in other art fields the barriers to entry have been dropping for a long while now. Consumer grade video recording has been available for years now. Musical instruments aren't hard to acquire and learn. Writing books has been viable ever since the widespread adoption of public education and the resulting increase in literacy rates. Games on the other hand are getting harder to develop because we insist on more complex technologies and bureaucratic nonsense. Twenty or thirty years ago game development was two guys sitting in front of a ZX Spectrum trying to get it to do full-color animation. Today it's a massive army of hundreds of art school graduates working insane hours to churn out art for the next generic brown modern war FPS. The budget for your average non-"indie" title just keeps going up and up just for the sake of "photorealism" (i.e. pushing out competitors in the market). This is not art.

But worse, if we go to the "indie" side, we start to see an ingroup/outgroup behavior developing, where everything that's indie has to be a self-important parody of itself and everyone is extremely quick to tear on anything that gets publisher backing. They are defining themselves not so much as a positive, inclusive development community, but soley as the opposition to the psuedo-realistic modern shooter consensus that's currently dominating the market. Fortunately, the indie community is still very fresh, so there's an opportunity for progress here, too, if the indie community can grow out of it's "retro pixel art super self-important" mentality into something greater.

And that's not even to say that retro pixel art is bad. Sometimes it's necessary, like in Minecraft where it helps cover up the aesthetic problems with the large voxel size it uses. And sometimes it can be beautiful, if you get a good artist on it. But I see a lot of indie developers jumping to retro pixel art for the sake of necessity or even laziness rather than doing something good with it. This would normally be just a chip on my shoulder, but we run the risk of defining ourselves with this art style. If "indie game" means "retro pixart game" then the independent development community will find it harder to make forward progress.

I'm not sure if I'm 100% accurate with any of this, but this seems to be my general feeling with the game industry today. The ideal state I want is the state that regular software development exists in. Imagine if non-game software development had the same rigid class hierarchy nonsense that game software does, it would be unworkable. But we don't, we have an environment where some guy's set of tools he wrote and posted on github are on the same equal footing as a large Free Software machine like GNOME or KDE. And that's ultimately the most healthy environment for programming literacy.

game development