A look at the lowered barriers that have changed game development
When Panic recently revealed their upcoming experimental handheld, the Playdate, community feedback was all over the place. A few folks used it as an opportunity to lament the “nightmare of capitalism”—I trust none of them will be upgrading to the new Nintendo Switch. Personally, I thought the Playdate looked like a fun alternative to occasionally letting my kid see my phone, but the super limited game releases might be a deal-breaker for me. Most game devs, however, were tripping all over themselves to find out how they might design and develop something for this emerging platform while the designing and developing was good. Since that time, disappointments seem to be piling up. I’ve observed as one creator doesn’t want to be restricted to Mac OS, another doesn’t want to choose between coding in C or Lua. The list goes on.
I didn’t realize why this stood out to me until I received a post suggestion from our friend Charlie Cox on the subject of how “access” has impacted game development. He and I were both around (perhaps not developing yet) at a time when any means of creating one’s own video game was rare and wonderful, albeit typically painful by comparison to anything most of us have to do today. I hesitate to use words like “entitlement” to describe modern developer perspectives, but I worry we sometimes forget just how good we have it.
A history of barriers in game development
I enjoy reading about early game developers and tales of the indies who first reached players with the whole deck stacked against them. Gamers at Work, Masters of Doom, and Jordan Mechner’s development journals all offer eye-opening glimpses into the earliest days of spare bedroom game development. The superstars of this era were the exception to the rule, overcoming markets flooded with expensive hardware, choices between slow languages and painful ones, and technology that moved too quickly to stay committed to any platform for long. Graham Axten has a great article at Retro Games Collector about his old and new attempts at game development on the Commodore 64 in which he sheds light on some of the pain points of the era’s equipment.
“I chose the C64 after reading about a recent price drop and an influx of new cartridge releases which promised to give the C64 a new lease of life,” writes Axten. “This didn’t turn out exactly as Commodore had planned though, and it wasn’t long after I first owned the machine that the 8-bit computer scene gave way to the 16-bit computers and consoles.” Unfortunately, Axten’s troubles extended beyond hardware choice.
“Like all 8-bit computer owners, my first programming attempts were in the BASIC language, but I soon grew frustrated that I couldn’t make the type of games I wanted to make as BASIC just wasn’t fast enough,” says Axten. “And so…I taught myself the basics of 6502 machine language.”
If the mention of machine language doesn’t make your heart beat a little faster, skim this introduction to machine language at Atari Archives to see what these souls were up against.
Those that endured and developed a viable game for the machines of the time had no obvious place to take it. It would still be a long time before huge central online game stores would launch, meaning retail was still king. C64-Wiki maintains a list of over a hundred publishers that were likely more harm than help for early indies, capable of sourcing their own talent, bundling games in colorful packaging and whisking them off to specialty store shelves, or in some cases, distributing the game code in magazines and books for determined users to type in themselves before playing the games.
Things only got weirder during the console wars.
Most gamers anywhere near my age have fond memories of the Nintendo Entertainment System. The NES is largely credited with saving us all from the notorious video game crash of ’83. Unfortunately, there’s a strong argument that they achieved this by locking down the publishing process to a point that third party developers could barely function. Gabe Durham writes on the process in Bible Adventures from Boss Fight Books.
Typically, the process went like this: LucasArts approaches Nintendo with Maniac Mansion, taking care to remember that they as a third party developer are only allowed to release five games with Nintendo per year. Nintendo accepts the game but requests (demands) content changes, and brokenhearted developers like Crockford comply. Once Nintendo is happy, they set the release date, choose the number of cartridges to be manufactured, and then manufacture the cartridges themselves, selling the cartridges back to LucasArts at a high price.
Durham also points out that Nintendo controlled the primary hype vehicle, Nintendo Power magazine, and that the game would be NES exclusive by necessity for at least two years after release.
Small developers generally couldn’t find a way to make development for Nintendo consoles lucrative and simply moved on. Atari, who created its subsidiary Tengen to publish titles on the NES, didn’t give up so easy. In 1988, Tengen tricked the Copyright Office into turning over the code for the 10NES lockout chip which it used to reverse engineer the system and distribute its own unauthorized NES games. Nintendo naturally sued Atari and Tengen leading to a settlement that left Tengen to distribute unauthorized games, but also allowed Nintendo to pressure retail stores not to accept them.
As consoles increased in processing power and demand, up went brand new roadblocks in the form of specialized “dev kits,” many of which are still rarer than unicorns. Not just anyone could get one; manufacturers struck up deals with select development teams, usually as part of airtight contractual agreements and in exchange for good money. In the case of Nintendo’s successor to the SNES, the Nintendo 64, the third party deal didn’t sound much better than it did in the 8 or 16 bit days, and the costs were even greater than before in the form of a variety of new hardware tools designed to complete development work. N64 development hardware has become the subject of much fascination and study—and you can still get your hands on a few items today. It may be due to these headaches that, as Ben Gelinas of Edmonton Journal put it: “There were more than 200 third party games released in North America. And most of them were garbage.” 200 is actually not a big number for a console’s entire run.
Dev kit hardware remained a major component of console development even as late as the Nintendo Wii U’s lifecycle.
Breaking down the walls
The eventual opening of the gates into viable game development was gradual and had several catalysts. A reasonably level playing field required not just a leap forward in technology, but a significant advancement in manufacturer philosophy as well. With more than a decade of momentum behind the top hardware companies, ample computing power in the average spare bedroom office, and emerging markets for indie services, new territories took shape in the industry where just about everyone could win.
Certainly, by the early 2000s, hardware manufacturers were aware of the potential of independent developers. PC development steadily showcased the talents of these outsiders throughout the console wars, but mainly in the form of mods, hacks, and self-distributed games that couldn’t reliably gain traction. This is not to discount the incredible era of FLASH games—that would be a fun feature article all its own—but it more likely further illustrates that the indie of the time had so little opportunity to make some pocket change, they were frequently content to make games for fun and the enjoyment of the community. Microsoft did more than observe; they set about creating a downloadable development kit, capable of running on a wide variety of PCs, and placed no major limitations on who could use it. With digital game licensing picking up speed, there was no reason not to open up virtual shelf space to anyone capable of sitting a product there.
Microsoft’s accommodation of indie developers represented a crucial recognition from the industry, not only that everyone stood to gain from wider access to players, but that the industry’s anointed developers and artists didn’t have a monopoly on talent. Other influencers took notice, and the dams began to burst.
As Microsoft worked to bring console publishing to the masses, Valve worked diligently on perfecting its own digital storefront, Steam. A centralized store and game launcher solved several technical distribution issues inherent in selling its games and keeping them up-to-date, and it didn’t hurt that this approach blew away previous retail margins. Valve saw so much potential in this model, it welcomed third party developers to do business in its store in early 2005. The sky was suddenly the limit for countless independent creators.
Increasingly, the focus landed on services and products to provide indie developers with every conceivable advantage. This meant tools, libraries, and even full game engines with realistic price models for teams and individuals on a shoestring budget. Open source projects like Blender and GIMP surged in popularity. Product teams that had previously catered to triple-A teams and major publishers had reason to scramble to reevaluate their strategies.
To the credit of Epic Games, the studio was an early believer in creators among the general public. Modding and content creation for series like Unreal Tournament was considered vital to its community relationship, and an early version of the Unreal Development Kit was made available to community tinkerers during the third version of the Unreal Engine. Later in 2008, Epic provided a free limited license for developers to publish and profit from their games. Unity would follow suit, announcing its first free license in 2009.
To round out the movement, an indie business-to-business space opened up, in which the community sought to solve its own problems. Clever developers began to focus on tools and frameworks to improve the quality of life for indie creators. Within a short period of time, sufficient tools existed not just to allow indies an opportunity to compete, but they could do it on nearly any platform with nearly any method they preferred. Publishers emerged from nothingness to compete with traditional publishers and ensure that indie teams had help on the marketing and distribution side, if they chose. Teachers, mentors, authors, and other content creators can earn a die-hard following by making technical skills accessible for learners. By the beginning of the current platform generation, triple-A game industry folks could occasionally be heard daydreaming about “going indie,” and some of them do.
The rise of indies
Indie access has resulted in huge benefits for everyone involved. Developers, of course, gained access to platforms and audiences they once only dreamed about. Players experienced unique projects traditional publishers never would have approved given the opportunity to veto. Console manufactures and digital storefront keepers earned cuts of indie hits that met or exceeded the sales of major budget games with relative frequency. For the first time, a successful game jam prototype provided a potential business opportunity. Young self-taught creatives could pursue their lifelong dreams without picking up and relocating to one of the elite few cities. Platforms that don’t sufficiently accommodate indies no longer look exclusive; they look foolish.
While I don’t know what’s in store for the Playdate, I know that they’re selling yellow coasters if they don’t create at least a semi-open marketplace alongside the curated seasonal experience they’re currently advertising. I don’t even say that as someone particularly interested in developing for it (so far, I’m not). The modern expectation of a gaming platform includes openness and variety on a level not easily maintained if you’ve hired a bouncer and given him a developer guest list. This is good news. It means gaming has become a medium of its own in a truer sense than before, and it’s become less of a collection of mass market playthings designed in a high-rise conference room.
Photo Credit: “Z80 Assembly Language Programming” by Bill Bradford is licensed under CC-BY-2.0