As engineers move into senior roles (title dilution not withstanding—”senior” here means many years of practice), their work becomes less and less about writing code all day. It’s more about judgment than logic. They’re shaping systems, guiding teams, making decisions that ripple through architecture, culture, and future projects. They’re solving fewer “how do I write this” problems and more “what’s the right thing to build and how do we build it responsibly” problems (note the alignment of this statement with LLM-assisted programming—a different topic for another time).
So it’s strange—honestly, absurd—that when interviewing for these roles, we still reach for the same tired approach, typically some combination of live coding, whiteboarding systems design, random technical questions, and/or rushed hypotheticals. As a proxy for real conversation, it’s a worn-out strategy for predicting whether someone is right for the role.
The Interview as Performance
For seasoned engineers, technical interviews can be a challenging format for learning anything useful. It’s a performance—a show of nerves and endurance rather than ability or judgment. When you ask someone to rebalance a binary tree or walk through a caching strategy in an interview, what you’re really asking is how well they can adapt to an artificial environment. Can they quickly decode what’s expected? Can they perform under pressure? Can they think out loud in the “right” way?
That might be helpful if you’re hiring stage actors, but for thoughtful, accomplished engineers who are used to solving real problems over weeks or months, it’s just noise. Worse, sometimes it’s a power move, especially when the candidate is very senior. In that situation, throwing down technical puzzles isn’t about assessment—it’s about control, and it’s toxic.
Why Do We Keep Doing It This Way?
Because it feels fair—or at least, it feels standardized. Everyone gets the same kinds of questions, the same time limit. It creates the illusion of objectivity. But fairness isn’t the same as insight. Just because something is easy to score doesn’t mean it’s meaningful.
There’s also inertia. We’ve done it this way for years, it’s how the big companies do it, and isn’t it reasonable to expect everyone to know the same things? But that’s bias, not purpose. At best, it reflects a narrow definition of engineering competence. At worst, it’s just lazy hazing.
It’s not easy to get off the stage and into the real world. It can be intimidating to really talk shop with someone you just met, especially a battle-hardened senior engineer. Asking questions where you don’t already know the answer takes vulnerability. The standard bag of tricks offers comfort and control.
Don’t Ask Trick Questions—Talk About the Work
Real signal comes from lived experience. What did this person build? Why that way? What broke? What would they do differently? What tradeoffs did they make? How did they define “done”?
If you listen with interest and curiosity, you’ll get more insight from a single war story than ten rounds of technical tests or whiteboard sessions. Ask what failed in production. Ask what tough call they had to make. Ask what they learned. If the conversation is honest, you’ll come away with a real sense of how they think and lead.
If your team isn’t equipped to have that conversation—if they need a script, actors and a theatre instead—then the problem isn’t the candidate.
Koster is one of our industry’s most credible designers. His contributions to MMORPGs, notably Ultimate Online and Star Wars Galaxies, are seminal, and he has been a steady design influence for many years, whether speaking at industry conferences, his blog (it’s been around forever), or his books, especially A Theory of Fun for Game Design (a delight).
On the heels of a successful new Kickstarter campaign, Stars Reach is starting to look as if there is more there there, and it’s the most excited I’ve been about an MMO in years. Originally announced last June, Koster and team at Playable Worlds have been full speed ahead with dev blogs, pre-alpha tests, and a YouTube channel.
The game is a single-shard sandbox MMORPG with strong procedural elements, thousands of planets, spaceships, space stations, destruction, rebirth, housing, and ecosystems running in the background (planets have health bars that can drop to zero!). Much to my delight as a long-time Unity developer, it’s using Unity.
There is an inevitable comparison here to No Man’s Sky, but the approach appears quite different. Stars Reach is more focused on creating a collaborative, living galaxy of sorts, with a deep skill tree and a horizontal progression system. There is a broader simulation system at work, too, with community-driven goals and cooperation at the core.
I can’t help but feel that something pivotal lies in the direction of Stars Reach. While having a clear structure and a predictable gameplay loop is fundamental to most video games, marrying that to the effects of fun, well-executed dynamic environments and emergent behaviors on choices and outcomes is a tall order. Stars Reach is getting a complex weather simulation, on top of allowing players to modify and destroy elements in the game world (using cellular automata, not voxels), purportedly without lasting negative consequences.
It will be interesting to see how it all shakes out. Koster seems fully aware of the challenges of a deep sandbox. This is definitely a project to follow as it moves toward release over the next few years.
Brad Feld once wrote a little gem called Something New is Fucked Up In My World Every Day. It’s an inspirational reminder that the way out of your problems is through, and that you don’t need to look far to discover how insignificant your significant woes may be. It also reminded me that sometimes problems don’t look like problems.
Years ago my mother managed a facility for psychiatric patients who were hoping to eventually reintegrate into society. Once, on a visit home, I was chatting with her in her office when someone knocked on the door, came in with a clipboard and a stack of papers, and proceeded to discuss medication schedules and patients with her.
He was dressed well, articulate, and personable. He introduced himself to me and asked how my visit was going. He enthusiastically talked about how much he enjoyed working with my mother.
After he left I said, “Great guy, mom, he seems like a go-getter”, to which she replied, “He’s a patient—one of our most difficult”. Turns out that he was a well-adjusted fellow most of the time (though delusional about his role there), but every couple of weeks he would have a terrible psychotic break for a day or two. He was bipolar with short, intense manic periods. Without medication, he was much worse, but with medication (and the harmless delusion that he was an assistant at the facility), I had no idea there was a problem there.
Of course there are many ways in which a problem does not look a problem. Since this blog is mostly about video game development, I can think of a few:
Minimized by Something Else. Frustrating level design might be minimized by adjustable difficulty settings. While this makes the game more accessible, it doesn’t address bad core design choices.
Masked by Something Else. Underlying performance issues could be masked by high-end graphics and engaging gameplay. Players may not notice problems until later levels or in non-persistent subsystems, like VFX, that are more demanding on the system.
Compensated by Other Strengths. In a game where story is crucial, exceptional programming skill might compensate for inexperienced story writing, leading to a game with strong mechanics but a weak narrative.
Overshadowed by Larger Issues. Minor glitches might go unnoticed because developers (and players) are more concerned with major bugs that significantly affect gameplay.
Delayed Effects. The long-term impact of crunch may not be immediately apparent, but over time it leads to burnout and high turnover.
Normalization of Deviance. Cutting corners to meet deadlines, such as not fully testing patches or bypassing QA, could become the cultural norm if no immediate issues arise, potentially leading to bigger problems down the line.
Of course you can’t anticipate every bump in the road, but you can concede a bumpy road. In the Eat Me If You Wish parable referenced in Feld’s post, a man whose cave is full of demons makes them disappear by surrendering to their unknown wishes. Another way to view this is that you render your demons powerless by consenting to their nature, rather than fighting to accept them as some sort of intractable finitude.
Consent is powerful. Consent to problems you can’t see. Get comfortable with uncertainty. Allow for plenty of unknown mistakes. And be willing to pivot.
The scene is all too familiar: A whiteboard (real or virtual), a distracted interviewer with little time or patience, and a contrived problem to solve in thirty minutes. The job candidate’s heart races, fingers poised over the keyboard, while the pressure mounts—the syntax, the algorithm, the fear of forgetting a semicolon—until it’s all anxiety and adrenaline, a far cry from the collaborative, iterative process that defines real-world game development.
It’s so… suboptimal. And for senior game developers—battle-hardened by years of thoughtful problem-solving, who have built formidable programming war chests—it’s downright silly. Yet these interviews are all too often an integral part of the hiring process, even at small studios.
The Three Virtues, or Lack Thereof
Larry Wall, the sage behind Perl, bestowed upon us the three virtues of a programmer: Laziness, Impatience, and Hubris. But in the pseudo-crucible of live coding interviews, the virtues morph into darker counterparts:
Artificial Pressure. Laziness in its virtuous form drives programmers to automate, optimize, and streamline, and that takes time. When an interviewer lords over an artificially short deadline that stifles creativity and encourages careless thinking, they are simulating a type of high-pressure scenario that mirrors the worst kind of real-world game development.
Narrow Focus. Impatience, when wielded by interviewers, becomes a blunt instrument. Swift solutions ignore the intricacies of real problem-solving, while senior developers long for deeper discussions about topics that transcend mere code snippets.
Cryptic Trivia. Hubristic interviewers can’t see past their canned code problems, problems they themselves would likely not be able to quickly solve. They scoff at candidates who question the relevance of the exercise or can’t solve it exactly the way they want. Meanwhile, senior developers are thinking: “I’ve shipped games, optimized renderers, battled nasty memory leaks, rewritten entire subsystems from scratch. Why not discuss that?”
False Positives
Imagine a job description that optimizes for the three [non]virtuous qualities:
Of course no one would advertise for such an absurd developer—a false positive if there ever was one—since these qualities would result in highly undesirable outcomes:
Stagnation in problem-solving and inability to adapt to novel challenges
Poorly designed systems, technical debt, and frustrated teammates
Lack of groundbreaking features, outdated practices, and missed opportunities
Broken features, uninspired implementations, and missed UX opportunities
Clunky interfaces, inconsistent gameplay, and spaghetti code
Misaligned goals, communication breakdowns, and missed optimizations
Wasted time on trivial details, missed deadlines, and strained relationships
All kidding aside, it’s not difficult to see how, at best, a live coding interview optimizes for a more realistic false positive: a much more junior developer:
Junior candidates may excel in live coding because they are more accustomed to rapid coding challenges from their academic or early career experiences
Juniors may have more recent practice with coding challenges due to recent coursework or coding bootcamps
Live coding tests sometimes favor memorization of common algorithms or patterns, which junior candidates may have studied more recently
Live coding interviews assess specific coding skills, but senior roles require broader expertise like architecture, system design, and project management
False Negatives
Live coding interviews also have a knack for producing false negatives. This results in:
Missed Opportunities. Rejecting a senior candidate due to to a poor live coding interview means missing out on their potential contributions—you know, the things real senior developers do. They could have optimized code, improved performance, enhanced gameplay mechanics, and mentored others.
Costly Delays. Game development timelines are always tight. A false negative prolongs the hiring process. You’ll need to restart the search, interview new candidates, and onboard someone else. Meanwhile, the game faces delays, impacting release dates and revenue.
Team Morale. Imagine the impact on team morale when a promising senior developer is turned away. Existing team members may question your judgment or feel demotivated. It’s essential to maintain a positive atmosphere.
A Better Approach
Studios deserve a interview process that discourages false positives and false negatives, and senior game developers deserve an interview that celebrates their craft, not one that reduces them to code-spewing automatons. Here are some ideas:
Higher-Level Discussions. Replace live coding with an in-depth conversation. Imagine discussing game architecture, engine choices, plugins and frameworks, optimization strategies, workflow, and pipelines. Senior developers shine when they can articulate their vision, share war stories, and debate trade-offs.
Take-Home Projects. Instead of a whiteboard, assign a small take-home project, for instance building a game mechanic, optimizing existing code, or implementing a non-trivial state machine. This mirrors real-world tasks and allows creativity to flourish.
Collaborative Problem-Solving. Conducta short problem-solving session. Sit down with the candidate, present a real issue from a real game, and discuss different approaches. Collaboration reveals teamwork, adaptability, and communication skills—essential for any senior role.
Jaron Lanier has another great piece called “How to Picture A.I” in the New Yorker. He is so good at using simple metaphors to explain complex ideas, and I loved this last little bit:
The science-fiction writer Arthur C. Clarke famously stated that a sufficiently advanced technology is indistinguishable from magic. But that is only true if that technology is not explained well enough. It is the responsibility of technologists to make sure their offerings are not taken as magic.
At the moment, OpenAI appears to be content with offerings that are taken as magic. Magic is exciting. Magic creates drama. Magic generates investment.
I really want to trust Sam Altman, his board, and the optimistic engineering team at OpenAI. Altman comes across as a natural-born CEO—confident, purposeful and thoughtful, albeit with a fair dose of tech-bro. But he is no scientist which, given the stakes, makes me uneasy.
Lex Fridman(01:35:02) There could be major theatrical moments, also. What to you would be an impressive thing AGI would do? You are alone in a room with the system.
Sam Altman(01:35:16) This is personally important to me. I don’t know if this is the right definition. I think when a system can significantly increase the rate of scientific discovery in the world, that’s a huge deal. I believe that most real economic growth comes from scientific and technological progress.
“I wish it need not have happened in my time,” said Frodo.
“So do I,” said Gandalf, “and so do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us.”
J.R.R. Tolkien, The Fellowship of the Ring
Some believe that the video game industry is in crisis due to the spate of layoffs over the last couple of years. It’s not been easy, and my heart goes out to every game developer who has lost their livelihood—it’s a very tough pill to swallow to be let go from a job you love.
But remember, we’ve seen this before. Things cycle and consolidate like crazy in this business. Teams ramp up, then reconfigure or downsize. Companies wax and wane. I’ve seen this many times over a nearly thirty-year career.
“Happiness can be found, even in the darkest of times, if one only remembers to turn on the light”.
Albus Dumbledore
Owing to other commitments, I will miss GDC this month. Frankly, I won’t miss Moscone and San Francisco in March, or how verbose many of the sessions have become. (I still pine for the days when it was held in San Jose!)
But I will miss the faces, minds and hearts of fellow game developers—so many creative spirits in one place—and the random, sometimes deep (often hilarious), conversations that tend to popup right after a session, in a queue for a slice of pizza, in the lobby of the W, and certainly at parties.
And for those a bit too worried about the state of things, I will miss the chance to say: Have hope. Find your happy place. Shine your light—it is still there, through the darkness, I promise you. Keep making things. Keep learning. Keep that delightful creative spirit that lives within you alive—it’s the thing that got you into this business in the first place. Remember your light!
I grew up in a little town in the western part of Kentucky, in a stereotypical farm economy just east of the breadbasket. My family was decidedly rural and we were farmers — soybeans, corn, tobacco, gardens, cows, horses, tractors, fences.
My dad wasn’t especially good at it — his reach often exceeded his grasp — but he managed to hold things together. Farming is as tough as you’d imagine (to quote a friend from high school who is still farming, “the American farmer is the biggest gambler on the planet”). I loved the pastures and creeks and woods, but I hated the all-consuming nature of farm work — it’s an endless amount of very hard manual labor, and I never warmed up to it.
Whether I liked it or not, I was stuck being a “farm kid”, but I had my coping strategies: reading, writing, music, games, electronics and eventually, programming. Books and stories were my first big bulwark against it all, and I was a manic reader of anything I could get my eyes on. In grade school I was a precocious, over-achieving book lover — bored to death and annoying to my teachers.
SRA was a weird bright spot. SRA cards were essentially the gamification of reading, the brainchild of Don Parker, who in the 50’s successfully pitched the system to Science Research Associates Inc., a small Chicago-based publishing company that developed vocational and aptitude tests. (The SRA Reading Laboratory Kit was first published in 1957 and eventually wound up at McGraw-Hill in 1989, where it still lives today, with over 100 million served).
SRA consisted of large boxes filled with color-coded cardboard sheets, each including a reading exercise. A student would work on a card independently of other students, then grade their own answers to multiple choice questions. Correct answers meant moving ahead until you leveled up to the next color.
The reading was short and dull, but it was a glorious grind through the colors as fast as possible. Its foundation was pure behaviorism — the pleasure of moving to a new color, or being sent to “the box” as a reward for some other good behavior.
This is a perfect example of a complicated, rather than complex, system, the epitome of gamification. The ostensible goal is to become better at reading comprehension, but the adaptive response that emerges is to become an “expert” at short-term, rote memorization. It has the effect of training the reader to navigate a complicated space in an ordered manner (“read, test, reward”) — an attention-limiting exercise that leaves little time to explore a richer, more complex space (for instance, “read, discuss, reply”).
For kids like me it was something new to combat boredom, but ultimately it did little to make me more capable as a young reader and thinker. It simply made me specialize, which is what all gamification systems do.
Unfortunately, a lot of what passes for games these days, especially on mobile, are much more like gamified apps. These games sacrifice complexity for task completion, choice for selection, and meaning for mastery. Skill is purely a function of correct responses rather the deeper learning that accompanies a well-designed risk/reward game mechanic. This is not unlike the problems inherent in Social Media, as discussed in this wonderful piece by Jordan Greenhall. Cherry-picking from the article:
In a truly complex environment, we are always empowered (and indeed often required) to generate novel (creative) actions in response to perceived circumstances. In other words, our field of choice is unbounded and, therefore, symmetric to the unbounded field potential of the complex system in which we are living. We are thus challenged to and trained to improve our responsive capacity to complex circumstances.
In a complicated environment, we are ultimately engaging in the very different mode of simply selecting the “right” or “best” action from a finite list. This is an optimization game, and while it can be extremely useful when competing in finite complicated environments (e.g., Chess) it is a capacity that is oblique to creative response. Therefore, again, the basic problem is that meaningful (and widespread) participation in this kind of platform is training our agency away from capacities that are truly adaptive and towards a narrow specialization for particular complicated games.
For the video game industry to mean something beyond profits, we’ve got to get better at generating complex gaming experiences. We must forego the desire to slam together twitchy mechanics in favor of more thoughtful design that brings back the magic of “play”, that improves our players’ “agentic capacity”, as Greenhall puts it:
In the case of complexity, the optimal choice goes in a very different direction: to become responsive. Because complex systems change, and by definition change unexpectedly, the only “best” approach is to seek to maximize your agentic capacity in general. In complication, one specializes. In complexity, one becomes more generally capable.
In order to do this at a meaningful scale, we must first be able to rely on funding sources to give us the time we need to design and implement better games. This means that publishers have to be willing to share more risk than what is typical in the industry right now. Second, we need producers and designers to be more thoughtful and eschew the gamified design tropes that have arisen over the last decade.
If you’re making games for living — whether you’re writing checks or cashing them — start challenging yourself to go back to the days of video game yore when our industry looked a little more lovingly at quality. Ask yourself if a complicated ecosystem, already saturated with hundreds of thousands of gamified apps, needs another one.
Newzoo has mobile gaming on track for an estimated $70 billion in global revenues this year — 51% of the total game market. As a mobile game developer since the early 00’s, I’m hardly surprised — but I am in awe. This is big market.
iOS and Android are stronger than ever as the Coke-and-Pepsi rival platforms, publishing and distribution have re-structured themselves, and thousands of new developers have come and gone since the launch of the iPhone. We’re deep in the throes of a world we tried to imagine almost two decades ago, a world of wireless distribution over large-scale networks comprising a big chunk of the overall game market.
What’s left of the old retail world of physical boxes on shelves — much like video and music — are remnants of a bygone era, nostalgic, archaic, boutique. Video games don’t quite live and die by the graphics sword as they once did, either, by high-polygon counts or texture memory, and the heady days of big-dollar budgets, huge teams and deep pockets to fund them are fewer and farther between. We continue to have higher-performing GPUs, smaller footprints and new display technology. We’ve got plenty of devices and form factors, and we’re doing more at the shader level. In particular, VR/AR/MR/XR are bringing, albeit more slowly than anyone wants to admit, new ways to experience games.
But the fundamentals — the look, feel, depth, mechanics, gameplay — are less a function of technology than they are slaves to the markets that have evolved from the platforms. Big productions and high quality don’t compete nearly as well in this world. Yes, we continue to see small numbers of deeply designed, cinematic-quality games — and lest we forget that Steam has kept PC gaming alive — but they’re not the main stream anymore.
And there’s the rub, because the biggest problem we face is now our biggest market segment — mobile games. I’ve said before that the thorn in mobile gaming’s side is discovery, which is almost exclusively a function of the platforms, which are in turn a function of two things: Free-to-play (F2P), which allows players to play without paying (or with the illusion of not paying) and pushes developers to spend a large part of their time micro-managing monetization, and what I call Free-to-create (F2C), which is the low barrier to entry to game development. By themselves, F2P and F2C are beneficial, desirable, worthwhile. Together, they may be destroying what it means to be a game developer.
F2P
Like its grandfather the game demo, F2P works by enabling players to optimize for avoiding a false positive: It costs players nothing to try before they buy. If they’re in love, they’ll invest time and money; if not, they don’t feel quite so duped or dumped or disappointed. F2P is more sophisticated than dear old grandpa though and relies on a careful in-game IAP (In-App Purchase) plan. Developers must take care to give players the right combination of free and paid experiences unique to the game. Risk/reward mechanics, quantity and timing can be very tricky to nail, and add significant costs to development.
Poorly implemented IAP misses crucial opportunities to make money or, on the flip side, players feel ripped off or manipulated. More than ever, developers must be at the right place and at the right time to become profitable, but for the user, it’s a seemingly endless source of low-risk gaming potential.
F2C
F2C in the purest sense is a wonderful thing — anyone, with some effort, a little money and a reasonable amount of time can design, develop and deploy a game or app that functions like a game. The new developer gets to learn something exciting and rewarding (design and programming), gets the distinction of doing it, and dreams of having a hit.
The platform gets the benefit of massive amounts of content to sell, theoretically for every conceivable taste, desire or need that billions of potential players may have. This makes the platform more popular, draws new players, makes current players stickier and encourages developers to believe that they’re competing for consolidation. The opportunity cost is so low that, not only do novel games emerge from unlikely, would-be developers, the sheer size of the developer base greatly increases the chance of game content that more closely or clearly taps into current cultural trends and preferences. We’ve seen it many times already on both iOS and Android, despite the overwhelming number of games made with shallow or amateurish content.
Where’s the Value?
In the heyday of feature phone games (2001-07), mobile games were mostly P2P (Pay-to-play), developed by professional teams who sold them for a fixed cost — the retail model. This was also the case in the early days of smartphone games.
The charts were more volatile than they are today. There were far fewer games, and players voted with their money up-front. Developers were diligent, and an MVP was closer to a full-on release candidate than a beta release. They still had to do a solid job of writing advertising copy, producing image assets and providing support. They could also price their games higher and had a much better chance of being noticed on the deck. (Development was also more frustrating due to the number of different phones and operating systems and APIs — but that’s another, much longer, discussion).
Back then developers did their best to score coveted first-party deals with device manufacturers, but most either self-funded or had publishing partners who were ready and willing to fund them. The platforms were new and the distribution all-digital, but the traditional retail publisher-developer model worked much as it always had.
Things changed with the arrival of the iPhone. A handful of developers early on saw the potential for massive amounts of traffic via F2P, and their successes attracted more amateurs, which was only possible because of the low barrier to entry — F2C. The platforms flooded with new games, a large number of which were half-conceived or half-implemented, or both. This quickly had the effect of cramming the digital shelves so full that P2P (with some exceptions, like Angry Birds and Infinity Blade, for example) could not compete with F2P.
In fact there was a period — nearly all of 2010 — when an explosion of very good games that would have otherwise been P2P were free with very little IAP. This created a small group of lottery winners — developers who pulled massive traction, bolstered by the new mobile gaming press and incremental improvements to the platforms’ storefronts. These crucial early hits trained players to expect higher-value F2P, but when the smoke cleared developers still had to pay salaries — so they dove more deeply and cleverly into IAP.
Fast-forward to today, where we’re now at over a million active games across the iTunes App Store and Google Play, growing at a rate of hundreds of new game submissions per day, most of which are F2P or have a F2P option in addition to P2P. Practically speaking, it’s absurd. Imagine a million titles in a physical retail store — if you spent just one minute per title reading each description, you’d be trapped in the store for almost two years. (Further imagine that every game on the shelf is free — you can just take it home and try it.)
The result of all of this is that, unlike the old retail model in which developers tended to focus on quality, successful mobile developers had to become masters of low budgets, test markets and market triage, frequent updates, daily engagement with players and of course, IAP. Otherwise they were just playing hit-game roulette. The bottom line is that we now have a mobile genome full of junk DNA whose value, if any, is not well understood. Discovery is still fundamentally broken, and while we have the requisite gaming genres and digital endcaps with featured titles, they’re mostly games whose survival depends on clever monetization models, not quality.
So, where’s the value? For players, it’s whatever is on those few endcaps fronting an endless aisle of other games they will never see (though the aisle serves an important function by creating the illusion of platform power, credibility and trust). It’s a dollar here and a dollar there, and the latest loot crate on sale. It’s not always easy to tell how much fun players are having, but it’s clear they are still under the illusion that mobile games are practically “free”, though “whales” — that small percentage of players who will rack up hundreds, even thousands of dollars in IAP — are ever-present.
In terms of quality, it’s still a race to the bottom, though we are seeing some improvement as the most successful publishers become bored with their large catalogues and over-optimistic about their successes. But publishers still rarely fund anything that isn’t high-profile IP or derivative, and you can’t blame them — the discovery problem and the immense cost of marketing a title into a featured slot or Top 3 list would make anyone risk-averse. (This is not uncommon in traditional games, either, but’s it’s far more profound in mobile.) For self-funded new developers, most still wind up as “one and done” — they make a single game then close up shop when it’s immediately clear they will never recoup their costs.
For professional developers who have the stamina and resources to stay in the game, they’re largely reactive and resistant to re-investing profits into higher quality. They understand what they’re up against. To quote Trip Hawkins from a few years ago, “There really ought to be an institute for studying virtual economies… It’s about thinking about your game like you’re the merchandising manager at Bloomingdale’s. Once you have made a game that has good lifetime value, then you can afford to buy marketing.”
Trip is dead-on, but that kind of reality-check messes with our basic worldview as game developers. We cling to the idea that what we’re doing is magical and novel and creative. Meaning, Mastery, Skill, Flow, Risk, Reward and Story are our prophets, and Fun is our God, but IAP is the Boss and without him, there is no game.
Growing up in Kentucky, I fell in love with video games, one coin at a time, in arcades. There were so many great games that inspired me. Early on it was Space Invaders, Asteroids and Galaxian. I was hooked by the relentless pursuit of a new high score.
I turned over my first million points on Galaga, a game that would become a favorite, not too long after its arrival in our little town.
I was so into arcade games that, after being hired to paint the logo of our new local arcade (that’s me, on the left), every quarter earned from the job found its way back to the arcade within weeks. Of course, the owner of the arcade already knew that’s what would happen.
That jet-fueled teenage competitive streak transformed into a much richer gaming experience by way of D&D. I was already lost to story and plot, improvisation and character when, wet behind my elf ears, I started college. I majored in art and theatre, but spent more time playing D&D and fiddling with computers and coding than in class or acting in plays. I enjoyed being a DM — but I absolutely loved battling wits with other DMs as a player.
I began to think about how I might blend the excitement of twitchy arcade mechanics with something like world-building in D&D, and that deceptively simple thought was what began a life-long relationship with creating and programming video games, starting with the humble TRS-80. The TRS-80, by today’s standards, was an exceedingly modest machine, and perhaps not all that well-suited to video games. But I managed to pound out my first adventure game on it, complete with battle mechanics and stat bonuses, in BASIC. The programming constraints were unimaginable by today’s standards.
I left college with a year to go, dreaming of working in video games. I moved to Indianapolis, Indiana and looked for companies making games, a futile quest at the time. I decided to keep making games on my own while working various other odd jobs for a few years, then went to college again, this time to study mathematics and creative writing. It was an unusual combo — I’m pretty sure I was the only student there doing it, and my advisers didn’t quite know what to think. I’d been a math and puzzle geek since my first algebra class in 7th grade, which was profound and revelatory, almost a religious experience; on the other hand I loved to write, mostly short fiction, and had some talent for it.
I TA’d my last two semesters, including a new calculus class where the professor would use Mathematica in the lab four days a week, while I would work through problems with chalk in hand every Friday from 9 am to noon. I thought it would be a cakewalk — who would want to work problems on the board on a Friday morning? I couldn’t have been more wrong — not only did most of the class show up, half the students from the same course in two other time slots started coming. It turned out that learning advanced calculus on a computer was not an easy thing, and the prof was so focused on the shiny goodness of graphing and playing with equations in software, there was never any time to practice.
After graduation I took a job at one of the biggest tech-like companies in Indy, Macmillan Publishing, developing reference books on programming, networking, and the newest technology on the block, the Internet.
I kept tinkering with games and graphics in my spare time, mainly on Windows. I can’t tell you the number of little games I wrote and programmed, though in all honesty most of them were more like tech demos. But with each new idea, OS version and language/compiler iteration (mostly C), I became more and more interested in graphics, eventually spending as much or more time finding ways to optimize rendering as programming game logic. I became obsessively interested in tools and 3D authoring and rendering, including a brief descent into the magnificent rabbit hole that was the Amiga (which, by then, was no longer even a supported platform).
At work, I moved up, and found myself producing video games in Macmillan’s small software division. We did mid-range and value PC titles and add-ons, and we had some real hits (and plenty of duds, too). I worked on some of the first early 3D games for the lower end of the PC market. I went to my first GDC, my first E3, then back again each year with a half-dozen programming/platform conferences in between. I got to meet stars like John Carmack and Sid Meier. I began to understand how the industry was evolving, what players valued, the different genres, game mechanics, gameplay.
I also played a ton of games on PC and consoles, and from Meridian 59 onward, was hooked on MMOs. A lot was going on both in gaming and with the Internet. Macmillan was willing to take some chances on new business models, and I was in the right place at the right time. We started a new business for distributing add-on levels for popular PC games; RealmX was a highly ambitious, very early attempt at a form of DLC, something now commonplace, but it failed spectacularly. We then created an even more ambitious web product called InformIT, which was arguably the first online collection of professional technical books on the Internet, including books on games. It survives to this day. I’ll never forget the weeks it took us to finalize the first-cut of the data model. By the time we were finished, we had hundreds of sheets of whiteboard paper wrapping every wall in the office.
But by then it was 1999, and I was ready to up my game.
My first job in Silicon Valley had nothing to do with games, but it was a foot in the door. I was hired to help relaunch a large hotel reservations website, both the content system and the server framework. Back then there was no Google infrastructure or AWS like there is today — you had to roll your own on top of other, relatively nascent, software. One of most important things we did was to switch the back-end from Microsoft’s IIS to Apache — a decision prompted by the reality that two full-time, on-call engineers, whose primary job was to reboot the server every four hours, was utterly absurd.
In six months we were done, and by that time I had turned back toward gaming, to a startup in Mountain View. Staccato Systems developed an audio subsystem for the PC that replaced a $27 wavetable chip on sound cards and also was used to create unique audio effects in PC games. I came in with a focus on helping the games side of the business and wound up coding applications to make the core technology accessible and usable by game developers including EA, Lucas and a few others. It was remarkable tech — physically-modeled, logically-controlled audio at a granular level. The engineers I worked with there were absolute geniuses (and there was no shortage of egos), although it never failed to amuse me that, at the end of the day, they were mostly hard-working hackers, like most people who do anything authentically novel in software. Staccato’s technology was first licensed by AC97 Codec manufacturers SigmaTel and then Analog Devices. It was sold to Analog Devices for $30M in 2001.
Around the same time as the acquisition, a whole new game market was starting to make waves — mobile games. I started programming feature phone games and eventually moved into smartphones, around 2007 when the iPhone landed. Companies I worked for, and helped lead, won awards. We brought dozens of titles to market, including high-profile mobile games like Guitar Hero Mobile, Duke Nukem Mobile and Prey Invasion. I started to get a little recognition. I spoke at GDC a couple of times. I was a gameplay programmer, a senior software engineer and engine architect, then a VP of Production, then a CTO. Through it all I was continually amazed by the talent and dedication in the industry, an industry that was going places it had never been!
These days I’m still working on games and tools, but I get to hop around a bit more from project to project. Not long ago I helped bring a wonderful children’s game to Unity/HTML5 and before that spent over a year working on a mobile casino game, right after a couple of years engineering a large framework for performing, essentially, extensive mobile CAD functions in Unity.
There’s almost always something new and exciting to do (right now it’s VR/AR/MR/XR — yes, the acronyms never end!), though there’s nothing like a great new stealth project, or prototype, or a new take on an old shader, or a fresh API. So much to do, so little time! I’m still in love, and I’m comforted by the thought that my best game projects are ahead of me.
“Peaches and cream. You see, dear heart of hearts, everything will be peaches and cream.” She holds up a spoonful. “A toast — I propose a toast! To peaches, cows, and the freezing point of milk.” We tap-tap plastic tips together. I scrape my finger across the spoon-skin dugout part of my head. I drop the spoon, no sound to speak of unless I was a little dust mite or a needling meddler-fly pausing to throw up on an infinitesimal universe.
“Pooky — it’s gone,” I say to her, suddenly out of my mind.
“Well, just ask for some more, silly goob. I don’t know what I’m gonna do with you!” She spot-swipes a tiny piece of sex-starved peach from her chinny-chin-chin; oh yeah, she knows how to do just that but she doesn’t know how I could care less. And scrolls her eyes, her slow motion slot-machine eyes until two peaches rest for a moment, barely off the mark from each other, glow-glower-ing.
“Pooky-pooh — it’s gone.”
“Now what’s gone, ’cause it’s not the creamy-cream-cream I can see that now can’t I?” She fakes a paused grin then looks serious, then pauses, then seriously grins.
Grasping her hand I paint it along the back of my head over the concave lack-of-a-knob. “Well do you feel anything? The growth — do you feel it?”
And she gets to be astonished. For once in her life she gets to witness a miracle, a tap-tap-tap into something that isn’t sponsored by the next commercial after an evening’s corn-fed dinner-sofa diet. “Well, what does this mean?”
This does not make sense. I had a tumor there, a funny little sonofabitch thing that crumpled my curses up like newspaper (the obituary section) as I obsessed over how fast it takes rigor mortis to set in, all the while sucking pity from her and the whole family, me (me!), the attention-getter and newly sanctioned medicator, cramming in night-light walks along Kalimdor Road with no regard for splinters, bones, bears, cats, disease or losing myself in some fuzzy logic.
But I can feel the color returning to my face already, I don’t get off that easily. So I straighten, take stock of the room — the fine fakety-fake oak counter, the fuzzy green pool table (I wonder if felt dust mites are green), the sudden lack of ping-pong ball pops and the squelch of old video games, the fluorescent ceiling-tube flicker now swinging slow-mo like a cape around my neck, man, like a swoosh–
“Excuse me — well, I thought so!” A tasteless, familiar voice, behind me. Pivoting around in my seat (I still have motion balance, you know), it’s a surprise, it’s him. “Doctor? The thing, in my head! It’s gone!”
“Now that’s just not funny, I’m not here on business. My son and I are trying out the new ping-pong tables. He’s a student here, you know.” The doctor is animated and that’s odd, really odd but he cheshire-cats his words. He’s wearing a university sweatshirt and shorts. He beams, then contorts for a second and beams again. “Serendipitous, I tell you!”
“But, Doctor, Doc — Pooky, tell him. Tell him what’s happened. I’m the miracle man, not the dead man — not the endpoint.”
“Now, now, I’m not on call.”
She scrolls her eyes again, but sideways this time and I’m thinking, I should be concerned about that. “He’s off duty, give me a break, what do you want him to do, cut you open right here on cheap formica? Besides, I’d like to propose another toast — to the doctor, and–” She raises her spoon again and this time I can clearly see the raised plastic ridge from the factory mold on it. Her voice trails off to a murmur and a lactose hiccup.
“Look, son,” the doctor interjects, still grinning as if nothing happened, no miracle, no anomaly, an endpoint, back in the middle. “I came over here to see if you could help me and my boy out. I’m afraid we, well, actually, I did it. I hit the ball so hard it just–” He leans in, “Well, anyway, we still have a game to finish.”
“What?” I said I’m a miracle, an anomaly, not an endpoint, back in the middle.
“A smashed ball. It’s not exactly the first time, but — don’t know my own strength. Anyway, when I saw you over here I thought, ‘there’s my answer’, basta. I can’t exactly return it, but I expect that’s okay with you.”
“Return what?” I’m cold, I shouldn’t be — but it kicks in. Almost shivering.
“Why, the tumor, of course.”
“What?”
“In your head — you know, the little ball in your head
It’s the perfect size
Lucky I have my instruments with me
We can use one of the tables in the lounge
It’ll only take a few minutes, and you’ll be doing me a great favor
I don’t want to quit
I’m winning the game right now — ah, yes, here it is, my saw!
Funny I had it with me, and no need for anesthetic
Pooky-pooh can hold your hand, that always works in the movies
Actually I’d call it a miracle that you’re right here, right now
I’d call it a miracle–“
SRA consisted of large boxes filled with color-coded cardboard sheets, each including a reading exercise. A student would work on a card independently of other students, then grade their own answers to multiple choice questions. Correct answers meant moving ahead until you leveled up to the next color.
