Author: David Lindsey Pittman

Categories
Slayer Shock

The One About Slayer Shock

It’s a delicate balancing act being transparent in game development. I’ve seen friends who had the best intentions speak openly about what went wrong in their games, only to have their words turned against them in the streamlined narrative that their game was a failure and they were a failure for making it. It taught me to be guarded. Mainly for that reason, I’ve never said much about Slayer Shock (Steam user reviews: 55%). It was a dud, and nothing I could say would change that. You can’t mea culpa a game into success. But it’s been 7 years now, I’m not going to damage its sales or my reputation by talking about it. I’ve spent a lot of time reflecting on what happened there, I’ve internalized the lessons and made conscious positive course corrections on subsequent projects. I think I actually have something to say about it now.

Vampires in Nebraska

It was 2015. I was wrapping up NEON STRUCT (Steam user reviews: 87%) and thinking about what my third indie game would be. After spending a year feeling out of my element in level design and writing, I was eager to return to the familiar territory of procedural levels and systems-driven gameplay. The central concept owed a lot to an early version of XCOM (the ill-fated 2K project which eventually shipped as 2K Marin’s The Bureau: XCOM Declassified): a strategy-level campaign game combined with a first-person stealthy shooty game. Then I wrapped it in a Buffy the Vampire Slayer skin and sprinkled on some of my own experience growing up in Nebraska, and that was Slayer Shock. Patrol and protect the town, research the vampires, find and eliminate the vampire leaders. The elevator pitch still works for me, I just wish I had made the game I envisioned.

Sometimes Real Life Happens

Through all of NEON STRUCT‘s development (2014-2015) and into Slayer Shock (2015-2016), I was in the middle of an extended separation and divorce. I shared custody of a toddler. I had no family nearby, and I had somewhat alienated myself from my former work friends after quitting and going indie. I felt alone, and I felt under immense pressure, and I didn’t handle it well. I drank a lot, and I created new problems for myself.

That’s not an excuse for how Slayer Shock turned out, but it is the truth. I still believe there was a great idea at the heart of that game, and maybe a healthier version of me could have made it work. But I was at an all-time low and my heart wasn’t in it.

The Scope Monster

Or maybe I just got too big for my britches. After the modest success of Eldritch and the warm reception to NEON STRUCT, I was starting to feel like I could do no wrong. I had great ideas and I could execute on them. I made games faster than anyone. Could I make a stealth FPS with a strategy campaign layer, built for endless expansion and designed to be played for 100 hours? Of course I could! If anyone could do that, it was me.

And that was Big Mistake #1. I arrived at the idea of endless expansion and a 100-hour play time in a few ways. The first—and more legitimate—reason was because of what happened with Eldritch: the game was successful, and I wanted to add more, but I’d painted myself into a corner with its rigid quest structure. The second reason was a more toxic one: I craved success in all its forms, and to me that meant people playing my game for hundreds of hours the way they did with The Binding of Isaac or other roguelikes.

And this is Big Lesson #1. There are only two ways to make a game that people play for 100 hours. Either you make a game that is So Good that people want to play it over and over, or you exploit players’ addictive tendencies. These aren’t mutually exclusive, but I’d rather not do the latter at all. And I didn’t want to do that in 2016 either, so I accidentally set myself up to make a 100-hour game purely on the strength of its content. Oops.

Big Lesson #2 is: if your game relies on future expansions to be good, then it’s not good now. I built a game infrastructure in which I could endlessly layer in additional content on multiple axes. New levels? Yes! New level twists? Yes! New enemy types? Yes! New weapon types? New ammo types? New research methods? Yes, yes, yes! I’ve got a framework for that! I spent so much time building neat little systems without realizing the cost of populating those systems with interesting content. I shipped Slayer Shock in what I considered to be a finished form, but with big plans to grow it from there. Another way to describe that might be “Early Access”. And then I ran out of money and those plans never happened.

Art Is Hard

