Unity가 2026년 6월 26일 공개한 Xalavier Nelson Jr. 인터뷰는 겉으로 보면 한 인디 스튜디오 대표의 제작 철학 이야기입니다. 그런데 게임을 실제로 만들어본 사람 입장에서 읽으면 조금 다르게 보입니다. 이 글은 “멋진 아이디어가 떠올랐을 때, 그걸 정말 게임에 넣어도 되는가”를 묻는 제작 메모에 가깝습니다.
Strange Scaffold는 짧은 기간에 여러 프로젝트를 동시에 굴리고, 장르와 톤을 크게 바꾸며, 작은 팀 구조 안에서 상업적인 결과를 만들어온 스튜디오입니다. 그래서 이 인터뷰가 흥미로운 지점은 “많이 만든다”가 아닙니다. 오히려 반대입니다. 많이 만들기 위해서는 무엇을 만들지보다, 무엇을 만들지 않을지 더 빨리 판단해야 한다는 이야기로 읽힙니다.
이 글에서는 Unity 인터뷰에 나온 DIDIT 프레임워크를 중심으로, 기획자, 프로그래머, 아티스트, 테크니컬 아티스트, VFX 아티스트가 기능 추가를 판단할 때 어떤 질문을 던질 수 있는지 정리해보겠습니다. 엔진 기능 소개 글은 아닙니다. 대신 팀이 실제 제작 중간에 붙잡고 볼 수 있는 결정 메모에 가깝게 보시면 좋습니다.
1. 결정 배경: 빠르게 만드는 팀일수록 기준이 먼저 필요합니다
작은 팀은 속도가 생명이라는 말을 자주 듣습니다. 맞는 말이지만, 여기에는 함정이 있습니다. 속도가 빠른 팀이 아무 방향으로나 빠르게 움직이면 더 빨리 망가집니다. 빠른 제작은 손이 빠르다는 뜻이 아니라, 판단 기준이 선명하다는 뜻에 더 가깝습니다.
Unity 인터뷰에서 Xalavier Nelson Jr.가 이야기하는 Strange Scaffold의 방식도 결국 이 문제로 모입니다. 팀은 아이디어가 많고, 하고 싶은 장르도 많고, 흥미로운 실험도 많습니다. 하지만 모든 아이디어를 끝까지 밀어붙이면 일정, 예산, 팀의 집중력, 마케팅 메시지가 함께 무너집니다. 그래서 프로젝트를 굴리는 사람은 “이 기능이 재미있다”보다 “이 기능이 지금 이 게임의 약속을 더 선명하게 만드는가”를 먼저 물어야 합니다.
개발 현장에서 기능은 거의 항상 좋은 얼굴로 찾아옵니다. 새 전투 액션은 플레이를 풍부하게 만들 것 같고, 새로운 이펙트 시스템은 화면을 더 멋지게 만들 것 같고, 추가 상호작용은 월드가 살아 있는 느낌을 줄 것 같습니다. 문제는 기능 하나가 코드 한 줄로 끝나지 않는다는 점입니다. 기획 문서, 프로토타입, 애니메이션, VFX, 사운드, UI, QA, 튜토리얼, 밸런싱, 번역, 마케팅 스크린샷까지 따라옵니다.
특히 게임 아트와 VFX 쪽은 이 비용이 눈에 잘 보이지 않습니다. “폭발을 하나 더 넣자”는 말은 간단하지만, 실제로는 머티리얼 예산, 파티클 수, 충돌 이벤트, 카메라 거리, 색 보정, 플랫폼별 스케일, 사운드 타이밍, 플레이어 피드백까지 이어집니다. 작은 팀에서 이런 결정을 감으로만 하면 나중에 “왜 이렇게 바빴는데 핵심 장면은 아직 약하지?”라는 상황이 옵니다.
그래서 이 인터뷰의 가치는 Unity라는 엔진보다 넓습니다. Unreal, Godot, 자체 엔진, 어떤 파이프라인을 쓰든 제작팀에는 비슷한 질문이 남습니다. 지금 추가하려는 기능이 정말 게임의 중심 경험을 강화하는가. 아니면 팀이 불안해서 더 많은 것을 붙이고 있는가. 이 차이를 빨리 보는 팀이 결과적으로 더 빠르게 보입니다.
2. DIDIT을 제작 언어로 바꾸면 이렇게 읽힙니다
Unity 글에서 핵심으로 등장하는 DIDIT은 단순한 체크리스트처럼 보이지만, 제작 현장에서는 꽤 강력한 회의 도구가 될 수 있습니다. 이 프레임워크를 VFX Diary식으로 풀어보면, 새 기능을 넣기 전에 다섯 가지 관점으로 압축해 묻는 방식입니다. 기능이 플레이어에게 더 나은 경험을 주는지, 팀이 감당할 수 있는지, 지금 프로젝트의 이야기와 어울리는지, 일정과 예산 안에서 살아남을 수 있는지, 그리고 실제로 이 게임이 팔리고 기억되는 데 도움이 되는지를 보는 겁니다.
중요한 점은 이 질문들이 추상적인 가치 판단으로 끝나면 안 된다는 것입니다. 예를 들어 “플레이어에게 좋다”는 말은 너무 넓습니다. 플레이어가 더 잘 이해하게 되는가, 더 빨리 반응하게 되는가, 더 오래 기억하게 되는가, 더 강한 감정을 느끼게 되는가처럼 구체적으로 쪼개야 합니다. “팀이 감당 가능하다”도 마찬가지입니다. 구현 가능 여부뿐 아니라 유지보수, 디버깅, QA, 추가 콘텐츠 제작 비용까지 같이 봐야 합니다.
예를 들어 액션 게임에서 새로운 속성 시스템을 넣는다고 해보겠습니다. 얼음, 불, 전기 속성이 들어가면 플레이어 선택지는 많아집니다. 하지만 아트팀에는 상태별 히트 이펙트, 캐릭터 피드백, 환경 반응, UI 아이콘, 튜토리얼 연출이 추가됩니다. 프로그래머에게는 데미지 타입, 저항값, 세이브 데이터, 네트워크 동기화, 툴 입력 방식이 추가됩니다. 디자이너에게는 적 배치와 난이도 곡선이 다시 열립니다. 기능은 하나지만 파급 범위는 팀 전체입니다.
DIDIT식 판단은 여기서 “재미있어 보이니까 넣자”를 멈추게 만듭니다. 이 속성 시스템이 게임의 핵심 판타지를 강화하는지, 아니면 이미 있는 액션을 흐리게 만드는지 봐야 합니다. 플레이어가 실제로 읽을 수 있는 수준인지도 중요합니다. 화면에 이펙트가 많아졌는데 전투 판단이 흐려지면, VFX 입장에서는 열심히 만든 작업이 오히려 게임 경험을 방해하는 결과가 될 수 있습니다.
반대로 기능을 자르는 결정도 더 설득력 있게 말할 수 있습니다. “시간이 없어서 못 합니다”가 아니라 “이 기능은 현재 프로젝트의 핵심 약속에 비해 QA와 아트 비용이 크고, 플레이어가 체감할 차이는 작습니다”라고 설명할 수 있습니다. 팀 회의에서 이런 문장으로 말할 수 있으면 감정 싸움이 줄어듭니다. 누군가의 아이디어가 나빠서가 아니라, 지금 프로젝트의 우선순위와 맞지 않는다는 판단이 되기 때문입니다.
3. 작은 팀의 아트와 디자인은 덜 만들기가 아니라 정확히 만들기입니다
인디 제작에서 “스코프를 줄이라”는 말은 너무 많이 반복돼서 오히려 힘이 빠진 표현이 됐습니다. 줄이라는 말만 들으면 뭔가 포기하는 느낌이 듭니다. 하지만 Strange Scaffold식 접근에서 배울 수 있는 지점은 단순한 축소가 아니라 정확도입니다. 더 적게 만드는 것이 아니라, 게임이 약속한 감정과 플레이를 정확히 겨냥하는 것입니다.
아티스트 입장에서 이 차이는 중요합니다. 작은 팀이라고 해서 화면이 허술해도 된다는 뜻은 아닙니다. 오히려 작은 팀일수록 화면의 우선순위가 더 날카로워야 합니다. 한 장면에서 플레이어가 반드시 봐야 하는 실루엣, 캐릭터의 상태, 위험 신호, 보상 피드백, 분위기를 만드는 색과 조명은 살아야 합니다. 대신 플레이어가 거의 읽지 못하는 장식, 시스템상 의미가 없는 변주, 출시 직전까지 유지해야 하는 과도한 비주얼 옵션은 과감히 줄여야 합니다.
VFX 작업도 마찬가지입니다. 이펙트는 “많을수록 좋다”가 아닙니다. 화면이 복잡한 게임에서는 강한 이펙트 하나가 약한 이펙트 열 개보다 낫습니다. 플레이어가 회피해야 할 공격, 내가 성공했다는 피드백, 위험 구역, 상태 이상, 보스의 페이즈 전환처럼 기능이 분명한 곳에 비용을 쓰는 편이 좋습니다. 반대로 모든 상호작용에 고급 이펙트를 붙이면 첫인상은 화려해질 수 있지만, 실제 플레이에서는 정보량이 과해집니다.
기획자와 디자이너도 이 관점에서 아트 요청을 더 구체적으로 해야 합니다. “좀 더 멋있게”가 아니라 “플레이어가 0.3초 안에 위험 방향을 읽어야 한다”, “이 스킬은 성공 보상보다 취소 가능성을 먼저 보여줘야 한다”, “이 장면은 스크린샷보다 반복 플레이 피로도가 중요하다”처럼 말해야 아트와 VFX가 정확히 움직일 수 있습니다. 기능 추가 여부도 같은 기준으로 판단됩니다.
프로그래머 입장에서는 툴과 데이터 구조가 이 결정을 도와야 합니다. 팀이 매번 엔진 안에서 손으로만 조정해야 한다면 작은 기능도 비싸집니다. 반대로 색, 강도, 지속 시간, 프리셋, 플랫폼 스케일을 데이터로 조정할 수 있으면 기능을 작게 실험하고 빠르게 버릴 수 있습니다. 결정 기준이 아무리 좋아도 파이프라인이 무거우면 팀은 결국 결정을 미루게 됩니다.
그래서 “작게 만들자”는 말을 “정확히 만들자”로 바꿔보는 것이 좋습니다. 정확히 만들면 줄일 것도 보이고, 남겨야 할 것도 보입니다. 그리고 남긴 것에는 더 많은 에너지를 쓸 수 있습니다. 플레이어는 개발 중 삭제된 기능의 수를 모릅니다. 대신 남은 장면이 얼마나 선명한지는 바로 느낍니다.
4. 플레이어 관점에서는 기능 수보다 약속이 먼저 보입니다
게이머 입장에서 생각해보면 답은 더 단순해집니다. 플레이어는 게임을 시작할 때 기능 목록을 전부 외우고 들어오지 않습니다. 대신 “이 게임은 나에게 어떤 기분을 줄 것인가”를 아주 빠르게 판단합니다. 코미디 액션인지, 불편한 공포인지, 정교한 전술인지, 편안한 탐험인지, 기묘한 캐릭터 드라마인지 같은 약속이 먼저 들어옵니다.
Strange Scaffold가 여러 독특한 프로젝트를 만들 수 있었던 이유도 결국 이 약속을 강하게 잡는 방식과 연결됩니다. 게임이 이상해도, 작아도, 장르가 익숙하지 않아도, 플레이어가 “아, 이 게임은 이런 감정을 주려는구나”라고 받아들이면 따라갈 수 있습니다. 반대로 기능은 많지만 약속이 흐리면 플레이어는 금방 피곤해집니다.
이 지점은 VFX와 연출에도 직접 연결됩니다. 예를 들어 코미디 톤 게임에서 지나치게 진지하고 사실적인 폭발 이펙트를 쓰면 퀄리티가 높아도 어긋날 수 있습니다. 반대로 어두운 심리 액션에서 장난감 같은 피드백을 쓰면 플레이어가 세계를 믿기 어렵습니다. 같은 기술이라도 게임의 약속에 따라 맞는 표현이 달라집니다.
기능을 추가할 때도 플레이어의 머릿속 문장을 상상해볼 필요가 있습니다. 이 기능을 넣으면 플레이어가 게임을 더 쉽게 설명할 수 있는가. 친구에게 추천할 때 더 선명한 한 문장이 생기는가. 스트리밍이나 쇼츠에서 바로 이해되는 순간이 생기는가. 아니면 개발팀 내부에서만 의미 있는 복잡도가 늘어나는가.
이 질문은 마케팅만의 문제가 아닙니다. 제작 중간에도 계속 돌아옵니다. 플레이어가 알아차리지 못하는 복잡도는 가치가 없는가? 꼭 그렇지는 않습니다. 하지만 플레이어가 알아차리지 못하는데 유지 비용이 크고, 버그 가능성도 높고, 핵심 장면을 흐린다면 우선순위를 낮춰야 합니다. 반대로 플레이어가 바로 느끼는 작은 피드백이라면 코드나 아트 비용이 비교적 작아도 큰 가치를 만들 수 있습니다.
게임 개발자에게 무서운 것은 기능이 없는 게임이 아닙니다. 약속이 흐린 게임입니다. 기능은 나중에 설명할 수 있지만, 약속은 첫 5분 안에 느껴져야 합니다. 이번 Unity 인터뷰를 읽으며 가장 크게 남는 것도 이 부분입니다. 좋은 제작 판단은 개발팀의 할 일 목록을 줄이는 동시에, 플레이어가 기억할 한 문장을 더 강하게 만듭니다.
5. Unity 맥락에서 보면 툴 선택보다 제작 리듬이 중요합니다
Unity가 이 인터뷰를 자사 블로그에서 다룬 것도 흥미롭습니다. 엔진 회사의 글이라면 보통 기능, 성능, 워크플로 개선을 전면에 내세우기 쉽습니다. 그런데 이번 글은 특정 기능 소개보다 창작자의 제작 방식에 더 가깝습니다. Unity가 별도로 제공하는 인디 개발자용 자료와 함께 보면, 메시지는 “작은 팀도 제대로 된 제작 판단과 반복 구조를 갖춰야 한다” 쪽으로 읽힙니다.
이 부분은 Unreal 사용자에게도 의미가 있습니다. 엔진 선택은 중요하지만, 엔진이 팀의 결정을 대신해주지는 않습니다. Unity를 쓰든 Unreal을 쓰든, 팀은 여전히 같은 질문을 해야 합니다. 프로토타입을 얼마나 빨리 만들 것인가, 어떤 기능을 데이터화할 것인가, 어느 시점에 퀄리티 기준을 잠글 것인가, 플랫폼별 테스트를 언제 시작할 것인가, 어떤 장면을 데모의 중심으로 삼을 것인가.
Unity 기반 작은 팀은 에셋 스토어, 패키지, 빠른 프로토타입, 다양한 플랫폼 대응에서 이점을 얻을 수 있습니다. 하지만 그만큼 쉽게 기능을 붙일 수 있다는 위험도 있습니다. “패키지가 있으니까 넣자”는 결정은 특히 조심해야 합니다. 무료이거나 저렴한 기능도 프로젝트 안에 들어오는 순간 유지 비용을 가집니다. 버전 호환, 아트 톤 통일, 빌드 크기, 입력 충돌, 세이브 구조, QA 케이스가 생깁니다.
Unreal 팀도 비슷합니다. 플러그인, Marketplace 에셋, 샘플 프로젝트, MetaHuman, Niagara 시스템, PCG, Motion Matching, MegaLights 같은 강력한 기능이 많을수록 선택은 더 어려워집니다. 좋은 기능이 너무 많기 때문에, 프로젝트가 지금 필요로 하는 기능과 나중에 배워도 되는 기능을 나눠야 합니다. 기술적으로 가능하다는 사실은 제작적으로 해야 한다는 뜻이 아닙니다.
테크니컬 아티스트에게는 이 지점이 특히 중요합니다. TA는 종종 “가능하게 만드는 사람”으로 불립니다. 하지만 좋은 TA는 모든 것을 가능하게 만드는 사람이 아니라, 팀이 감당 가능한 방식으로 가능성을 정리하는 사람에 가깝습니다. 새 셰이더 기능, 머티리얼 파라미터, VFX 프리셋, 툴 자동화가 팀의 판단 속도를 높이면 좋은 투자입니다. 반대로 누구도 유지하지 못하는 고급 기능은 출시 직전 부채가 됩니다.
결국 툴 선택은 제작 리듬을 돕기 위한 수단입니다. 어떤 엔진이 더 좋으냐보다, 우리 팀이 어떤 결정을 얼마나 자주, 얼마나 명확히 내릴 수 있느냐가 더 중요합니다. Unity 인터뷰는 이 점을 기술 외부의 언어로 보여줍니다. 작은 팀이 살아남기 위해 필요한 것은 만능 엔진이 아니라, 기능을 받아들이고 거절하는 명확한 기준입니다.
6. 팀에서 바로 써볼 수 있는 결정 메모
이 글을 실제 회의에 쓰려면 아주 짧은 문서로 바꾸는 것이 좋습니다. 새 기능이나 새 비주얼 시스템이 제안될 때마다 긴 기획서를 먼저 쓰기보다, 한 페이지짜리 결정 메모를 작성해보는 겁니다. 목표는 결정을 늦추는 문서가 아니라, 애매한 흥분을 명확한 판단으로 바꾸는 문서입니다.
첫 번째 줄에는 기능의 이름이 아니라 플레이어 약속을 씁니다. “속성 시스템 추가”보다 “플레이어가 적의 약점을 읽고 즉흥적으로 대응하게 만든다”가 낫습니다. 이렇게 쓰면 이후 판단이 훨씬 쉬워집니다. 기능이 그 약속을 강화하지 못하면 이름이 멋져도 우선순위는 내려갑니다.
두 번째로 팀 비용을 직군별로 나눕니다. 기획, 프로그래밍, 아트, VFX, 사운드, UI, QA, 플랫폼, 마케팅까지 아주 짧게 적습니다. 정확한 공수 산정이 아니어도 괜찮습니다. 중요한 것은 비용이 한 사람의 작업으로 보이지 않게 만드는 것입니다. 게임 기능은 거의 항상 여러 직군의 약속입니다.
세 번째로 실패했을 때의 모습을 적습니다. 기능이 망하면 어떤 일이 벌어지는가. 플레이어가 이해하지 못하는가, 성능이 깨지는가, 콘텐츠 제작 속도가 떨어지는가, 스크린샷은 좋아도 반복 플레이가 피곤해지는가, QA가 감당하기 어려운 조합이 생기는가. 실패 모습을 먼저 적으면 기능을 작게 실험할 방법이 보입니다.
네 번째로 최소 실험 버전을 정합니다. 완성형 기능을 바로 만들지 말고, 플레이어 약속을 검증할 가장 작은 형태를 잡습니다. VFX라면 최종 퀄리티 이펙트가 아니라 컬러 블록, 타이밍, 화면 점유율부터 테스트할 수 있습니다. 프로그래밍이라면 전체 시스템 대신 한 상황에서만 작동하는 얇은 프로토타입으로 충분할 수 있습니다.
다섯 번째로 삭제 기준을 미리 적습니다. 이 기능을 언제 포기할 것인가를 정해두지 않으면 팀은 이미 쓴 시간이 아까워서 계속 붙잡게 됩니다. 예를 들어 2주 안에 플레이어가 의도를 이해하지 못하면 보류, 목표 플랫폼에서 프레임 예산을 넘으면 축소, 튜토리얼 없이는 이해되지 않으면 디자인 재검토처럼 조건을 둘 수 있습니다.
이 메모는 프로듀서만 쓰는 문서가 아닙니다. 아티스트도 쓸 수 있고, TA도 쓸 수 있고, 디자이너도 쓸 수 있습니다. 중요한 것은 “내 작업이 필요하다”를 증명하려는 문서가 아니라, “이 게임이 지금 무엇을 필요로 하는가”를 같이 보는 문서가 되는 것입니다. 회의가 길어질수록 이런 짧은 기준이 오히려 팀을 빠르게 만듭니다.
7. 포트폴리오와 교육 콘텐츠로도 좋은 주제입니다
VFX Diary 관점에서 이 주제는 포트폴리오와 교육 콘텐츠로도 꽤 좋습니다. 많은 포트폴리오가 결과물 중심으로만 구성됩니다. 멋진 이펙트, 잘 만든 셰이더, 깔끔한 환경, 완성된 UI를 보여주는 것은 당연히 중요합니다. 하지만 실무자는 결과물만 보지 않습니다. 이 사람이 어떤 기준으로 만들었고, 무엇을 줄였고, 어떤 플레이어 정보를 우선했는지도 봅니다.
예를 들어 포트폴리오에 전투 히트 이펙트를 넣는다면 단순히 “불꽃 이펙트 제작”이라고 쓰기보다, 의사결정 메모를 함께 보여줄 수 있습니다. 이 이펙트의 목표는 플레이어에게 피격 성공을 0.2초 안에 전달하는 것, 색상은 적 공격 이펙트와 충돌하지 않게 한 것, 모바일에서는 파티클 수를 줄이고 스프라이트 애니메이션을 유지한 것, 카메라가 멀어질 때 실루엣만 남도록 LOD를 조정한 것처럼 설명하는 방식입니다.
이런 설명은 기술 자랑보다 강합니다. 왜냐하면 팀에서 같이 일할 수 있는 사람처럼 보이기 때문입니다. 실무에서는 멋진 것을 만드는 능력만큼, 지금 프로젝트에 맞는 크기로 만드는 능력이 중요합니다. 기능을 줄이는 판단, 성능 예산 안에서 표현을 살리는 판단, 디자이너의 의도를 화면 언어로 바꾸는 판단이 포트폴리오의 신뢰도를 높입니다.
교육 콘텐츠로도 연결하기 좋습니다. “Niagara로 멋진 폭발 만들기”도 좋은 주제지만, 한 단계 더 나아가 “이 폭발을 언제 쓰면 안 되는가”, “플레이어 정보 전달용 이펙트와 분위기용 이펙트는 어떻게 다르게 설계하는가”, “작은 팀에서 VFX 요청서를 어떻게 쓰면 좋은가” 같은 콘텐츠를 만들 수 있습니다. 이런 주제는 초보자에게도 실무 감각을 줍니다.
개발자와 디자이너도 같은 방식으로 자기 작업을 기록할 수 있습니다. 입력 시스템을 만들었다면 왜 액션 맵을 나눴는지, AI 동료를 만들었다면 빠른 행동과 느린 추론을 어떻게 분리했는지, 레벨 디자인을 했다면 어떤 장면을 삭제해서 핵심 루프를 선명하게 만들었는지 기록할 수 있습니다. 결과물 뒤에 판단을 보여주는 포트폴리오는 단순한 기술 데모보다 오래 기억됩니다.
그리고 블로그 운영 관점에서도 이런 글은 가치가 있습니다. 최신 기술 업데이트만 따라가면 글의 리듬이 비슷해지기 쉽습니다. 반면 제작 판단, 팀 구조, 플레이어 약속, 기능 삭제 기준 같은 글은 독자가 자기 프로젝트에 바로 적용할 수 있습니다. VFX Diary가 단순 뉴스 요약이 아니라 실무형 아카이브가 되려면, 이런 의사결정형 글이 사이사이에 필요합니다.
게임 기능을 더 넣기 전에 멈춰야 할 때: Unity가 조명한 Strange Scaffold식 작업 메모
Unity의 2026년 6월 26일 Xalavier Nelson Jr. 인터뷰는 “인디 스튜디오가 어떻게 많이 만들었나”로만 읽기에는 아깝습니다. 더 중요한 질문은 “작은 팀이 어떻게 기능을 고르고, 버리고, 선명하게 만드는가”입니다. 이 질문은 Unity 사용자에게만 해당하지 않습니다. Unreal, Godot, 자체 엔진을 쓰는 팀도 똑같이 마주합니다.
이번 글의 실무적인 결론은 단순합니다. 새 기능을 넣기 전에 플레이어 약속, 팀 비용, 실패 모습, 최소 실험, 삭제 기준을 먼저 적어보는 것입니다. 이 다섯 가지를 적는 데 오래 걸린다면, 그 기능은 아직 팀 안에서 충분히 정리되지 않았을 가능성이 큽니다. 반대로 짧게 정리된다면, 구현 전부터 좋은 대화가 시작됩니다.
게임을 풍부하게 만드는 것은 기능의 개수만이 아닙니다. 때로는 기능을 덜어내는 판단이 게임을 더 강하게 만듭니다. 아트와 VFX도 마찬가지입니다. 더 많이 보여주는 것보다, 플레이어가 정확히 느껴야 할 순간을 선명하게 만드는 것이 중요합니다. Strange Scaffold식 제작 철학에서 우리가 가져갈 수 있는 가장 현실적인 교훈은 바로 이 지점입니다.
참고 출처
- Unity Blog, “Xalavier Nelson Jr. of Strange Scaffold shares lessons on building games that break the mold”, 2026-06-26: https://unity.com/blog/xalavier-nelson-strange-scaffold
- Unity, “The Indie Survival Guide”: https://unity.com/campaign/indie-survival-guide
- Strange Scaffold official site: https://www.strangescaffold.com/
- Steam store page, “Truck-Kun is Supporting Me from Another World”: https://store.steampowered.com/app/3642010/Truckkun_is_Supporting_Me_from_Another_World/
작업 이야기와 댓글
이 글을 보고 떠오른 질문이나 경험을 남겨 주세요. 서로의 시도와 관찰을 나누는 공간입니다.