{"id":421,"date":"2026-08-13T17:34:45","date_gmt":"2026-08-14T00:34:45","guid":{"rendered":"https:\/\/secondhandcarrot.com\/blog\/?p=421"},"modified":"2026-08-13T17:35:27","modified_gmt":"2026-08-14T00:35:27","slug":"after-you","status":"publish","type":"post","link":"https:\/\/secondhandcarrot.com\/blog\/dev\/after-you\/","title":{"rendered":"After You"},"content":{"rendered":"\n

Last time I wrote about staging conversations, and the whole post turned on one sentence: the dialogue flow is the master script, and the sequences are just shots. Pick a boss, let everything else be a servant. There was a line near the end of that post I want to cash in now \u2014 that we’d learned a long time ago not to let two systems argue about a character’s position.<\/em><\/p>\n\n\n\n

Reader, we had three systems arguing about a doorway.<\/em><\/p>\n\n\n\n

It’s been longer than usual between these. Heads-down stretch; the notes piled up faster than the writing did. This one’s the oldest thing on the pile and the one I still think about most.<\/p>\n\n\n\n

Fair warning, same as the last two: background post. Dense, in the weeds, no screenshots, no trailer beats. If you came here to see the game, this isn’t that one.<\/p>\n\n\n\n

And a stronger version of the standing caveat than usual, because this post needs it: this is a redesign in flight, not a victory lap.<\/strong> The first half \u2014 the diagnosis and the deletion \u2014 is landed code. The second half is a design we’ve committed to and are partway through, with a chunk of it still living in specs rather than in the build. I’ll mark the seam when we get to it. I’m writing it up now because the reasoning<\/em> is the useful part, and reasoning doesn’t get more true by waiting for the last task to close.<\/p>\n\n\n\n

The error we’d been ignoring<\/h2>\n\n\n\n

Every time an NPC crossed a threshold, the log said this:<\/p>\n\n\n\n

LogSmartObject: Error: Expected slot state is 'Claimed' or 'Occupied' but current\nstate is 'ESmartObjectSlotState::Free'. Slot will not be released<\/code><\/pre>\n\n\n\n
One test run with a single<\/em> NPC \u2014 Yarbo, walking from home to the grocery where he works \u2014 produced four of them. Two on his way into the house, two around entering the shop. Checking older logs afterward, the same error was sitting there a month earlier. It had been announcing itself politely for weeks.<\/p>\n\n\n\n
It’s the kind of thing that’s easy to file under “engine noise.” Nothing visibly broke. Yarbo got where he was going. But read what it says: something tried to free a door slot that had already been freed.<\/strong> Nearby in the same logs was its blunter sibling \u2014 a complaint about one user trying to release a slot claimed by a different<\/em> user. Two keys to the same lock, no agreement about who locks up.<\/p>\n\n\n\n
Three claimers, and nobody in charge<\/h2>\n\n\n\n
A door in our game is a SmartObject \u2014 the engine’s way of saying “a thing in the world that advertises what can be done with it, with a limited number of slots for people doing it.” Claim a slot, use it, release it. Fine with one claimant.<\/p>\n\n\n\n
We had three, none aware of the others:<\/p>\n\n\n\n
    \n
  • The task that decides “I want to go through this door”<\/em> claimed a slot and kept the handle in its own instance data.<\/li>\n\n\n\n
  • The processor that performs the crossing claimed a slot and kept the handle on the NPC’s location fragment.<\/li>\n\n\n\n
  • A third, general-purpose claim task \u2014 which also handled work stations \u2014 claimed a slot, kept the handle in a third<\/em> place, and wrote a mirror copy into the second.<\/li>\n<\/ul>\n\n\n\n
    Three claimers, three handle storages, overlapping lifetimes, coordinated entirely by hand-written comments. One of those comments ran something like twenty-five lines, patiently explaining why this<\/em> system clears that<\/em> system’s handle so the third<\/em> one will skip its release.<\/p>\n\n\n\n
    That comment was the architecture documenting its own race condition. When code needs a paragraph of apology to be correct, the paragraph isn’t the problem. (It’s gone now \u2014 deleting it was part of the fix, and I’d be lying if I said that wasn’t satisfying.)<\/p>\n\n\n\n
    It was worse than three, because one “walk inside” touches two different doors<\/strong>: the entrance on the street, and the interior-side landing door the NPC arrives on. So the real shape was three claimers spread across two SmartObjects with handles flowing through three storages. Working out which handle was live at any instant wasn’t hard<\/em>, exactly. It was untraceable by reading \u2014 which, for two people, is the same thing as impossible.<\/p>\n\n\n\n
    The unnecessary claim<\/h2>\n\n\n\n
    The unlock was asking a dumb question out loud: why does walking toward a door require owning it?<\/strong><\/p>\n\n\n\n
    It doesn’t. Several members of a household can head for the same front door at once. They aren’t using<\/em> it yet. They’re walking.<\/p>\n\n\n\n
    Exclusivity matters at one instant \u2014 the crossing itself, so two NPCs don’t land on the same interior spot in the same frame. And that instant was already handled by the crossing processor: it walks the door’s slots until one hands back a valid handle, and if none do, it doesn’t force it \u2014 the NPC’s state is left alone and the processor tries again next tick.<\/p>\n\n\n\n
    So two of the three claims weren’t protecting anything. They were redundant with a guarantee that already lived somewhere else. Removing them couldn’t lose serialization we depended on, because the serialization was never in them.<\/p>\n\n\n\n
    The fix was mostly subtraction: delete the claim block from the intent task, delete the door branch from the general-purpose claim task, and let the crossing processor own the door claim outright.<\/p>\n\n\n\n
    Worth saying what that cost, since this is a from-the-workbench post. Making the general claim task activity-only broke the work loop<\/strong>. The tree still had a state asking it to claim a door, and it now refused, loudly and repeatedly. That was known and accepted \u2014 the tree needed rewiring anyway \u2014 but for a stretch there the deletion left the build worse than it found it. Subtraction isn’t free just because it’s subtraction.<\/p>\n\n\n\n
    The bigger thing underneath<\/h2>\n\n\n\n
    Here’s the seam I promised. Everything above is landed. What follows is where the reasoning went next, and it’s mostly still ahead of us.<\/p>\n\n\n\n
    Having pulled that thread, we looked at what was left and had a less comfortable realization: we’d been hand-rolling a find \u2192 claim \u2192 use \u2192 release<\/strong> lifecycle as a side-car, running alongside the one Unreal’s Mass StateTree already ships.<\/p>\n\n\n\n
    You want to know how we could tell? There’s a comment in our crossing processor that says, more or less: replicate the engine’s own cleanup routine here.<\/em> We had named the engine function we were reimplementing, in a comment, directly above the reimplementation. It’s still there today. That’s not a war story, it’s a to-do.<\/p>\n\n\n\n
    WHAT WE HAVE                         WHAT THE ENGINE SHIPS\n\nour task claims a slot               Find  \u2014 candidate search\nour processor claims a slot          Claim \u2014 owns the handle AND the release\nour other task claims a slot         Use   \u2014 fires the behavior, never frees\n   \u2193                                    \u2193\nthree handle storages,               one storage, one owner,\ncoordinated by comments              release on success \/ fail \/ abort<\/code><\/pre>\n\n\n\n
    The engine’s version has a property ours structurally could not: the claim owns the release.<\/strong> Leaving the claim state frees the slot \u2014 on success, on failure, and on abort. There’s no path where a claim outlives its owner, because the owner is<\/em> a state, and states always exit.<\/p>\n\n\n\n
    Delegating also hands you a thing we’d been paying for in workarounds. Claiming through the engine’s handler registers a slot-invalidation callback: if the object goes away underneath you \u2014 an interior streaming out with an NPC mid-interaction \u2014 the engine aborts for you. Ours doesn’t register that, which is part of why we grew a set of polling checks that notice the same condition late and recover. Not all of that polling is waste; some of it covers cases the engine genuinely doesn’t model. But some of it is us re-deriving a callback that was one function call away.<\/p>\n\n\n\n
    To be precise about scope, since “delegate to the engine” sounds bigger than it is: we’re keeping our own Find<\/strong> \u2014 we know which door or station we want and don’t need a search \u2014 and handing over Claim<\/strong> and Use<\/strong>. It’s a narrower change than the diagram makes it look.<\/p>\n\n\n\n
    Where the engine’s version doesn’t fit<\/h2>\n\n\n\n
    The engine cycle assumes the object exists. Our hard case violates that: the destination might not be loaded.<\/strong> If nobody’s inside the grocery, the grocery’s interior isn’t streamed, and there is no landing-door SmartObject to claim or use. The NPC still goes in \u2014 abstractly \u2014 and gets placed for real later, if and when the interior loads.<\/p>\n\n\n\n
    That’s the irreducible part, and it stays custom. The useful thing is that the boundary was already sitting in our code as a condition the tasks check: is this NPC virtual right now?<\/em> We’d drawn the line in roughly the right place while patching bugs, without noticing it was also the answer to what should we delegate.<\/em><\/p>\n\n\n\n
    I’ll flag a correction to my own thinking here, because I had this wrong for a few days. I’d assumed the other irreducible case was NPCs with no visible body \u2014 nothing to walk to a slot. Turns out using a door doesn’t require a body at all; the “use” can be abstract, and the same cycle covers represented and unrepresented NPCs alike. One boundary, not two. Finding out that a special case you’d been carefully protecting doesn’t exist is one of the better feelings in this job.<\/p>\n\n\n\n
    The claim came back, and that’s fine<\/h2>\n\n\n\n
    One wrinkle, because leaving it out would make this cleaner than the truth.<\/p>\n\n\n\n
    The door claim came back. Not the one we killed \u2014 a smaller one. To make the door’s behavior data-driven, the crossing gets triggered by using<\/em> the door SmartObject, and using it requires claiming it. The rule that stops this from recreating the original mess is about lifetime<\/strong>, not existence:<\/p>\n\n\n\n
    \n
    The claim lives only inside the use. Never across the walk.<\/p>\n<\/blockquote>\n\n\n\n
    The approach stays read-only. The claim is taken at the door, the use completes immediately, the claim releases when the cycle exits. And it’s on the entrance<\/em> door, while the crossing processor still owns the landing<\/em> door \u2014 two objects, two lifetimes that don’t overlap.<\/p>\n\n\n\n
    The cost, stated plainly: that entrance claim is functionally redundant. Setting the flag alone would cross the door. It exists purely to give the behavior a trigger, and it means housemates arriving together will briefly queue at the entrance. We took that trade on purpose, to buy one data-driven place where “going through a door” happens.<\/p>\n\n\n\n
    And the open ends, since I’d rather you hear them from me:<\/p>\n\n\n\n
      \n
    • The multi-NPC door case is not validated.<\/strong> Our own design notes say, in as many words, that it must be tested and not assumed. It hasn’t been yet. I’ve argued in this post that the race can’t recur; that’s an argument, not a test result.<\/li>\n\n\n\n
    • A door that’s momentarily full has no back-off.<\/strong> Find and claim will hand off to each other in a tight loop rather than waiting. Fine for one NPC, not fine for a town.<\/li>\n\n\n\n
    • The wait-to-be-placed step has no timeout.<\/strong> If the thing it’s waiting on never happens, it waits forever.<\/li>\n\n\n\n
    • The headline pass condition \u2014 that error count going to zero \u2014 hasn’t been measured yet.<\/strong> That’s the number that decides whether any of this worked.<\/li>\n<\/ul>\n\n\n\n
      Why bother<\/h2>\n\n\n\n
      Nothing here makes the game more fun. No player will notice it. So, the argument for spending the time anyway.<\/p>\n\n\n\n
      The three-claimer design worked<\/em>. That’s the trap. Yarbo went to work, came home, went again. The only outward sign was four lines of error text nobody had to read \u2014 and against building something players can see, that loses the argument every week until the week it doesn’t.<\/p>\n\n\n\n
      Same fear as the last two posts, different hat. We’d rather pay in places that are cheap and visible than in places that are expensive and silent.<\/strong> An NPC stalled because a slot didn’t free is expensive and silent. A design where one system owns one thing, and the engine owns the rest, is legible at three in the morning eight months from now \u2014 which is when it’ll actually matter.<\/p>\n\n\n\n
      One owner per thing. Don’t reimplement what’s already under your feet. Keep custom code only where the shipped version genuinely can’t reach \u2014 and know exactly where that boundary is, because it’s the most valuable line in the system.<\/p>\n\n\n\n
      We’re not all the way there. The door currently has an engine claim on one side and our claim on the other, and that replication comment is still sitting in the processor waiting for me. But the direction is set, and I’d rather write that down mid-move than pretend it arrived finished.<\/p>\n\n\n\n
      Boring and deterministic. Still the whole strategy.<\/p>\n\n\n\n
      More from the workbench soon \u2014 and sooner than last time. If you want the louder updates, that’s what the socials are for; this corner of the site is where we leave the long notes.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"
      The post discusses the complexities encountered while redesigning how NPCs interact with doors in a game. It highlights issues with multiple systems claiming access to doors, leading to errors. The author emphasizes simplifying the process by eliminating redundant claims, ensuring a more robust design that relies on the engine’s built-in mechanisms while maintaining custom functionalities for specific cases.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"give_campaign_id":0,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"advanced_seo_description":"Explore the challenges of NPC interactions with doorways in game design. Discover how simplifying claims enhances efficiency in your code.","jetpack_seo_html_title":"Managing Multiple Claims in Game Design: A Doorway Solution","jetpack_seo_noindex":false,"jetpack_seo_schema_type":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"{title}\n\n{excerpt}\n\n{url}","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"edge","default_image_id":27,"font":"","enabled":true,"token":"eyJpbWciOiJodHRwczpcL1wvc2Vjb25kaGFuZGNhcnJvdC5jb21cL2Jsb2dcL3dwLWNvbnRlbnRcL3VwbG9hZHNcLzIwMjZcLzA0XC9GZXlsaWdodEJheUljb24ucG5nIiwidHh0IjoiQWZ0ZXIgWW91IiwidGVtcGxhdGUiOiJlZGdlIiwiZm9udCI6IiIsImJsb2dfaWQiOjI1NDEzODg1N30.4X9a_fdDbsXqeSPnqzV4lmxyDHCQoG8SmkyBdHtcDlUMQ"},"version":2},"_wpas_customize_per_network":false,"jetpack_post_was_ever_published":false},"categories":[9],"tags":[31,8,30,14,13],"class_list":["post-421","post","type-post","status-publish","format-standard","hentry","category-dev","tag-code","tag-game","tag-indie","tag-tech","tag-unreal"],"jetpack_publicize_connections":[],"jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"jetpack-related-posts":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/secondhandcarrot.com\/blog\/wp-json\/wp\/v2\/posts\/421","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secondhandcarrot.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secondhandcarrot.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secondhandcarrot.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secondhandcarrot.com\/blog\/wp-json\/wp\/v2\/comments?post=421"}],"version-history":[{"count":2,"href":"https:\/\/secondhandcarrot.com\/blog\/wp-json\/wp\/v2\/posts\/421\/revisions"}],"predecessor-version":[{"id":423,"href":"https:\/\/secondhandcarrot.com\/blog\/wp-json\/wp\/v2\/posts\/421\/revisions\/423"}],"wp:attachment":[{"href":"https:\/\/secondhandcarrot.com\/blog\/wp-json\/wp\/v2\/media?parent=421"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secondhandcarrot.com\/blog\/wp-json\/wp\/v2\/categories?post=421"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secondhandcarrot.com\/blog\/wp-json\/wp\/v2\/tags?post=421"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}