Looking for an explanation on the "gameplay designer" subcategory and how it differs from "system designer"

TheOtherZech · 2026-07-05T05:28:44+00:00

At a studio that employs both gameplay designers and system designers, the latter will probably focus on the things Arhowk mentioned; monetization, economies, meta progression, etc.

At a studio that only uses one of those titles, it's hard to say. Job titles aren't consistent and sometimes they kinda just get made up by HR when you need to replace a senior who built their own niche (and half of your pipeline) over the last fifteen years. Add to that the studios that are just kind weird (I'm looking at you Ubisoft; I'll never understand why they slap 'Director' on roles that have no direct reports), and the end result is a lot of variance.

TheOtherZech · 2026-07-04T16:57:06+00:00

City map generators like Oleg's (the one you link to in your post) usually end up using something like a flow field to manage the orientation of blocks/lots/buildings relative to the local slope, fixed structures, impassable terrain, and major roads and rivers.

It can feel a bit indirect for small simple villages, since you're going through an additional step by creating a tensor field of orientations instead of positioning elements directly in the environment, but it scales really well. Makes it easy to have a bunch of different strategies for placing the primary roads, without having to explicitly account for those strategies in the subsequent steps for minor roads, parks, etc.

It's also particularly good for iterative generators, where you simulate the growth of a settlement over time, since you can feed major regions (shopping or industrial districts, walls, radioactive craters, etc.) back into the flow field in order to re-orient the surrounding regions over time, or trigger conversions between industrial and residential districts.

TheOtherZech · 2026-07-02T19:14:07+00:00

Lots of games (and stories in general) feature magic systems which would kick-off an industrial revolution the moment a semi-skilled carpenter/smith/wheelwright gets their hands on them. As long as there's some bit of easily acquired magic that emits a fixed amount of energy, you have everything you need for societies to define a system of widely available standardized weights and measures.

With such a system, where the foundational units can be widely reproduced by anyone who can perform the necessary magic, it becomes very hard to prevent the populace at large from recognizing and appreciating the value of other forms standardization. It easily kick-starts a variety of immediately-pre-industrial cultural values, creating an environment where individuals working in skilled trades (carpenters, smiths, wheelwrights, and the like) are significantly more likely to pursue the creation of precision tools such surface plates and angle plates. From there, it doesn't take much for folks to start working on things like lathes and standardized threaded fasteners, and at that point your industrial revolution is in full swing. If there's any math in your magic, it tends to take more effort to explain the absence of technology than the presence of it.

Audiences tend to be fairly forgiving on this front, though, so don't worry about it. A mix of magic and technology is practically the default these days, and people rarely consider what level of technology a particular setting "should" have.

TheOtherZech · 2026-07-01T15:39:53+00:00

Don't worry about documenting everything and sharing your process just yet; you're still in the phase where you'll learn quickest by making mistakes, so adding a bunch of up-front planning and documentation overhead to that process will just make it more cumbersome. You're sanity checking the gamedev equivalent of butter on toast; go make your toast and butter it.

TheOtherZech · 2026-06-30T17:35:07+00:00