After making two games with voxel-based worlds, and especially after hearing Eldritch described so many times as looking like a Minecraft mod, I wanted to step up my art game. No more voxels, I was going all in on mesh geo and dynamic lights and physically-based lighting and materials. I had a vision in my head of the style I wanted, and if you’re familiar with Warhammer 40,000: Boltgun, it was a lot like that; but I’m not a good artist and I extremely missed the mark.

As I was nearing the game’s release, I was talking with my brother about the game, and he said something to the effect of: “Eldritch was simple, but it had a style.” And he was right, but it was far too late for me to course-correct. I guess Big Lesson #3 is to know your strengths and weaknesses. I have put in tens of thousands of hours to be a world-class programmer, a great designer, and a pretty good composer. I could do the same for visual arts, but I’m running out of years here. So if I’m not good at art, maybe a better option than making bad art is making the most out of simple art.

The Grind

The core loop of Slayer Shock isn’t bad per se: sneak around an environment, dispatch some vampires, grab some goodies, and get back home. For one or two missions, it works pretty well. But it quickly gets tiresome.

Big Mistake #2 was my assumption that if replaying levels in a roguelike is fun then replaying levels in a campaign-based game would be equally fun. But there’s a psychological element I hadn’t accounted for. When you replay a level in a roguelike, you know you’re playing it again, from the start, and you’re challenging yourself to do better this time. Roguelikes trade player character progress for player progress. Your character doesn’t get better over time, you do. But if the game takes away permadeath, and you keep playing variations of the same level over and over in pursuit of some unclear finish line, it doesn’t feel like progress. It’s a grind.

