I was posting on Bluesky today and said “I’ve done all the things I ever wanted to do in games,” which is something I’ve said in a handful of conversations recently, but maybe not so publicly or visibly, and I decided to dive into what that meant to me.
(To be clear: I don't have heroes in this industry anymore. I did when I was younger. I even got to work with some of them. But now I've done all the things I ever wanted to do in games, and it turns out your heroes are just people. And that's pretty cool actually.)
That “I’ve done all the things I ever wanted to do in games” thing has been weird in my current job search. I don’t know what I’m looking for. I don’t know where I see myself in 5 or 10 years. I’ve done all the things, I’ve gotten all the cheevos, and I’m still playing the game because I enjoy it.
(Also because I need to pay the bills.)
When I was starting out, I’d have said I wanted to level up to being a senior engineer owning some systems, maybe someday become a manager, and maybe if the stars aligned make my own games someday. I did all that before I was 30 years old!
I came back from the solo indie thing, worrying I was stagnating, to challenge myself to do multiplayer code and console porting on The Blackout Club, and I nailed that.
I’d been hesitant to return to management after my first experience, but I stepped up, led the engineering team on The Killing Stone, and guided us to a smooth landing.
At this point, I’m not worried about stagnating, because… I’ve done everything. It’s just a matter of what I focus on next.
And really, in the current industry, that’s a matter of who can/will pay me. If I can get funding to make Eldritch 2, then obviously I’ll do that. If I can get a job as a director at a AAA studio, then obviously I’ll do that. But I can take a senior engineer job and it pays the bills, I’ll do that.
A decade ago, in my last job search, I kept asking for more time to make a decision, and the recruiter at 2K (who had previously hired me for 2K Marin) told me frankly that engineers had all the power in negotiations. That ain’t the case in 2026.
Someone of my caliber could’ve walked into any job a decade ago. I mean, I literally had my pick of four offers when I joined Question, and I dragged out negotiations with the other three places so that I could wait for Question’s offer.
That ain’t the case in 2026.
(The other three were Double Fine, Hangar 13/2K, and Gearbox. I was also in the middle of interviewing with Arkane, but they were in the middle of shipping Prey, so it was going slow. But at least I got an intro call and a programming test there! Can’t even get that far at most places now.)
There have been a handful of jobs I’ve applied to this time around that I REALLY wanted, and they’ve all either rejected me outright, declined to continue past the intro call, or withdrawn the position for other reasons (womp womp Otherside).
I just want to make video games, and also pay the bills.
This post is inspired by the current discourse about Pacific Drive‘s save system. It’s a good game and I’m not intending to pick on them. The technical challenges they describe are real, and we’ve all faced them. This is my solution from my solo games.
What Does It Mean to Save Anywhere
“Save anywhere” means the ability to save a game’s progress and restore it to the exact state, or as near as possible. A typical example is a game where a player is allowed to quicksave and quickload at will, perhaps to retry a difficult sequence over and over without consequences. A perfect example is retro console emulator save states, which store the complete memory layout and whatever else they need to load later, with everything exactly as it was, down to the emulated CPU timing. In non-emulated environments, saving the complete state of system memory is not feasible; we, as developers, need to make decisions about what information is important enough to write to disk.
What Do You Save
Everything. Every entity. Every component. Every property. Save everything.
There are various ways to do this—some engines or frameworks or languages provide high-level reflection and serialization, enabling a game developer to simply save the scene/world and get everything within it “for free”. If you’re not working in a space that already does that heavy lifting, this means iterating every entity in your scene and writing all their important properties to disk. This is The Hard Part if you don’t do it early in development; the goal is simple enough, but determining what is an important property is not obvious, and trying to figure out the set of important properties when the game is full of hundreds of entities with tens of thousands of properties is a testing and development nightmare. This is the main reason why games that do not plan for save-anywhere from the start cannot feasibly add it later.
What Do You Not Save
Except!
There are some things that don’t need to be saved. Static entities that are part of an authored level do not need to be saved (unless some part of their state is mutable); when the saved game is loaded, they will be instantiated as a part of that level. Their properties are effectively saved once in the game’s content files, never to be changed.
And other properties may not need to be saved if they can be automatically determined from context. AI behavior states should fall out naturally from all the other state in the game. It’s probably not necessary to remember that enemy X was doing an attack animation at player Y, if you’ve already saved that enemy X is aware of player Y. When the game is loaded, the AI behaviors will fall into place from that information, and enemy X will attack player Y.
When Do You Save
All the time. Constantly.
When to save is partially dependent on the game design, but there is no game design or genre where the player should not have a reliable backup save file in the event of a power outage or Alt+F4.
Save the game when the player clicks Save Game. Save the game when the player quits for any reason. Save the game at regular intervals. Make sure that the player’s progress is never lost.
I’m a big fan of the Gunpoint style of rolling autosaves (for certain types of games, see below). When you save the game at regular intervals, do it in a rotating buffer of save files, so the player can restore to various points in their past, whether they were managing their save files or not.
For most games (see below) don’t autosave the game during combat. Don’t autosave the game when the player is in any dangerous motion (perhaps in midair, or any other unusual move). Don’t autosave during a cutscene unless your game is all cutscenes, and then this probably isn’t the right blog for you.
When Do You Load
This is where the save/load system really depends on the game.
For most games, you should let the player load any save file at any time. Give them a menu of manual saves, autosaves, their most recent quicksave, cloudsaves, friends’ cloudsaves, chapter bookmarks, who knows, who cares? Let them jump to the place in the game they want to go to, at any time, for any reason.
But! Roguelikes are a special case, because you don’t want the player to abuse the save system as a way to cheat death. That doesn’t mean you shouldn’t save the game! Always save! In fact, for roguelikes, you should ignore the rules above about not saving during combat. Don’t let them savescum out of a tough situation! The player might encounter a crash, or need to quit suddenly to go deal with some real life. So always save! But for roguelikes, the player should not have any choices about what to load; it is always the most recent save, so they cannot cheat.
Save Anywhere in Rosa
Finally, the technical bit, specific to my engine.
The Rosa engine uses a pure entity-component framework, where every game entity is of a singular type, composed of virtual components which inherit from a base class. Every entity belongs to the scene. Every component belongs to an entity. Every saved property belongs to a component. So the save process goes:
Basically: iterate the entities in the scene, and iterate the components in each of those entities, and write the important properties of those components.
There is no automatic system here, no reflection of variables that get automatically serialized. When I add a member to a component class, I also add it to the ::Save function. This is The Hard Work.
But, this isn’t a lot of work if you build it from the start! I rarely touch these save/load functions, and when I do, it’s because I’m in the middle of writing a new component, or new functionality on an existing component, and I know what parts need to be serialized. It looks like a lot of work, but it is extremely low maintenance.
Loading is basically the same process in reverse, and with conditions to handle different save file versions:
This is why each component serializes a version number, and it is how I make sure that old save files will be compatible with newer code; if the component was serialized with an old version number, it will simply skip loading the related properties and use their default value. Again, this looks messy, but I don’t ever have to think about it! It’s not zero work, but it’s just following a mindless pattern, and it Just Works.
Why Should I Care?
You might think your game design doesn’t need save-anywhere, because it’s meant to be difficult or it’s a short game or whatever. I think those are bad reasons to not do save-anywhere (as I noted above, roguelikes probably need save-anywhere more than any other genre), but if nothing else, consider this: save-anywhere is a huge time saver in testing your game. Anyone who has ever had to replay a 5-minute sequence in a game to get back to the part where a bug can be reproduced should understand this. When you can save/load anywhere, you can reproduce (most) bugs almost instantly, which saves a ton of development time and frustration. Even if your game has no player-facing save system, the ability to restore the game state to repro a bug is immeasurable.
Do it for the players. Do it for QA. Save anywhere.
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 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.
NEON STRUCT: Desperation Column is the third game in the NEON STRUCT series, and the second that I’ve released as a free game jam.
The reason I’ve been doing game jams again recently is that sometimes I need the extrinsic motivation of a theme, a competition, or a deadline. I like making games, but it’s easy to get lazy, and an extra push doesn’t hurt.
This is the first game jam I’ve done in a very long time that put gameplay first. I’ve been doing narrative-focused stuff for a while, and that’s been great too; but this is pure action gameplay, and I’m at home here.
I started from a codebase that already had a lot of the things I needed for this game. I think that’s fine for a game jam, it’s the same as starting with Unreal or Unity + your fav plugins, but I definitely didn’t make this from scratch in a week.
The 7dfps jam has generous rules (read: no rules), but I wanted to finish on time AND make something good. So I knew I’d have to be careful about scope, and baby I LIVE for being careful about scope.
My initial parameters were: 1 weapon, 1 enemy type, 1 environment. That grew to 2 enemy types, plus an NPC type, and 3 environments (sorta); but the ultra lo-fi style meant those additions didn’t explode scope.
You can search bodies and containers, but there is only 1 resource to find: ammo. You have limited ammo mostly because it gives you a reason to search containers. And it maybe creates tense moments when you run out.
There are no health pickups, no upgrades or unlocks, no skills or perks. No conversation trees, no shops, no character customization. I’ve done all those things before, I still have the code, and I chose to not do them here.
The result is a minimalist game that is now one of my favorite personal projects: a pure distillation of the action/FPS mechanics at the heart of all my work. I think it’s the closest thing to Eldritch I’ve made in a long time.
And it broke me out of a mental rut where I’d felt like doing this sort of thing was too hard, or would take too long. It wasn’t, and it didn’t. It was a sheer joy to make this game, and I hope that shows.
