#Dev

Why I Write Games in C (yes, C)

AI & ML Reporter
4 min read

Jonathan Whiting explains his unconventional choice of using vanilla C for game development, prioritizing reliability, simplicity, and portability over modern language features.

Jonathan Whiting, an indie game developer, has made an unusual choice in today's game development landscape: he writes all his solo project games in "vanilla" C. In an era where C++ dominates the industry and higher-level languages like C#, Java, and Go offer modern conveniences, Whiting's preference for C stands out as a deliberate rejection of contemporary programming trends.

The Non-Negotiables

For Whiting, the foundation of any programming language choice must be reliability and portability. Having witnessed the death of Flash—a platform that once hosted many of his games—he's acutely aware of the risks of platform dependency. "I can't afford to spend my time dealing with bugs I didn't cause myself," he explains, emphasizing his desire to focus on creating new games rather than constantly porting old ones to new platforms.

This need for longevity drives his insistence on using a language that will remain viable for years to come. C, with its decades of proven stability and near-universal platform support, offers the kind of future-proofing that newer languages struggle to match. The ability to target multiple operating systems and potentially consoles without being locked into a specific ecosystem is crucial for his workflow.

The Ideal Language

Beyond the essentials, Whiting has a clear vision of what he wants from a programming language. At the top of his list is simplicity. "I find looking up language features, and quirky 'clever' APIs incredibly tiring," he notes. His ideal language would be one he could memorize completely, eliminating the need for constant reference checks that interrupt creative flow.

This desire for simplicity extends to his approach to software architecture. Unlike the object-oriented programming (OOP) paradigm that dominates modern software development, Whiting prefers to handle data as data and write code that fits each specific situation. "I've spent most of my professional life working with classes and objects, but the more time I spend, the less I understand why you'd want to combine code and data so rigidly," he observes.

Performance and Developer Experience

Performance matters to Whiting, but not in the way many developers think about it. He's not pursuing high-definition realism but rather exploring what's possible with modern computers when fidelity isn't the primary goal. More importantly, he values the speed of compilation. "Waiting 10+ seconds is wasteful, yes, but more importantly it breaks my flow. I flick over to Twitter and suddenly 5+ minutes are gone," he explains, highlighting how even small delays can derail creative momentum.

His bug-prevention strategy relies on strict typing, strong warning messages, and static code analysis. He wants bugs to be easier to find through good debuggers and dynamic analysis, viewing bug-hunting as a "huge creative drain" that he wants to minimize.

Why Other Languages Don't Fit

Whiting has evaluated numerous alternatives, finding significant drawbacks in each:

C++ remains the industry standard for game development, and Whiting still uses it for contract work. However, he describes it as "desperately complicated," noting that despite decent tooling, it's easy to create insidious bugs. The compilation speed is also slower compared to C.

C# and Java share similar issues—they're verbose, complex, and tend to railroad programmers into strongly OOP styles that Whiting opposes. Like most higher-level languages, they hide complexity in ways that don't actually prevent it from causing problems.

Go appeals to Whiting significantly. "In many ways it is C revisited, taking into account what has been learnt in the long years since it was released," he says. However, Go's stop-the-world garbage collection poses serious problems for games, where even brief pauses are unacceptable. The library support for games is also poor, and the niche status raises concerns about long-term relevance.

Haxe shows promise, particularly for web development, with good library support and a more appealing syntax than JavaScript. However, Whiting worries about its relative youth and whether it will last.

JavaScript receives particularly harsh criticism. "I marvel that people are able to write big chunks of software in it," Whiting says, finding its loose nature fundamentally incompatible with his desire for reliability and bug prevention.

The C Choice

Despite C's reputation for being dangerous and prone to memory errors, Whiting sees it as the best fit for his needs. "C is dangerous, but it is reliable," he explains. "A very sharp knife that can cut fingers as well as veg, but so simple it's not too hard to learn to use it carefully."

The language's compilation speed is unmatched, and its ability to run on virtually any platform remains as relevant today as ever. The library and tooling support is strong and ongoing, providing the ecosystem stability that Whiting values.

A Personal Choice, Not a Universal Recommendation

Importantly, Whiting emphasizes that his choice is highly personal and not meant as advice for others. "I absolutely DO NOT mean to say 'hey, you should use C too'," he clarifies. His preferences are "pretty specific and unusual," and his extensive experience with vanilla C contributes significantly to his comfort level.

His decision represents a thoughtful rejection of modern programming trends in favor of principles that serve his specific needs as an indie game developer: reliability, simplicity, portability, and minimal cognitive overhead. In choosing C, Whiting has found a tool that, while potentially dangerous in the wrong hands, provides exactly the control and predictability he needs to focus on what matters most—making games.

Comments

Loading comments...