Games use codenames during development for various reasons: often because the real title won’t be determined until later in the project’s lifecycle, or because a sequel’s existence needs to be kept secret. Every studio I’ve worked at has had some pattern for generating new codenames: tree species, San Francisco neighborhoods, chemical elements.
When I started making indie games, I didn’t have a plan for codenames. “Eldritch” was a codename until I realized I didn’t have a better title for that game, and it stuck. NEON STRUCT was originally titled Die Augen der Welt, but I had picked the codename “Neon” for its target aesthetic.
A lot of Eldritch‘s C++ classes are prefixed “Eld” because it was shorter than writing “Eldritch” every time. Neon’s codebase was derived from Eldritch‘s, and it has a mix of C++ classes prefixed “Eld” and “Neon”, which was confusing during development. When I started working on Slayer Shock, I picked the codename “Vamp” and decided to unify all the class names with that prefix. Doing that broke a bunch of tab spacing where the additional letter changing “Eld” to “Vamp” moved a tab further to the right. I’m meticulous about tab spacing in my code, and that was annoying to fix.
The next project I started after Vamp was a bank heist roguelike (think single-player Payday 2) which I codenamed, shockingly, “Heist”. The tab spacing issue cropped up again, and I decided that all my projects after that would have four-letter names to avoid this problem. Later, I got tired of renaming classes altogether, and decided to use a common name unrelated to a project’s codename. That became my de facto engine name “Rosa“.
Despite not caring about tab spacing issues anymore, I’ve stuck with the four-letter codenames out of habit. I also make sure that the codename does not appear anywhere in my codebase, so I can do a find-and-replace on it when moving code between projects. So for example, I’d reject the codename “Apex” because my codebase has the variable MinimapExtents, which has “apex” embedded in it. That limits my options a lot!
I’ve also begun using four-letter codenames for the tools in my engine. That started by accident during the development of Neon, when I called my scripting language “Loom” (because it wove strings together, I think?); but now, my texture generator is “Piet” and my music generator is “Roja”.
Anyway, here’s a chronological list of the codenames of every indie project or tool I’ve worked on since 2013, including the unfinished and abandoned ones. Titles in bold are shipped or active projects.
- Eldritch: Eldritch (2013)
- Deos: abandoned open-world cyberpunk game (2013)
- Chef: abandoned cooking simulator game (“Drunk Chef“) (2014)
- Tango: Where’s Tango? (2014)
- Neon: NEON STRUCT (2015)
- Loom: configuration/scripting language and compiler (2015)
- Vamp: Slayer Shock (2016)
- Heist: abandoned bank heist roguelike (2017)
- Deos (again): abandoned open-world NEON STRUCT sequel (2017)
- Noir: abandoned 1940s/50s magical realism immersive sim (2017)
- Buzz: abandoned Persona-like “gamedev simulator” (2019)
- Loam: unfinished fantasy roguelike immersive sim (2019)
- Ludo: Davy Dreamt of Flying (2020)
- Voya: abandoned private investigator crime thriller (2020)
- Cyme: NEON STRUCT: Carrion Carrier (2020)
- Acid: Davy’s Dreams of Chasing Things (2020)
- Voya (repurposed): Gothwane Towers (2020)
- Deep: To Mine Own Craft Be True (2021)
- Laff: abandoned sitcom-themed game jam (2021)
- Zeta: NEON STRUCT: Desperation Column (2021)
- Fray: abandoned open-world sci-fi FPS (2022)
- Lily: Li’l Taffer (2022)
- Gild: abandoned Li’l Taffer expansion (2023)
- Lith: dark fantasy prototype (2023)
- Tofu: Eldritch 2 (in development, 2023-present)
- Piet: texture generator tool (2023)
- Wolf: Schloss der Wölfe (2023)
- Zwei: unbegun Schloss der Wölfe sequel (2023)
- Rasa: abandoned “paint the world with footprints” game jam (2023)
- Roja: music generator tool (2024)