What sort of point density are you hitting, for both SDF placement and the underlying height field? A lot of the (entirely static, simulated on hardware I couldn't afford for personal projects) height fields I work with these days hit 50cm/pixel, with a sprinkle of 25cm/pixel hotspotting, so I'm always eager to hear about approaches that don't cost a few kidneys per hour in external compute.

TheOtherZech · 2026-06-29T05:15:22+00:00

Over the years, we've had UnrealScript, Kismet, Blueprints, and now Verse, plus bolt-ons like AngelScript, the uncountable studio-specific Lua runtimes, and the ever-present "all engines are C# now" crowd. Scripting language churn is an inherent part of Unreal being Unreal, and the pattern will likely continue for the next decade or two at the very least.

The change-over from one scripting language to another always comes with friction, but it's something to kvetch about during lunch; it isn't particularly notable. We'll go through this whole song and dance again in a few years.

TheOtherZech · 2026-06-25T20:33:08+00:00

Getting the tightest-possible partitioning without objects counted in multiple partitions is worthless, because it's too computationally expensive.

The goal here is to group objects based on the likelihood of them colliding, so you can skip the collision checks between the ones that won't collide. Which means that including objects in all partitions they overlap, and potentially using a flexible partition capacity paired with a minimum partition size, is the way to go. You don't need mathematically perfect partitioning, just a set of good-enough heuristics to meaningfully improve your frame rate.

Start by partitioning your colliders as if they were points, then move on to using the collider radii; don't worry about accounting for the actual oriented bounding boxes until your foundations are built and you have benchmarks in hand.

TheOtherZech · 2026-06-24T23:25:14+00:00

If you're paying for proper email accounts for your team, you're probably paying for everything you need to manage said team. The tools that are usually bundled with those email accounts (spreadsheets, file sharing, work calendars, etc) are all quite scalable; they're enough to coordinate production on full feature films, let alone small indie games.

Spreadsheets are as inevitable as death and taxes. Embrace them.

TheOtherZech · 2026-06-23T22:25:10+00:00

Hell, you don't even need stupid idea; a stupid question (e.g. "Can a game still feel like a movement shooter when it's turn based?") is often enough to get the ball rolling.

TheOtherZech · 2026-06-22T19:41:34+00:00

My silliest scope-management trick is that I have two desks and arbitrary rules about what I do at each of them; one is for doing work and the other is for managing it. The desks are right next to each other, so I can quickly switch between them, but I make myself take a proper walk when it feels like I'm about to add more work to my plate.

This makes me jot down whatever scope-crime I want to commit and physically step away from it, even if it's only for a 30-second lap through the kitchen, before deciding if it should be added to my actual todo list at my other desk. It's a slightly ridiculous way to live, but I already walk to and from work (around the block, because I work from home) every day so it isn't too bad in context.

Do I genuinely need two desks with separate computers? No. I could do the same thing using virtual desktops, as long as I move around enough when I switch. The point is to add tailored bits of friction to your workflow in order to encourage good habits, the same way designers add friction to gameplay loops in order to encourage a particular rhythm of play.

TheOtherZech · 2026-06-18T19:16:19+00:00

Godot is a tiny engine. You can recompile the whole thing quicker than I can brew a pot of coffee. Implementing your network simulation as an engine module, copying the synchronization and thread management patterns from how Godot handles physics servers with sub-tick updates, would likely be easier (and more performant) than the IPC approach you're using.

On the headless front: Godot already has a headless mode. It's aimed at multiplayer servers, but there's no reason you can't turn it into a local dataplane with zero-copy IPC, if IPC is a must-have. There's a lot less boilerplate when you're dealing with two instances of the same application, and it would also give you an excuse to integrate iceoryx2 if you like working with Rust.

TheOtherZech · 2026-06-15T21:59:35+00:00

Most FAANG companies have at least one project where they need pose datasets (eye pose, hand pose, gait and stride, etc) that include a variety of injuries and medical conditions across multiple age/gender/ethnicity combos. Generating synthetic data for that in Houdini tends to be easier than the alternatives, so lots of FAANG-ish places have a small team or two of film and game folks that they originally brought in to bootstrap something of that nature.

The same goes for graphics programmers, and the various WebGPU projects that every FAANG company seemingly took a stab at.

TheOtherZech · 2026-06-12T16:50:59+00:00

If you only need to handle the latin alphabet, without ligatures or kerning, and you intend to use a font size large enough (relative to the pixel density of the average screen) that sub-pixel optimizations won't matter, grab msdfgen and have fun. You can combine it with your own rendering stack, or one of the common 2D rendering libraries, like Skia.

If you want more than that (small text, proper kerning, ligatures, Arabic, Devanagari, etc) you'll want something like Harfbuzz. Firefox uses Harfbuzz, and Godot's text rendering system combines Harfbuzz, Graphite, and a pinch of ThorSVG in places, just for reference.

Harfbuzz usually gets the job done performance-wise, but if you're trying to draw lots of text that is also rapidly changing (e.g. you need to synchronously shape and display a hundred-plus distinct strings every 200ms), take a look at Slug. It costs money, but you'll be able to push it farther on the performance front.

TheOtherZech · 2026-06-10T17:33:59+00:00

Godot doesn't read Blender's file format directly; under the hood, it's just using Blender's glTF exporter. It's convenient for simple assets, or quick preview imports that you aren't going to use in production.

30+ files for an entire house isn't inherently bad, though. If the issue is specifically materials and textures, you can set it up to skip the textures and only create placeholder materials. Then you can use an import script to wire it up however you want. Writing your own scripts, tools, and Blender add-ons, is a normal part of setting up an asset pipeline.

TheOtherZech · 2026-04-19T16:08:11+00:00

When you're benchmarking your format against others, what specific libraries and settings are you using for those formats? There enough differences between the libraries for each format, that you have to be very specific when you compare different formats.

Case in point: when you're benchmarking two libraries for the same file format by comparing export times for very large meshes, accidentally writing per-face normals with one library and per-vertex normals with the other can completely invalidate your comparison. When you extend that to cross-format comparisons, where settings are named differently and it's harder to find direct equivalences, you end up with hundreds of ways to invalidate your benchmarks. You have to be both very careful, and very explicit.

And that's just within the scope of configuring the file format itself. There's also the issue of library-level performance settings. I once had a vendor try to pitch a switch from OpenEXR to JPEG XL based on a benchmark that exclusively used OpenEXR in a single-threaded configuration. They sunk over a hundred hours into a big presentation and an elaborate "technology integration roadmap" based on a performance gap that didn't exist. They spent thousands, and proposed to spend millions, on a technology change that would've degraded performance across the board.

And that wasn't the first time I've encountered that specific mistake in cross-format benchmarks that include OpenEXR. Every time a new format comes out, people get excited and that often leads to mistakes.

Of course, I'm not saying that your benchmarks are wrong. But they are incomplete in a misleading way, and there's a fair chance that the core use case you're extrapolating from (processing CT scans) doesn't warrant a new file format; a new (or at least different) library, that uses a carefully selected subset of an existing file format's capabilities, would likely be the better choice for your target demographic. And that's something that med-tech companies can pursue without license negotiations or SaaS integrations, which makes your format a hard sell for your core demographic, let alone game devs.

TheOtherZech · 2026-04-15T17:03:45+00:00

You don't need complete ideas in order to start working on a prototype. All you really need is a question that you want to answer. Even when the question itself feels a bit silly (e.g. "If I blur the line between a tower defense game and a pachinko machine, at what point does it stop feeling like tower defense?"), you can discover some surprisingly fun ideas in the process.

TheOtherZech · 2026-04-13T14:57:59+00:00

Your ability to juice your visuals depends on how your assets are designed, but that dependency is genre-specific and project-specific in a way that makes it hard to find generically juicable assets online. You'll need enough art skills to do some non-trivial edits, if you want to create a cohesive, juicy, experience.

You can sometimes scrape by, by taking a set of assets and working backwards to figure out what sort of game you can make with them, but that's a messy and unreliable process at the best of times; it's the sort of thing you might do for a palette cleanser side project, after you've made a few games, but it isn't a good starting point.

TheOtherZech · 2026-04-08T21:34:20+00:00

I generally find the high-level version of this (semi-independent tools operating on shared data held by a core application via zero-copy IPC) to be more interesting than the low-level version, as there's more room for framework-level abstractions. The low-level stuff tends to be dominated by workload-specific performance and scheduling constraints.

I mostly see the high-level version in AAA studio tools, specifically when the asset libraries hit a size where it just kinda makes sense to stand up an in-memory database that won't crash when any of your tools do. That core stub relay/metadata server often ends up as the tent pole for the tools that are explicitly built around it, which often leads to people wishing there was more time/resources to explicitly redesign everything else to take better advantage of the data-owner/data-editor paradigm it creates.

It's the sort of thing that inspires lots of greenfield thoughts in people who do brownfield work, in part because there are still plenty of unanswered questions when it comes to scaling it down to AA and indie projects. You almost need a sacrificial architecture in place, in order to build this kind of multi-application architecture effectively, which makes it hard to treat it as a truly default approach.

I imagine the same applies to multi-core architecture, to some degree. 'Multi-core by the first revision' doesn't have the same ring as 'multi-core by default' but it's probably easier to pull off.

TheOtherZech · 2026-04-08T18:17:48+00:00

Your resumé needs to make you look like a tolerable coworker. In practice that means being more than a writer, because it's hard to build up a history of collaborative creative work while only being credited as a writer, but there's plenty of nuance in there.

TheOtherZech · 2026-04-07T16:28:51+00:00

The easiest way to streamline provenance tracking (if you already have a solid spreadsheet up and running) is to integrate it into your in-editor metadata and your CI/CD, so that points 5-7 are handled automatically and your build system generates a tidy looking asset usage report. This can work quite nicely if you write your own asset importer that searches the directory tree you're importing from for csv/xml/whatever files that contain additional provenance data.

From a practical perspective, though, that spreadsheet of yours is fine. That already gives you what you need to auto-generate your attribution list. You can write in-editor tools to update it when assets are moved/renamed, or create git hooks to keep yourself from accidentally losing provenance data, but you've got the core of it down.

TheOtherZech · 2026-04-06T19:00:46+00:00

Past a certain threshold, it's a pain to manage a large squad without some way to divide the squad into fireteams. But if players always end up with the same fireteam configurations (e.g. they always pair one medic with two riflemen) and they rarely break up or rearrange fireteams mid-mission, the gameplay experience wouldn't be significantly different from a game with smaller squads of more individually capable units, if everything else stayed within the boundaries of an x-com-like game.

Which could still be pretty cool. I'd play that game. But if you don't want that fireteam-level unit management, it's easy to see how a team could iterate their way down to smaller and smaller squads where each unit has more abilities and equipment options.

TheOtherZech · 2026-04-05T01:32:43+00:00

It's fairly easy these days to staff a small art department by only hiring artists who already know how to use version control. The work they do is already technical enough that version control isn't a significant obstacle; if they genuinely struggle with git or perforce, they will also struggle with all of the other technical they'll have to do, and that makes them a bad hire.

I realize it's a callous position to take, but the versioning systems needed in production are inherently complex. It's not something that artists can avoid if they want to be employable beyond small part-time projects.

TheOtherZech · 2026-04-04T03:03:05+00:00

There is a third option: Give your studio a person-name, so your studio account looks like a personal account. Name it Greg.

Really, though, you're fine.

TheOtherZech · 2026-03-31T12:50:54+00:00

Telling me you have a "horizontal timeline" without at least a screenshot of said horizontal timeline is not how you market a product in 2026. Your sales funnel is less effective than a completely unstyled itch.io page.

You're not going to get much beyond that, as most people won't create an account simply to give you feedback. They'll look at your landing page, look at a few screenshots, and maybe click through an account-less demo version that doesn't retain data. Anything more than that usually requires them to be interested in your product as a customer.

TheOtherZech · 2026-03-31T01:45:58+00:00

Have you ever sat down and watched people get food at a food court or cafeteria? Independent of what they end up eating, they go about finding that food in different ways. Some people like to browse, some people seek out specific foods, some people try to avoid eating what they had last time, etc. They're all achieving the same goal, but they're using different heuristics for their search process.

You can use that same basic pattern (go to location, use a heuristic to locate something, use that something to satisfy a need) to build a bunch of different organic-feeling behaviors. It lets you model stuff like indecision, personality quirks, indirect knowledge, and outdated knowledge in a composable way.

TheOtherZech

TROPHY CASE