I hoped to offset this sameness with level twists, but (see Big Lesson #2), I didn’t have enough of those to make a meaningful difference. And maybe I could have changed the player build model so that players didn’t grow into and then stick with a single loadout for the whole game; but none of that really addresses the psychological element of the game structure. Big Lesson #4 (which is a corollary to Big Lesson #1): if your game asks players to replay content—even if that content is randomized—you sure as heck need to make sure they have a good reason to care.

What Went Right

I shipped a game, and that is a miracle, because every game that ships is a miracle.

Categories
Eldritch 2

Dancing Without a Partner

I teased Eldritch 2 on social media last year, but I haven’t properly announced it. And this still isn’t a proper announcement. That will come sometime in the future, with screenshots and a trailer and a PR agency to do the words good. Please do not write that I have announced Eldritch 2. But I haven’t been shy about the fact that I’m working on it, and that I want to develop it in the open as much as possible.

I buy myself a new Moleskine notebook for every project. Most of them end up unused. Not this one.

So, the three big questions: Why Eldritch 2? Who’s making it? When’s it coming out?

Why Eldritch 2?

Since Eldritch‘s release, many players have asked for multiplayer, and my answer has remained: I originally wanted it to be a multiplayer game, but it would have blown up the game’s very tight (8-month) schedule; subsequent tech and design decisions I made along the way locked it into a single-player structure; and let’s save it for the sequel. Those last words have haunted me for a decade.

The obvious option was to follow Spelunky‘s lead and make a co-op action roguelike. Eldritch was already indebted to Spelunky in so many ways, and the model works. It was always unrealistic to convert Eldritch into a multiplayer game for tech reasons, but if I were starting a new project from scratch, I could conceivably do that.

But then I worked on two multiplayer games (The Blackout Club and South Park: Snow Day!) in my day job at Question. Both of those were developed in UE4, which has very stable netcode (which my own Rosa engine does not have); and still I was reminded how much more complicated everything is when code has to resolve four disparate game states in realtime. Multiplayer makes it harder to make games. Or to put that another way, making a multiplayer game for the same budget necessarily sacrifices a lot of features that are important to me.

So I had kinda sorta promised that Eldritch 2 would be a co-op multiplayer game, but also I didn’t want to make a co-op multiplayer game. And the bigger question in my mind was: why make Eldritch 2 at all? Was I just wanting to relive a past moment of glory? Hoping that the modest success of the first game could penetrate the crowded indie scene? What could I do with a Lovecraftian roguelike immersive sim that I couldn’t just do by adding some free expansions to the original game?

It took a long time and a few false starts, but I feel that I’ve found a way to answer those questions and weave multiplayer into it. I don’t want to give too much away, because it is part of a central mystery of the game, but I’m using the procedural nature of roguelikes in a way that I don’t think I’ve seen done before; and which has the convenient side effect of synchronizing the pseudorandom levels that each player sees. The best analogy I can offer is: imagine the daily challenge mode in Spelunky, where every player sees the same levels on the same day—what if you could also see all the other players running those levels at the same time? And what if there were secrets only accessible on certain days? And what if you could rewind to previous daily challenges, and find those secrets again?

Who’s Making It?

It’s me. It’s just me.

Since 2017, I’ve worked full time with Question, and I hope to stay with Question for years to come. They’ve allowed me to continue my personal work at Minor Key Games (even if it has been mostly on the backburner); and in the last year, I’ve switched to working 4/10 weeks (four ten-hour days), opening up my Fridays for personal use. That has given me a lot more time to work on side projects like Eldritch 2.

I developed the first game (and large parts of its engine) in about 8 months, solo, save for an assist from my old Guildhall colleague Kale Menges on the key art. I like the creative independence of working alone; not because I’m allergic to outside ideas, but because I believe the strongest ideas come from a creator with a holistic view of all the parts working together. I can’t imagine trying to pitch the networked elements of Eldritch 2 to a team that was developing the roguelike elements separately; they all need to function with each other.

I formed Minor Key Games with my brother in mid-2013, and we have operated the company as a collective; a shared identity with shared values, but making separate games. This has led to some confusion, with each of us sometimes being credited for games the other made. To be clear, I’m making Eldritch 2 alone. He’s making Project Verse and I’m excited about that.

When’s It Coming Out?

Man, I dunno. I work fast and I’ve got an engine that was literally made to make Eldritch, but this is a part-time project for me, and the scope of Eldritch 2 is substantially bigger than the first game in a few ways. If this were a full-time project, I’d estimate it could be done in 12-18 months. Given my limited time to work on it, it will take, uh, longer than that.

I don’t have a real schedule yet. I don’t know when I’ll have a proof of concept build or a first playable milestone. I don’t know when I will have enough real art to put together a Steam store page and properly announce the game. I don’t know what my marketing strategy will be. I don’t know if I’ll do any kind of public beta or early access. I don’t know when it will be done.

What I do know is that it is rewarding to share things as I work on them, and that early feedback will help shape it into a better game. And this is the most fun I’ve had MAEKing GAEMs in years, so I’m going to keep chasing that.

Categories
Eldritch Eldritch 2 NEON STRUCT Slayer Shock

Rosa

I’ve been developing games professionally for 17 years, and I’ve been developing my personal engine Rosa for about as long. This isn’t going to be a post about whether or not you should make your own engine. I generally wouldn’t advise it, but you should make your own decision. I made my decision a long time ago. I love making games, but I love programming too; and engine development provides some of the most satisfying programming challenges. This is a brief history of Rosa and my current ideas for its future.

The origins of Rosa came from my student work at SMU Guildhall (2005-2007). As part of the curriculum, every programming student had to build their own 3D game engine, with OpenGL and Direct3D rendering, audio, input, collision and physics, etc. The more game-specific parts of an engine were left to each individual to focus on, and I chose to pursue AI with studies on behavior systems, awareness models, and pathfinding. This was my first time writing a 3D engine from scratch, and I got it done but it was messy.

When I graduated in 2007 and became a full-time professional game developer, I also began building a new personal engine, taking the good parts of what I had learned and cleaning up the messier, poorly-architected bits. Incidentally, I jettisoned OpenGL at this point, believing Direct3D to be the way (and Windows to be the only OS). I did this work mostly for fun, but I also hoped to eventually make a game of my own. Between 2007 and 2012, I built a lot of engine parts without ever getting close to actually shipping a game.

Brass City Couriers (unfinished, circa 2009-2012).

I leaned on Blender heavily at this time, even using it as my level editor because that seemed easier than building a level editor. The lighting model was baked and static, encoded into level geo as vertex colors and applied to dynamic meshes through a coarse volumetric directional ambience grid. Game objects were inheritance-based. Development was slow.

Codename “Agency” (extremely unfinished, circa 2012).

In the summer of 2011, I was frustrated with the inheritance model of game objects and decided to experiment with this fancy new “Entity Component System” concept I’d been hearing about. I was also eager to explore procedural generation, for reasons I don’t quite recall but probably had something to do with Minecraft. I built a simple textmode graphics framework and began building an infinite procedurally-generated world populated with composition-based objects. It was fast, it was fun, and in retrospect, it may have been the most important step I could have taken in my career.

Second Order (unfinished, circa 2012).

In early 2013, I left the relative security of my Big Commercial Games job and went into business for myself. (A few months later, my brother did the same and we formed Minor Key Games.) I had a very limited budget and needed to ship a game in around 8 months. The obvious choice might have been to lean on all the tech I had built over the prior 6 years, but instead, I ripped it all up and streamlined everything. I used the simplest possible art and rendering: all albedo, no normal maps, no specular lighting. I rewrote my collision code for AABBs exclusively, because it’s fast and simple and I was using voxels so everything was axis-aligned anyway. And I incorporated some ECS concepts to make game object composition and reusability a breeze.

Eldritch (2013), Minor Key Games.

My engine didn’t have a name at this time, but I’ll call this Rosa v1. Eldritch was a modest success and I followed it with my Thief-meets-Deus Ex cyberpunk stealth love letter NEON STRUCT. I didn’t make many engine changes for Neon; I improved my tools and optimized the voxel lighting grid to support turning lights on and off at runtime, but it is fundamentally still Rosa v1: all albedo, with voxel worlds.

NEON STRUCT (2015), Minor Key Games.

By the time I finished Neon, I was growing tired of Minecraft comparisons. I liked the ease of working with voxel worlds, but I couldn’t escape the shadow of the king of voxels. I was also starting to feel constrained by how much I had cut my engine to the bone; in particular, I was constantly working around the lack of dynamic lights and eager to rebuild my rendering skills. I undertook a substantial overhaul of my engine during development of the next game, removing voxels in favor of mesh-based geo and replacing the simple forward renderer with a deferred renderer using a principled physically-based lighting model.

Slayer Shock (2016), Minor Key Games.

My engine still didn’t have a name, but I’ll call this Rosa v2. Slayer Shock missed the mark, but that’s a story for another time. I ran out of money around the end of 2016, got a job, and largely put my engine and my games aside for a while. From 2017 to 2020, I dabbled in a couple of projects but ultimately got nowhere. But while copying code back and forth between a couple of projects and renaming classes to match the project, I realized that it would be easier if I had a unifying name for game-level classes in my codebase. So instead of renaming top-level classes like EldritchFramework to NeonFramework to VampFramework, all my games could use one common codename. I picked “Rosa” because it was like tattooing “MOM” on my arm, and that became the de facto name of my engine.

In 2020, stuck inside while a pandemic raged on, I started doing game jams to scratch the indie dev itch. I finished four game jams that year, and have done at least one every year since. These game jams culminated in what I consider a trilogy of minimalist first-person games: NEON STRUCT: Desperation Column, Li’l Taffer, and Schloss der Wölfe. Each of these improved upon my engine’s pipeline and workflow, largely by leaning on procedural generation. I developed tools to quickly generate procedural meshes and materials for world geo, and I reinvented my procedural level generation algorithm to create indoor spaces nested inside larger outdoor spaces. These three games also share a common visual style which I’ve been calling my signature “toy aesthetic”.

Schloss der Wölfe (2023).

I consider this current generation of the engine to be Rosa v3, and it is the engine I am now using to develop Eldritch 2. It combines the fast iteration and relatively simple art pipeline of Rosa v1 with the physically-based dynamic lighting and materials of Rosa v2. It’s a joy to work in, and work on. My current work is revising my procedural level generation (again) to bridge the gap between the more spatially plausible worlds of my recent game jams and the intentionally bizarro crashed-together spaces of Eldritch.

Looking to the future, there’s at least one unavoidable tech task that I need to deal with. Rosa is still using Direct3D 9 and OpenGL 2, absolutely ancient graphics APIs that have increasingly fragile vendor support. I don’t feel the need to upgrade for any particular modern features—I’m actually rather happy working with 20-year old tech—but OpenGL is no longer supported on Mac and getting a modern Windows PC set up to build a Direct3D 9 app requires jumping through a lot of hoops that they would clearly developers not do anymore. I’ll have to port to Vulkan eventually, and probably Metal if I ever want to target Mac again.

That’s a lot of words, and I’ve barely scratched the surface of my engine. I’ve got some tech that has been largely stable since as far back as Eldritch: AI behavior trees, event + reaction gameplay scripting, collision detection and sweeps/traces. I’ve got a custom cook process that is fast as heck. I’ve shipped 13 games or game jams on this engine, and it has grown a lot along the way. And I’m excited to keep using it!

Categories
Uncategorized

On Credits, and Other Things

Hi, I’m David Lindsey Pittman, and I make games.

Growing up, I was embarrassed by my middle name: Lindsey. That was a girl’s name, and I was a boy. I didn’t want anyone to know that was my name.

In my early years working in games, a lot people called me Dave. For a while, I hated it, because that wasn’t my name! Then I accepted it; and I didn’t just accept it, I adopted it. For a hot minute, I was Dave, and Dave was me. Then I rejected it again.

Names are fuckin’ weird yo, and I’m cis so I’m sure I don’t know the half of it.

Sometime during the pandemic year (I mean 2020, but they’re all pandemic years since then, right?), I decided to start using my full name in the credits. “David Lindsey Pittman”. No one calls me that, but that’s who I am. There are a lot of David Pittmans in the world, but I’m pretty sure I’m the only David Lindsey Pittman.

That was the same year I got into a brief spat on Twitter with a stranger over some hot take I tweeted about guns in video games. I don’t remember exactly what I said, and I don’t remember exactly what he said, but I definitely remember that I replied that I could end his career with a tweet. Because it was bullshit machismo posturing on my part, and it would have blown over and been forgotten the next day, except that a shitty alt-right comicsgate site decided to make a story out of it; and 4 years later, that’s still in the top results if you Google my name. The internet doesn’t forget anything.

On Halloween 2022, driving home from a screening of The Rocky Horror Picture Show, I was stopped by Plano PD for speeding, and arrested on suspicion of DWI. Within a week, if you Googled my full name, you could find my mug shot and my home address. I don’t mind owning up to my fuck-ups (fucks-up? how do you pluralize fuck-up?), but it is extremely fucked up that personal information in police and court records can get exposed online by sharks who will ask you to pay them to take it down.

I’ve lived my life online for as long as there has been online. I was DavidLP013 on AOL. I was David “Kyp Durron” Pittman in Unreal mods. I was MillennialDavid on AIM, before “millennial” was a thing anyone said. Then I was dphrygian, and that one stuck.

Sometimes, it would be nice to be invisible. I probably wouldn’t have so much anxiety if I just shitposted from an anonymous account, instead of being “David from Twitter” as my coworkers affectionately(?) call me. But for better or worse, my life is an open book. I’m 40 years old today, I’ve made more games than mistakes, and I hope the next chapter is a happier one.

I’m David Lindsey Pittman. And I make games.

Categories
Uncategorized

Schloss der Wölfe

I made a game about hunting Werewolf Hitler and punching Nazi zombies in the face. It’s called Schloss der Wölfe (“Castle of the Wolves”) and it’s out now for Windows and Linux: https://dphrygian.itch.io/schloss-der-woelfe

Schloss der Wölfe (or “Wolf” for short, because I’m not going to keep typing ö) was conceived as a short personal game jam, in the vein of the 7DFPS jam but on my own schedule. I started work on it on September 15, and intended it to be done by September 25. It’s now almost Halloween and I’ve just launched it, so… what happened?

For starters, it was probably a poor idea to do a game jam during a real crunchy month at my job. I made very slow progress the first weekend and had no time or energy to work on it midweek, so by the second weekend, it was clear that I wouldn’t hit my deadline. But I still wanted to finish it, so I let it slide into October. It’s a good game for Halloween-month, after all. Then it slipped the mid-October timeframe, as I got sidetracked with various tech detours and let the scope of the project grow beyond the original plan. But I was determined to finish it by Halloween, and here it is!

Wolf is the third in a series of minimalist first-person games I’ve made over the past two years, after NEON STRUCT: Desperation Column and Li’l Taffer. These three games are similar in design to my commercial games of the 2010s (Eldritch, NEON STRUCT, and Slayer Shock)—it’s what I love to make and what my engine was largely built to do—and one of my goals for each was to test new features and improvements to my engine by forcing myself to ship something small instead of noodling on tech with no real target.

I had begun some initial work on Eldritch 2 earlier this year—and I hope to get back to it now that Wolf is done—but that project got held up for months as my life got busy with buying a home, summer parenting duty, and the aforementioned crunch, among many other things. So Wolf was also a good opportunity to clear my mind and shake off the rust after a few months away from regular work in my codebase. As such, I let myself explore avenues that I’d normally avoid during a game jam, such as:

  • Reorganizing my deferred renderer G-buffer to replace the reflectance channel with an implicit reflectance (determined by metallicity) and freeing up a channel for ambient occlusion maps.
  • Adding new features to the texture generator that I developed earlier this year for Eldritch 2, including support for creating AO maps.
  • Completely rewriting my procedural geometry generator functions, to simplify the process of adding new shapes.
  • Replacing the simple echo filter I’d been using since 2018 with an actual reverb filter (which involved a crash course in digital reverb design—fascinating topic that I never knew much about before).
  • Implementing console commands, finally.

So, yes, a lot of tech detours; but it accomplished that goal of shipping something new and not just leaning on what my engine could already do to make a game as fast as possible. I consider that a success!

Enough about tech, let’s talk about the game. This is the original pitch, as I wrote in my email thread of potential game jam ideas:

Something I’ve never done before is a zombie game, and I have a feeling zombies in my signature toy aesthetic could be funny AND tense. Some light survival mechanics in a mid-sized generated city (or castle?) and a simple L4D style goal… that’s compelling. Maybe make it a Wolfenstein-core Nazi zombie thing for added punch. Could also use the comics style of Fray [an abandoned game project of mine, not the Joss Whedon comic], and really lean into a classic Captain America vibe. Call it “Schloss der Wölfe” (Castle of the Wolves) or something. Codename could be “Wolf”.

Of course, I’m not the first person to discover that the only thing better than killing Nazis or killing zombies is killing Nazi zombies; but as I said, I’d never made a zombie game before, so it stuck. The original idea was more stealth- and survival-oriented, but as I began to explore the concept and came up with Werewolf Hitler (initially as a joke that mi-i-ight be a stretch goal at best, but eventually became the central premise of the game), the tone got sillier and the genre shifted toward action.

I nailed down the high-level shape of the map and the pacing beats pretty early, but the bulk of the level design didn’t happen until this past weekend. In between, I focused on the mechanics: splitting my hands state and weapons system apart to support dual-wielding (the left hand can only punch, but it is technically a weapon in the code), optimizing AIs for zombie hordes, adding a simple zombie toxin status effect, and a whole lot of bespoke scripting for the (ahem) big boss fight. Also, it’s truly surprising to me that I’d never previously shipped a game with explosive barrels. I’m happy to finally check that one off my gamedev bucket list.

I’ll probably share more as I unwind over the next few days and reflect on this project. It’s my favorite thing I’ve made in a while, but it’s been six weeks of intense work, and I’m tired.