더블즈비의 기묘한 공방

게임회사 리드 개발자 1년차 후기

Doublsb — Sat, 14 Feb 2026 03:15:39 +0900

어쩌다보니 운과 타이밍이 잘 겹쳐 현재 재직중인 회사에서 리드 개발자로 일하고 있다. 2024년 11월부터 재직했으니 1년 반이 되어가고 있는 셈이다.

처음에는 이렇게나 다양한 업무를 하게 될지 몰랐고, 외부와 교류를 할 때 거창한 칭호로 스스로를 소개해야 해서 부끄럽기도 했었다. 사수가 없어지니까 성장에 대한 불안감도 있었고. 근데 자리가 사람을 만든다는 말이 진짜인 것 같다. 돌아보니 제법 성장했다.

그리고 글로 정리하지 않으면 금방 머릿속에서 사라질 것 같다는 기분이 들었다. 당장 글을 쓰도록 하자.

리드 개발자라고 하면 거시적인 코드 설계와 주니어 성장에만 신경쓰면 될 거라고 착각하고 있었다.

다만 내가 실제로 겪은 업무는 좀 차이가 있었다.

프로젝트 핸들링하기

우선 모든 부서와 직원들의 역량을 파악하고 있어야 했다. 이것은 개발 파트 뿐만이 아니라 기획/아트 파트의 역량도 알고 있어야 한다는 것이다. 디렉터가 현장을 지휘하는 것은 맞지만, 실제 개발 규모에 관한 키를 잡고 있는 건 나라고 느껴졌다. 디렉터가 원하는 기획을 제공하면, 나는 그 기획을 현실적으로 어디까지 실체화시킬 것인지를 논의하고 일정을 설계해야 했다.

초기에는 개발 파트만 속도를 내면 일정을 당길 수 있을 것이라 착각했는데, 실제로는 타 파트의 일정 배분이나 처음 겪는 파이프라인 등의 이슈가 있어 그보다 훨씬 늦어졌다. 실제 개발 일정은 예상보다 2배 늘어난다는 말이 실제로 일어날 줄이야... 많이 배운 것 같다.

개발-아트 파이프라인을 명시해서 협업해야 한다는 것도 이번에 깊게 깨달은 사실이다. 애니메이터 컨벤션을 설정해놓지 않고 작업했었는데, 이것이 후반부 폴리싱 작업을 어렵게 만드는 원인이 되었다. '다 프로들이니까 알아서 잘 하겠지'라고 생각하지 말았어야 했고, 프리팹 구조나 연출 가이드라인을 협의해서 깃 충돌이나 작업이 추가로 생기는 경우를 없애야 했다.

그리고... YAGNI 원칙은 프로젝트 설계에서는 조금 내려놓는 게 낫다고 생각했다. 예시로 입사 전부터 라이브중이던 프로젝트는 글로벌 출시를 전혀 고려하지 않았기에, 현지화 작업을 위해 대단히 고통스러운 노력을 해야만 했다. 라이브중인 게임의 기존 유저 세이브와 호환되도록 구조를 갈아엎었던 걸 다시 떠올려보면 아찔하다. 만약 미리 현지화를 고려했다면 오래 걸리지 않았을 것이다.

지금으로서 미리 고려해도 된다고 생각하는 항목들은 현지화, 콘솔 입출력, 크로스 플랫폼 등인 것 같다.

주니어 개발자 키우기

교육과를 졸업해서 그런지 적성에 맞는 일 중 하나인 것 같다. 면담을 해서 미래에 하고 싶은 전문 분야를 파악하고, 흥미가 있는 부분들을 고려해서 프로젝트를 배치하는 것. 그리고 성장 가능한 업무를 던져 주는 것이 뿌듯한 것 같다. 질문을 많이 받는 것도 좋았다. 설명충이라서 그런가보다. 그들이 되고 싶은 것과 잘하는 것의 괴리를 보았을 때 어떻게 가이드를 해 줘야 하는지는 여전히 잘 모르겠지만... 아무튼 재밌다.

현 회사는 입사 이전부터 PR 리뷰 문화가 있어서 자연스럽게 검수 업무도 하게 되었다.

처음에는 내가 얼마나 잘 해줄 수 있을까라는 막연한 두려움이 있었는데, 그 연차에 겪는 이슈들은 대부분 동일하다는 게 재미있었다. 주로 성능적으로 문제가 될 수 있는 부분이나 설계 안정성, 그리고 유지보수성에 관한 조언을 줬던 것 같다.

PR의 경우 컨벤션이나 코드 스타일에 관해서는 크게 피드백을 주지 않고 있다. 작은 팀은 클린 코드에 집착하는 것보다는 추상화와 생산성에 집중하는 게 더 옳은 방식이라고 생각해 유지하고 있다.

라이브러리 만들기

독립적이고 회사 자산으로 남길 수 있는 코드들을 패키지화해서 공유하는 작업이었다. 이전 리드 개발자분의 MVVM 기반 라이브러리도 존재했지만, 적은 인원 규모 입장에서는 레이어 깊이를 유지하는 비용이 더 컸다. 그래서 팀 규모와 속도를 고려하여 의존성을 단순화한 아키텍처를 짜게 되었다. 실제로 개발 속도가 이전에 비해 급격하게 상승했고, 게임 개발의 근본적인 문제에 더 집중할 수 있게 되었다.

다만 특정 라이브러리는 여전히 작업 중이다. 모바일 도메인을 가진 사람이었다보니 콘솔 입출력 대응을 적용하는 데에 고통을 겪고 있다. 프로젝트 초기부터 잘 적용해놓는 게 중요하다는 것을 여실히 느끼는 중... 다음 프로젝트에서는 절대 대비해야지.

CI/CD 작업하기

생산성 있는 배포를 위해 젠킨스도 자주 건드리게 되었다. 파편화되어 있던 아이템을 하나의 워크플로우로 통합하는 등의 작업을 했다. 신규 프로젝트의 빌드 아이템을 생성하는 건 이제 꽤 자연스러워졌다.

백엔드 업무하기

설계까지 하는 것은 아니므로 딥하지는 않은데, 기존 라이브중인 프로젝트를 유지보수 해야 하는 경우가 있어 업무 바운더리에 들어왔다. 비용의 미학은 최적화 빌런인 나로서는 꽤나 흥미로운 부분이지만, 어떻게 하면 비용을 낮출 수 있는지에 대한 문제제기를 하는 것부터 막히기 때문에 2026년은 백엔드를 깊게 배우기로 정했다. 고통이야!

네트워킹 하기

진짜 못하는 부분이다. 맨 처음 부분에서도 써 뒀지만 스스로를 강해보이는 직책으로 표현하는 것이 어렵다...

어느 포지션을 취해야 하는지도 잘 모르겠어서 듣는 이의 입장을 취하고 있다. 앞으로 이런 기회가 더 늘어날 것 같은데 고민이다.

정리

결국 소규모 팀의 팀원 > 1인 개발자 > 소규모 팀의 리드 개발자라는 테크트리를 타게 되었는데, 실무보다는 관리 경험의 비율이 점점 더 늘어나고 있다고 느낀다. 기업이 잘 되는 방향으로 내가 강해지는 것도 좋지만, 주니어 개발자를 키우고 책임을 위임하는 것이 더 바람직하다는 것을 많이 느끼고 있다. 넓은 시야를 가짐으로서 성장하는 것은 정말 귀중한 경험인 것 같다.

별개로 년차에 비해 일찍 관리직으로 전환한 것이 아닌가에 대해서는 아직도 열등감이 남아 있다. 팀원으로 더 오래 남아 있으면 사수님의 코드를 보면서 더 넓은 시야를 가질 수 있지 않았을까 하는 불안감이다. 그런 만큼 더 다양한 코드를 의도적으로 읽고 개인 프로젝트를 주기적으로 돌리면서 감각을 잃지 말아야 한다는 생각이 든다. 사실 이런 생각도 팀원으로만 있었다면 얻지 못했을 것 같다. 열등감을 버리고 강해지자.

아무튼, 네가 선택한 기업이니 내가 강하게 키우겠다는 마음을 잃지 말고 정진하자.

Please One More Block 개발 회고

Doublsb — Wed, 17 Dec 2025 03:09:18 +0900

어떻게 일을 꾸몄나

오랜만에 개인 작품을 내고 전시까지 했다. (~~그렇다곤 하는데 1년에 하나씩은 내는 것 같다~~)

Out of Index 2025, 즉 실험 게임 페스티벌은 3년만에 열렸다. 2019년에 관람객으로 참여했을 때 너무나도 즐겁고 인상 깊었기에, 접수를 받는다는 소식을 듣자마자 득달같이 달려들었다. 개발 동료로는 나를 OOI에 처음 데려가줬던 챠로를 영입했다. 소꿉친구면서도 같이 프로젝트를 한 적이 한 번도 없어서 벼르고 있었는데, 마침 좋은 기회라고 생각했다.

첫 기획 자체는 21년도에 나왔다. 지금과는 비슷해보이면서도 다른 편인 것 같다.

다른 사람이 세계의 정보를 넘겨줌(시드 개념)
시드의 개념을 넘겨주면서 한마디를 추가로 씀
"이 길이 정답이니까 믿어봐라" 같은... 아니면 "엿이나 한번 먹어보시지"
시드를 받는 사람은 그 한마디를 보고 플레이할지 말지 결정할 수 있다.
게임을 클리어하면 시드를 만들어낼 수 있다.

추가 (21.01.17)
서버에서 그날 테마를 정하고, (ex 완벽한 황금비) 게임 플레이 후 컨텐츠 하나를 추가함
이 때 컨텐츠는 슈마메같이 블럭 하나를 추가하는 것이며, 정각에 결산.
목표에 도달했으면 컨텐츠에 참여한 모두가 돈을 나눠가진다
- 예상 시나리오 1 : 완벽한 황금비
목표는 50퍼센트의 승률을 내기 (오차 2퍼센트)
- 예상 시나리오 2 : 지나치게 쉬운 게임 등... 더 이상은 안 떠오르네

추가 (21.06.21)
실험게임 페스티벌용 아이디어 - 집단골려먹기 놀이
원래 OOI에 내려던 아이디어 몇 개가 있었는데, 언제나 그렇듯이 드랍된(...) 내용.
플랫포머 게임. 평범하게 플레이한 뒤 죽으면 화면 내의 블럭을 하나씩 변경할 수 있다.
투명 블럭이라던가, 점프 블럭이라던가 등등.
변경된 내용은 자신의 아이디와 함께 기록되며, 페스티벌이 종료됐을 때 부문별로 시상한다.
- 킬러 : 배치한 블록으로 가장 많이 죽인 사람
- 제작이 하고 싶었어요 : 가장 많이 블록을 배치한 사람
- 맘에 안 들어 : 기존 유저가 만든 블록을 가장 많이 변경한 사람
페스티벌 종료 시 가능하다면 마지막 버전으로 온라인에 배포. 개발자도 플레이해보고 소감을 남긴다.
개인적으로는 이 집단지성의 끝에는 게임이 미친듯이 어려워지는 결말을 예상하고 있음.

추가 (210829)
맵에 블럭을 추가하고 점수를 받기
그 블럭 근처에서 죽었다
해당 블록을 많이 밟았다
해당 블록때문에 죽었다
아예 밟히지도 않았다
블럭의 목표 + 위치 + 기능을 조합해서 점수 받기
한번도 안 밟히는 게 목표 > 위치 설정 > 밟았을 때의 기능 설정

당시에는 그냥 기획적 취향으로 혼돈이 가득한 결과물을 보고 싶었던 것 같다. 실제 Please One More Block은 기획을 다듬어서 일부만 즐길 수 있는 게임이 아니라, 모두가 공평하게(?) 즐길 수 있는 게임으로 갈무리 된 것 같음. 지금은 위에 있는 기획보다는 플레이어가 '필요해서' 도움 요청을 누르고, 사람들이 배치한 블록을 '랜덤으로' 가져간다는 게 좋은 것 같다는 내면적 결론이 나왔다.

아래는 클로드와 얘기하면서 자체적으로 기획을 다듬은 것. 길어서 더보기 블록으로 줄였다.

기록에 초장부터 '복수하겠어!'라는 이름이 나오는데, 그냥 임팩트 있는 제목부터 만들려다 보니 그런 것이다. 본래 의도에 복수가 들어 있지는 않음.

클로드랑 대화하면서도 녀석의 말을 대부분 무시하면서 내 말만 하고 있는데, 원래 AI랑 대화하면서 하는 기획이 다 그런 것 같다 (...)

[나]

복수하겠어! 라는 타이틀로 게임을 만들려고 함.
이 게임은 OOI에 나갈 실험게임인데, 이전 플레이어의 마지막 액션으로 특정한 위치에 블럭을 놓아서 그 이전 플레이어에게 복수하거나 아니면 이후 플레이어한테 복수할 수 있는 컨셉임.
이 때 타이틀을 영어로 표현하려면 뭐라고 하는게 가장 적절할까?

[클로드]
"복수하겠어!"라는 타이틀을 영어로 표현할 때, 게임의 컨셉과 감정을 고려하면 몇 가지 좋은 옵션이 있습니다:

추천 옵션들:
"I Will Have My Revenge!" - 가장 직접적인 번역으로, 강한 의지와 결의를 표현
"Revenge!" - 단순하고 임팩트 있는 한 단어 제목
"Sweet Revenge" - 복수의 달콤함을 표현하는 클래식한 표현
"Payback Time" - 게임적이고 캐주얼한 느낌
"Vendetta" - 지속적인 복수를 의미하는 강렬한 단어

게임 컨셉을 고려한 특별 제안:
"Chain Reaction" - 플레이어들 간의 연쇄 복수를 암시
"Block & Revenge" - 블록을 놓는 메커니즘을 직접 언급
"The Last Laugh" - 마지막에 웃는 자가 승자라는 의미
OOI(온라인 오픈 이노베이션) 실험게임이라는 점을 고려하면, "Revenge!" 나 "Chain Reaction" 이 가장 적절할 것 같습니다. 전자는 직관적이고 임팩트가 있고, 후자는 게임의 메커니즘을 잘 표현하면서도 흥미로운 제목이 됩니다.

어떤 느낌의 제목을 원하시는지 알려주시면 더 구체적으로 추천해드릴 수 있습니다!

[나]
please one more block으로 할게...

[클로드]
"Please One More Block"은 정말 좋은 선택이네요!

이 제목이 특히 효과적인 이유:
간청과 위협의 이중성 - "Please"라는 정중한 표현과 복수라는 게임 컨셉의 대비가 흥미로움
게임 메커니즘 직접 언급 - "Block"이 핵심 게임플레이 요소를 바로 드러냄
긴장감 조성 - "One More"가 마지막 기회, 결정적 순간의 느낌을 줌
기억하기 쉬움 - 간단하고 직관적인 구조
게임의 컨셉과도 완벽하게 맞아떨어집니다. 플레이어가 마지막 블록을 놓기 전에 하는 간청 같기도 하고, 동시에 "이 블록 하나로 복수하겠다"는 의미로도 해석될 수 있어서 정말 잘 지은 제목인 것 같습니다.

OOI 실험게임으로서도 호기심을 자극하는 좋은 타이틀이 될 것 같아요!

[나]
게임 기획에서 필수 요소가 뭐가 있을까? 시스템 말고, 의도나 요구하는 경험 등의 항목을 말함.

[클로드]
게임 기획에서 의도와 경험 측면의 필수 요소들:

핵심 경험 설계
감정적 여정 (Emotional Journey)

플레이어가 느껴야 할 감정의 흐름과 강도
긴장감, 성취감, 좌절감 등의 타이밍과 균형
플레이어 에이전시 (Player Agency)

의미 있는 선택과 그 결과에 대한 책임감
플레이어의 행동이 실제로 게임에 영향을 미친다는 느낌
동기 구조
내재적 동기 vs 외재적 동기

플레이 자체의 재미 vs 보상을 위한 플레이
자율성, 숙련도, 목적의식의 제공
몰입 조건 (Flow State)

도전과 능력의 적절한 균형
명확한 목표와 즉각적인 피드백
사회적 경험
상호작용의 질

협력, 경쟁, 갈등의 의미와 깊이
타인과의 관계에서 오는 감정적 투자
소속감과 정체성

커뮤니티 내에서의 역할과 위치
개인의 플레이 스타일이 반영되는 정체성
학습과 성장
숙련도 곡선

배우기 쉽고 마스터하기 어려운 구조
점진적 복잡성 증가
발견의 즐거움

새로운 전략, 비밀, 가능성의 발견
플레이어만의 독창적 해결책 창조
당신의 "Please One More Block" 게임의 경우, 특히 복수라는 감정적 만족과 연쇄적 상호작용이 핵심 경험이 될 것 같은데, 어떤 부분을 가장 중요하게 생각하시나요?

[나]
좋아. 그럼 네가 쓴 가이드라인을 토대로 하나씩 정리해보자. 질문을 끝없이 해 줘.

일단 Please One More Block의 경우 사실 게임이지만 오프라인에서 겪을 수 있는 특이한 점을 추가로 느끼도록 만들 게임이야.

이전 플레이어의 플레이가 다음 플레이어에게 영향을 미치는 구조이고, 간단한 플랫포머 형식을 차용해서 블록을 배치하되, 이전 플레이어가 다음 플레이어에게 하나의 블록을 더해서 제공하는 방식으로 진행할 수 있다고 할 수 있어.

[클로드]
흥미로운 컨셉이네요! 오프라인에서는 경험할 수 없는 독특한 연결감을 만들겠다는 의도가 명확해 보입니다.

첫 번째 질문부터 시작해볼게요:

감정적 여정에 대해서:

플레이어가 게임을 시작할 때 느껴야 할 첫 번째 감정은 무엇인가요?

이전 플레이어가 남긴 블록 배치를 처음 봤을 때 "아, 이 사람이 나를 도우려고 했구나" 하는 감사함을 느끼게 하고 싶나요?
아니면 "이 사람이 나를 방해하려고 했구나" 하는 도전 의식을 느끼게 하고 싶나요?
아니면 "이 블록이 도움이 될지 방해가 될지 모르겠다" 하는 불확실성과 호기심을 느끼게 하고 싶나요?
그리고 게임을 끝낼 때는 어떤 감정으로 마무리되기를 원하시나요?

[나]
감정적 여정은 그걸 모두 포함해. 이전 플레이어가 만든 의도가 먹혀들었는지 이전 플레이어가 볼 수 있었으면 좋겠고, 다음 플레이어는 이 사람이 나쁜지 좋은지 파악하며 게임을 진행하고 싶을 거야.

결과적으로는 모든 플레이어들이 모여서 게임을 깰 수 있도록 만드는... 혹은 못 깨게 만드는 경험을 하게 만들고 싶어.

[클로드]
아하! 정말 흥미로운 다층적 경험이네요. 이전 플레이어의 의도 파악 → 자신의 의도 실행 → 결과 확인의 순환구조가 핵심이군요.

플레이어 에이전시에 대한 질문:

이전 플레이어가 자신의 의도가 "먹혔는지" 확인할 수 있는 방법이 중요할 것 같은데요.

피드백 시스템: 이전 플레이어가 다음 플레이어의 반응을 어떻게 볼 수 있게 할 건가요?
다음 플레이어가 그 블록을 어떻게 활용했는지 replay를 보여줄 건가요?
아니면 단순히 성공/실패 결과만 알려줄 건가요?
의도의 모호성: 플레이어가 블록을 놓을 때, 자신의 의도(도움/방해)를 명시적으로 표현할 수 있게 할 건가요?
아니면 순전히 블록 배치만으로 의도를 추측하게 만들 건가요?
선택의 무게: 한 블록으로 할 수 있는 영향력의 범위를 어느 정도로 설정하고 싶나요? 게임을 완전히 바꿔버릴 수 있을 만큼 강력하게? 아니면 미묘한 영향 정도로?

[나]
웹페이지에 연동하는 건 어때? 특정 페이지에 댓글을 쭉 달 수 있게 만들어서, 마지막 플레이어의 게임 흐름을 볼 수 있게 만드는 거지. 이 때 특정 페이지는 깬 사람들에게만 제공하고.

조금 어렵겠지만 서버랑 연동시켜서 유니티에 데이터로 제공한 다음, 유니티 클라이언트에서 해당 리플레이를 재생할 수 있게 만들면 좋을 것 같긴 해.

의도를 명시적으로 표현할 '수도 있게' 할래. 감정 말풍선같은 걸 넣어둬서 해당 블록을 터치했을 때나 가까이 갔을 때 말풍선을 띄워주는 거지.

영향력은 어쩔 수 없이 내가 정할 수 없을 것 같아.

[클로드]
정말 멋진 아이디어들이네요! 웹 연동으로 커뮤니티 형성하고, 감정 말풍선으로 의도를 선택적으로 드러낼 수 있게 하는 것도 훌륭하고요.

몰입과 학습 경험에 대한 질문:

첫 플레이어 문제: 맨 처음 게임을 시작하는 플레이어는 이전 플레이어가 없잖아요. 이들에게는 어떤 특별한 경험을 제공할 건가요?
튜토리얼 성격의 미리 배치된 블록들이 있을까요?
아니면 "첫 번째 플레이어"라는 특별한 역할 의식을 부여할까요?
학습 곡선: 플레이어가 "좋은 복수"와 "나쁜 복수"를 구분하는 기준을 어떻게 학습하게 만들 건가요?
웹페이지의 댓글에서 다른 플레이어들의 반응을 보고 학습하게 할까요?
아니면 게임 내에서 직접적인 피드백(예: 다음 플레이어의 성공/실패율)을 제공할까요?
발견의 즐거움: 감정 말풍선 외에, 플레이어들이 이전 플레이어의 숨겨진 의도나 전략을 발견할 수 있는 다른 방법이 있을까요?

[나]
첫 플레이어는 개발자가 이런저런 경험을 끼워넣을 거야 ㅇㅇ 그래서 첫 플레이라는 위화감이 없도록.

좋은 복수와 나쁜 복수... 그냥 복수라는 개념에서 벗어나자.
댓글을 보고 학습할 수도 있고, 직접적인 피드백을 제공해도 돼. (성공률)

그럼 힌트 기능을 제공하자. 해당 블럭을 누르면 이전 플레이어가 적었던 댓글의 내용이 같이 나오는 거야. 단, 힌트니까 게임 중 3번만 사용할 수 있도록.

[클로드]
오, 힌트 시스템 정말 좋네요! 댓글과 게임이 연결되면서 이전 플레이어의 "진짜 속마음"을 엿볼 수 있는 거군요.

사회적 경험과 상호작용에 대한 질문:

댓글의 성격: 웹페이지 댓글은 어떤 톤으로 작성되길 원하나요?
진지한 전략 분석? ("이 블록으로 점프 높이를 조절하려고 했어요")
감정적 표현? ("다음 사람 힘들게 하고 싶었음 ㅋㅋ")
아니면 자유롭게 두고 자연스럽게 문화가 형성되길?
익명성 vs 정체성: 플레이어들을 어떻게 구분할 건가요?
완전 익명으로 "Player #1234" 같은 식?
아니면 닉네임이나 간단한 아바타로 약간의 개성 부여?
연속으로 플레이하는 사람을 추적할 수 있게 할까요?
커뮤니티 형성: 게임을 깬 사람들만의 특별한 공간에서는 어떤 경험을 하게 만들고 싶나요?
성공한 "복수/도움"의 명예의 전당?
실패 사례들에 대한 분석과 토론?
새로운 전략이나 창의적 블록 배치 공유?

[나]
댓글은 자유롭게. 다만 필터링 기능이 걸리도록... 개발자가 정기적으로 체크해서 지울 수 있게 관리해야겠다.
플레이어들은 완전한 익명.
가장 많이 터치한 블록이나... 가장 많이 좋아요, 싫어요를 누른 블록이 좋지 않을까?

[클로드]
좋네요! 완전 익명이면서 자유로운 댓글 문화, 그리고 데이터 기반 인기 블록 시스템이 재미있을 것 같아요.

동기 구조와 지속성에 대한 질문:

게임의 끝: "모든 플레이어가 모여서 게임을 깬다"는 목표에서, 언제 게임이 "완성"되었다고 판단할 건가요?
특정 수의 플레이어가 연속으로 성공했을 때?
아니면 특정 기간 동안 실패가 없을 때?
혹은 개발자가 수동으로 "완성" 선언?
실패의 의미: 누군가 게임을 깰 수 없게 만드는 블록을 놓았을 때는 어떻게 처리할 건가요?
그 블록부터 새로 시작?
아니면 실패도 하나의 "작품"으로 기록하고 보존?
플레이 빈도: 한 사람이 여러 번 플레이할 수 있게 할 건가요?
만약 가능하다면, 자신이 이전에 놓은 블록을 만났을 때는 어떤 경험을 주고 싶나요?
연속 플레이를 막을 이유가 있을까요?

[나]
게임을 깰 수 없는 블록을 만들었을 때에는, 싫어요가 일정 이상일 때 해당 블록을 제거할 수 있게 할 듯.
그리고 힌트 포인트를 소모해서 해당 블록을 제거하게 만들 수도 있을 것 같아.

[클로드]
오, 싫어요 시스템과 힌트 포인트 소모로 블록 제거! 이게 정말 핵심이 될 것 같네요. 플레이어들이 스스로 게임을 정화하는 자정 시스템이면서 동시에 자원 관리 요소까지.

자원 관리와 선택의 무게에 대한 질문:

힌트 포인트의 가치: 힌트 포인트를 3개만 주는데, 이걸 "댓글 보기"와 "나쁜 블록 제거"에 모두 쓸 수 있다면...
플레이어가 힌트를 보는 것과 블록을 제거하는 것 중에서 고민하게 만들고 싶은 건가요?
아니면 힌트 포인트를 더 많이 줘서 부담 없이 사용하게 할 건가요?
집단 의사결정: 싫어요가 "일정 이상"이면 블록이 제거된다고 했는데...
이 기준을 플레이어들이 알 수 있게 할 건가요? (예: "5개 더 필요해요")
아니면 숨겨둬서 불확실성을 유지할 건가요?
제거된 블록의 흔적: 블록이 제거되면 그 자리는 어떻게 될까요?
완전히 사라져서 원래 맵 상태로?
아니면 "제거된 블록이 여기 있었다"는 표시를 남길까요?

[나]
힌트는 그냥 봐도 되지 않을까? 그렇게 하는게 나을듯...

[클로드]
맞아요! 힌트를 자유롭게 볼 수 있게 하는 게 더 나을 것 같네요. 그러면 플레이어들이 이전 플레이어의 의도를 더 잘 이해하고 소통할 수 있을 거고요.

그럼 힌트 포인트는 오직 "나쁜 블록 제거"에만 사용하는 건가요?

사회적 상호작용의 깊이에 대한 질문:

의도 전달의 정확도: 블록을 놓는 플레이어가 댓글에 자신의 의도를 솔직하게 적을 거라고 생각하나요?
"다음 사람 도와주려고 했어요" vs "사실 약간 괴롭히려고 했어요 ㅋㅋ"
아니면 애매하게 적어서 다음 플레이어가 추측하게 만드는 재미를 노릴까요?
복수의 연쇄: 만약 누군가 명백히 방해하려는 블록을 놓았다면, 그 다음 플레이어들이 "그 사람에게 복수하자"는 식으로 연대할 가능성이 있는데... 이런 상황을 어떻게 보시나요?
재미있는 드라마로 보시나요?
아니면 게임이 너무 적대적이 될까 봐 걱정되시나요?

[나]
제거된 블록이 여기 있었다는 시스템도 괜찮을 것 같아. 사악한 흔적을 알 수 있으니까...

의도는 뭐 사실 대충 쓰거나 해도 되겠지. 그건 그냥 플레이어의 자유로 남기자.
다음 플레이어들이 복수한다는 식으로 연대하는 건... 불가능할 듯. 해당 플레이어가 다시 게임을 플레이할 일이 있을지 모르겠어.

[클로드]
아, 그러네요! 완전 익명이고 연속성이 보장되지 않으니까 개인에 대한 복수보다는 "이런 패턴의 블록은 나쁘다"는 집단 학습이 일어날 가능성이 더 높겠네요.

제거된 블록 흔적은 정말 좋은 아이디어! "여기서 누군가 실패했구나"라는 경고 신호가 되면서 동시에 역사의 흔적이 되겠어요.

지속성과 진화에 대한 질문:

게임의 수명: 하나의 맵이 언제까지 계속 이어질까요?
무한정 계속해서 거대한 협업 작품이 될 때까지?
아니면 일정 기간/플레이어 수 후에 "완성"으로 마무리하고 새 맵 시작?
난이도 진화: 블록이 계속 추가되면서 맵이 점점 복잡해질 텐데...
초보자도 중간에 참여할 수 있도록 난이도 조절 장치가 필요할까요?
아니면 "지금 이 맵은 고수용"이라는 걸 받아들이고 새 맵을 만들 건가요?
성공의 정의: "게임을 깬다"는 게 구체적으로 무엇인가요?
단순히 골인 지점 도달?
아니면 특정 조건들(시간, 점프 횟수 등)을 만족하며 도달?

[나]
게임은 스테이지 방식으로 만들어질 것 같고...
아니면 다른 좋은 아이디어 있어? 플랫포머는 너무 블록에 종속되는 게 문제일 수도.

[클로드]
좋은 지적이에요! 플랫포머는 확실히 블록 배치에 너무 의존적이죠.

다른 장르 제안:

퍼즐/경로 게임:
플레이어가 A에서 B로 가는 최적 경로를 찾는 게임
이전 플레이어가 "벽" 하나를 추가해서 경로를 차단하거나 새 길을 열어줌
블록 하나의 영향력이 명확하면서도 창의적 해결책 필요
타워 디펜스 변형:
적이 지나가는 경로에 이전 플레이어가 "장애물/도움" 하나를 배치
다음 플레이어는 그걸 활용해서 적을 막아야 함
물리 기반 게임:
공을 목표지점에 굴려 넣는 게임
이전 플레이어가 경사로, 장애물, 튕기는 판 등을 하나 추가
물리 법칙으로 예측 가능하지만 실제로는 복잡한 상호작용
아니면 완전히 다른 접근:

스토리텔링: 이전 플레이어가 문장 하나를 추가해서 다음 플레이어가 이어가는 릴레이 소설?
어떤 방향이 흥미로우세요? 아니면 다른 아이디어가 있으신가요?

[나]
음... 차라리 빈 맵에서 도움 요청 버튼을 눌렀을 때 이전 플레이어들의 랜덤한 블럭이 하나씩 나타나는 걸로 하는게 어때?

[클로드]
와, 이거 정말 독창적인 아이디어네요! 완전히 다른 느낌이 될 것 같아요.

이 시스템의 매력적인 점들:

플레이어가 능동적으로 "도움을 요청"하는 행위
랜덤성으로 예측 불가능한 상황 연출
이전 플레이어의 블록이 정말 "선물"처럼 나타나는 느낌
새로운 경험 설계 질문:

도움 요청의 타이밍: 언제 도움을 요청할 수 있게 할 건가요?
막혔을 때만? 아니면 언제든지?
도움 요청 횟수에 제한이 있을까요?
블록의 정체성: 나타난 블록에 누가 만든 건지 표시할 건가요?
"Player #1234가 남긴 블록" vs 완전 익명
해당 블록의 댓글도 같이 볼 수 있게 할까요?
블록의 운명: 요청해서 나온 블록을 사용하지 않고 다시 숨길 수 있을까요?
아니면 한 번 나오면 맵에 영구적으로 남는 건가요?
"이 블록 별로네..." 하고 다른 블록을 요청할 수 있을까요?

[나]
ㄴㄴ 요청해서 나온 블록은 무조건 계속 써야 함

[클로드]
아하! 그럼 도움 요청의 무게가 훨씬 무거워지겠네요. "정말 지금 도움이 필요한가?" 신중하게 생각하게 만드는 시스템이군요.

위험성과 신뢰에 대한 질문:

러시안 룰렛 요소: 도움을 요청했는데 악의적인 블록이 나올 수도 있잖아요?
이런 "도박성"을 의도한 건가요?
플레이어가 "에이 설마 나쁜 블록이겠어" 하며 요청하게 만들고 싶은 건가요?
블록의 맥락: 이전 플레이어가 놓은 블록이 원래 맵과는 다른 위치에 나타날 텐데...
해당 블록이 원래 어떤 상황에서 만들어졌는지 알 수 있게 할까요?
아니면 맥락 없이 "순수하게" 이 블록 자체만 판단하게 할까요?
학습 효과: 플레이어들이 "어떤 종류의 블록을 요청하지 말아야 하는지" 학습하게 될 텐데, 이런 커뮤니티 지식 축적을 어떻게 보시나요?
웹페이지에서 "이런 블록 조심해" 같은 팁이 공유될까요?

[나]
러시안 룰렛 요소 물론 들어가.
블록의 맥락은 현재 위치한 곳에 가장 가까운 블럭만 나타나게 하는 방식으로 해결할 듯.
웹페이지가 어떻게 공유하든 상관은 없어.

[클로드]
완벽하네요! 러시안 룰렛 + 위치 기반 블록 선택으로 맥락 문제까지 해결하고, 커뮤니티는 자연스럽게 발전하도록.

긴장감과 릴리즈에 대한 질문:

도움 요청의 시각적 피드백: 도움 버튼을 눌렀을 때 블록이 나타나는 연출을 어떻게 할 건가요?
즉시 "뿅!" 하고 나타나게?
아니면 천천히 구체화되면서 긴장감을 조성?
블록이 나타나기 전에 "누군가가 당신에게 선물을 남겼습니다" 같은 메시지?
실패의 받아들임: 나쁜 블록이 나와서 게임이 더 어려워졌을 때...
플레이어가 "아 이런" 하고 받아들이게 만들고 싶나요?
아니면 "이것도 극복해보자" 하는 도전 의지를 불러일으키고 싶나요?
성공 시 보상감: 어려운 상황에서 블록을 잘 활용해서 성공했을 때의 만족감을 어떻게 극대화할 건가요?
그 순간을 특별하게 연출할 계획이 있나요?

[나]
좋아요/싫어요를 누르는 방식으로 해결되겠지.
도움 요청의 시각적 피드백은 당연히 극적으로.

[클로드]
좋네요! 좋아요/싫어요로 블록의 가치를 평가하고, 극적인 연출로 긴장감을 만들어내는 거군요.

경험의 완성도에 대한 질문:

게임 클리어의 순간: 플레이어가 마침내 골에 도달했을 때...
자신이 사용한 모든 블록들의 제작자 댓글을 한 번에 볼 수 있게 할까요? ("이 여정을 함께한 사람들")
아니면 단순히 성공 화면으로 끝낼까요?
실험의 목적: 이 게임이 OOI 실험게임이라고 하셨는데, 궁극적으로 무엇을 실험하고 싶은 건가요?
익명의 협력/경쟁 관계?
시간차 비동기 소통?
집단 지성의 자정 능력?
데이터 수집: 실험게임으로서 어떤 데이터나 결과를 관찰하고 싶나요?
플레이어들의 선택 패턴?
커뮤니티 문화 형성 과정?
도움 요청 빈도와 성공률의 관계?
이 질문들이 게임의 핵심 의도를 더 명확히 하는 데 도움이 될까요?

[나]
ㅇㅇㅇ 게임 클리어의 순간 도움 요청했던 사람들의 댓글이 한번에 표시되게 만들자.

어렵네. 도움 요청을 난사하거나 아예 난사하지 않거나 둘중의 하나의 게임이 될 것 같아서...
도움 요청을 제한해버릴까?

[클로드]
맞아요! 제한 없으면 극단적으로 갈 가능성이 높죠.

도움 요청 제한 방식들:

횟수 제한:
스테이지당 3-5회만?
전체 게임에서 총 몇 회만?
조건부 제한:
일정 시간 동안 시도해본 후에만 가능
특정 횟수 실패 후에만 가능
현재 위치에서 일정 거리 이상 진행 불가능할 때만
자원 소모:
도움 요청할 때마다 점수 차감
성공 시 보상으로 도움 요청 기회 회복
쿨다운:
한 번 요청하면 일정 시간 후에야 다시 가능
개인적으로는 "조건부 제한"이 가장 흥미로울 것 같아요. 진짜 막혔을 때만 요청하게 만들면, 각 요청이 더 의미 있어지고 받은 블록에 대한 감정적 투자도 커질 거고요.

어떤 방식이 게임의 재미를 해치지 않으면서도 남용을 막을 수 있을까요?

[나]
죽을 때마다 늘려줄까?

[클로드]
오! 그거 정말 좋은 아이디어네요!

이 시스템의 장점들:

실패가 단순한 패널티가 아니라 "자원"이 됨
어려운 구간일수록 더 많은 도움을 받을 수 있게 됨
플레이어가 "죽는 것"에 대해 완전히 부정적이지 않게 됨
구체적 설계 질문:

초기 횟수: 게임 시작할 때 도움 요청을 몇 번 가지고 시작할까요?
0번? (첫 죽음 후부터 가능)
1번? (최소한의 안전망)
증가량: 죽을 때마다 몇 개씩 늘려줄까요?
1개씩? 선형 증가
죽은 횟수에 따라 점점 더 많이? (1개→2개→3개...)
캐리오버: 스테이지를 클리어하면 남은 도움 요청 횟수를 다음 스테이지로 가져갈 수 있을까요?
아니면 스테이지마다 리셋?
이렇게 하면 "좌절 → 도움 → 감사 → 성공"의 감정 곡선이 자연스럽게 만들어질 것 같아요!

[나]
으음... 플랫포머가 가장 적절한지를 모르겠거든? 무슨 장르가 적절한지 고민이 더 필요해.
플랫포머가 괜찮다고 생각한 이유는 모든 유저들이 플레이할 수 있기 때문이거든.
근데 이런 방식으로 가면 그냥 일회용 게임으로 끝날 것 같아. 실험게임이니까 그게 나을지도...

[클로드]
맞아요, 이 딜레마가 핵심이네요!

장르 선택의 트레이드오프:

접근성 vs 깊이
재플레이성 vs 실험적 가치
다른 접근 방식들:

하이브리드:
메인은 간단한 플랫포머
서브로 퍼즐 요소나 창의적 요소 추가
예: 블록으로 그림 그리기, 메시지 전달하기
메타 게임:
게임 자체보다는 "이 과정"이 게임
플레이어들이 어떻게 상호작용하는지 관찰하는 게 목적
진화형 게임:
처음엔 단순하게 시작
플레이어들의 패턴에 따라 룰이나 요소가 추가됨
핵심 질문: 이 게임으로 무엇을 증명하거나 보여주고 싶은가요?

"사람들은 기본적으로 선한가?"
"익명 환경에서도 협력이 가능한가?"
"게임이 플레이어를 어떻게 변화시키는가?"
실험의 목적이 명확해지면 장르도 자연스럽게 결정될 것 같아요.

[나]
실험 게임 페스티벌이니까... 사실 플레이어 당 10분을 넘기면 안될 것 같긴 하다. 그냥 받아들인다의 방법이 있어.

[클로드]
아, 맞네요! 페스티벌 환경이면 10분이라는 제약이 완전히 게임을 바꾸죠.

10분 제약 하에서의 새로운 관점:

플랫포머가 오히려 최적일 수도 있겠네요!

규칙 설명 30초
플레이 5-7분
다음 플레이어를 위한 블록 배치 2-3분
이 제약이 만드는 긍정적 효과들:

과도한 고민 없이 직관적 선택
"완벽한" 블록보다는 "즉흥적" 블록
실패해도 "뭐 어때" 하는 가벼운 마음
새로운 질문: 10분 안에 경험해야 할 핵심 감정 하나를 정한다면 무엇일까요?

"누군가와 연결되었다"는 느낌?
"내가 누군가에게 영향을 미쳤다"는 느낌?
"예상치 못한 상황을 해결했다"는 성취감?
"다음 사람이 어떻게 할지 궁금하다"는 호기심?
어떤 감정을 가장 강하게 남기고 싶으세요?

[나]
누군가에게 영향을 미쳤다 -> 미니 게임 기획자같은 느낌 체험
누군가가 나에게 이런 도움을 주려고 했구나
집단 지성이 모이면 이렇게 되는구나 (?)

[클로드]
완벽한 3단계 감정 여정이네요! 특히 "미니 게임 기획자" 체험이라는 표현이 정말 핵심을 찌르는 것 같아요.

경험의 순서와 강도에 대한 질문:

기획자 체험의 구체화: 블록을 배치할 때 "미니 게임 기획자" 느낌을 강화하려면...
배치 후에 "당신의 블록이 다음 플레이어에게 미칠 영향 예상도"를 보여줄까요?
아니면 "이 블록으로 어떤 경험을 주고 싶나요?" 같은 의도 선택지를 제공할까요?
감정의 밸런스: 세 가지 감정 중에서 어느 것을 가장 강하게 느끼게 하고 싶나요?
개인적 영향력 (1번)?
타인의 배려 (2번)?
집단의 힘 (3번)?
집단 지성의 시각화: "집단 지성이 모이면 이렇게 된다"를 어떻게 보여줄 건가요?

[나]
웹페이지에서 전체 맵의 진화 과정을 타임랩스로?
아니면 게임 내에서 "이 블록들은 각각 다른 사람이 만들었어요" 표시?
이거 스팀 게임으로 낸다면 무료로 내되, 매일 맵이 바뀌게 만들어야겠는걸...

[클로드]
오! 스팀 무료 게임으로 가면 완전히 다른 스케일이 되겠네요!

데일리 맵 시스템의 장점들:

매일 새로운 "집단 작품" 탄생
어제 맵은 역사가 되고, 오늘 맵은 진행형
FOMO 효과로 플레이어 유입 증가
새로운 설계 고려사항들:

시간대 문제: 전 세계 플레이어들이 참여할 텐데...
한국 시간 기준으로 자정에 리셋?
아니면 지역별로 다른 맵?
첫날의 문제: 매일 리셋되면 첫 플레이어들이 빈 맵에서 시작하는데...
개발자가 매일 시드 블록들을 배치해둘까요?
아니면 전날 성공한 플레이어들이 다음 날 시작 블록을 배치하게?
보존과 기록: 어제의 "명작" 맵들을 어떻게 보존할까요?
웹페이지에 "역대 명예의 전당" 코너?
특별히 재미있었던 맵은 "클래식 모드"로 재플레이 가능?
커뮤니티 규모: 하루에 몇 명 정도가 참여하길 기대하세요?

[나]
마리오 메이커처럼 특수 블록을 사용할 수 있도록 만들 거고,

난이도를 나눠 놓은 맵의 풀들에서 랜덤으로 뽑아서 스테이지를 만든다,
쉬움/보통/어려움 난이도의 맵을 각각 개많이 만들어서 그중에서 n개 뽑아서 클리어하면 클리어,
죽거나 이기면 랜덤한 세개의 블럭 중에서 하나를 선택해서 놓을 수 있다
마리오에서 나오는 것처럼 슈퍼 점프 블록이라던가, 방해 불꽃을 쏘는 포대???라던가 그리고 일정 시간 이상 밟으면 잠시 사라지는 블록이라던가, 아무튼 그런 특수 블록들도 포함해서 만들어야 해.

이렇게 기획을 머릿속에서 정리한 뒤에, 트렐로를 만들어서 작업 상황을 서로 관리했다. 방금 캡쳐한 거라 작업이 대부분 완료 탭에 들어가 있다. 그거 말고는 뭐... 늘 하듯이 데이터 시트 만들고, 번역 시트 만들고 기본적인 프로젝트 세팅을 했다.

개발 뉴비였던 6년 전과는 다르게 과정은 빠르게 진행되었다. 원하던 기획을 두 달 정도 걸려서 완성했으니까. 제출 당시의 빌드는 퀄리티가 훌륭하지는 않아서 선정이 안 되더라도 좋은 경험이었다고 치고 출시하고 끝내려 했는데, 다행히 뽑혔다는 메일이 왔다. 아마 실험 게임 페스티벌이라는 의도에 잘 맞는 기획이라서 그랬던 것 같다. 이후에는 전시를 위한 폴리싱을 이어 나갔다. 챠로는 플랫포머의 조작감과 물리 시스템을 다듬어 나갔고, 나는 전시용 소셜 시스템을 더 디벨롭했다.

맡아서 한 일들

사실 두 명 모두 아트는 아니고 프로그래머였기에, 캐릭터나 블록의 대부분은 에셋을 사용했다. 부족한 부분들은 그렸고 만들어서 채워 나갔다. 나는 이펙트 수련의 일환으로 파티클이나 소소한 블록 애니메이션들을 만들었다. 다음 프로젝트부터 얼추 노하우가 쌓여서 요긴하게 쓸 것 같다.

이번 프로젝트에서의 주 업무는 소셜 기능을 위해 웹서버를 구현한 것이다. 백엔드를 입문한지는 1년도 채 되지 않았기에, 실제로 처음부터 끝까지 구현하고 배포해 본 것은 많은 도움이 됐다. 개발 스펙으로는 .NET C#, SQLite, Swagger를 사용했고, 배포는 Render에 했다. 세상이 참 좋은 게, 목적에 맞는 프레임워크나 데이터베이스는 AI가 참 잘 추천해준다. 본래 Node.js 서버만 사용했었는데, 주 언어인 C#으로 개발하니까 아주 편했다.

기획 초기에는 서버를 외부에 둘 생각이 없었고 전시장에서 랜 통신만 하려고 했었기에 로컬 파일에 쓰기만 하려고 SQLite를 사용했는데, 지금 글을 쓰면서 생각해보니 출시 직전에는 바꿔야 할 것 같다 ^w^... 그리고 개발하다보니 결국 테스트가 필요해져서, 랜 통신으로만 서버를 올릴 생각을 버리고 Render에 서버를 배포하게 되었다. 처음 써봤지만 좋은 것 같다. 귀찮게 deploy 명령어를 쓸 필요 없이 커밋만 하면 알아서 배포가 된다니. 토이 프로젝트에 최적화된 구성인 것 같다. 비용도 뭐... 전시했던 한 달 동안 7달러 언저리로 끊었으니 싸다! 그리고 Swagger를 클라이언트 개발자 입장에서만 쓰다가 백엔드 개발자 입장에서 쓰니까 마치 신이 된 것 같다.

웹페이지 디자인은 그냥 클로드한테 시켰다. 프론트엔드는 html 말고는 입문조차 안 했다. 출시 때에는 어차피 웹페이지가 아니라 유니티 UI로 소셜 기능을 표시할 것이라 상관 없다. 전시용 임시 방편이었다. 지금은 효율성을 따지지 않고 API 통신 로직을 만들었는데, 출시 직전에 최적화를 한 번 해야 할 것 같다.

유니티 클라이언트에서는 소셜 관련 UI, 네트워크 통신 로직, 블록 동적 생성 에디터 등을 만들었다. 사실상 플랫포머 시스템은 챠로에게 완전히 맡겨버린 셈인데, 기획만 들고 나왔더니 자동사냥을 해주니까 매일매일이 새로웠다. 협업 최고.

전시 날은 어땠나

이전 프로젝트인 How We Die도 있고, 현재 회사에서도 일로써 전시 짬이 많이 쌓인 관계로 특별히 힘들지는 않았다.

3일 내내 서 있어도 안 죽었고, 심지어는 새벽까지 빌드를 고쳤는데도 멀쩡했다! 아무래도 도파민 때문이었거나 운동의 효과인 듯 하다. 물론 월요일에 사망함.

첫 날에는 버그와 다양한 UX 문제를 전시장에서 보면서 무한한 동공지진을 겪었다. 직전까지 고민했던, '죽으면 블록 무한정 생성'이 결국 기획 의도와 다른 결과를 불러일으켰다. 도움 버튼 누르면서 사람들이랑 상호작용하는 게임이 아니라, 죽으면서 길을 개척하는 건축 게임이 됨. 긍적적으로 보자면 이 날 만들어졌던 블록들이 2일차부터 사람들에게 재미를 주었다고도 할 수 있겠다. 부정적으로 보자면 아무래도 내가 고통받았다는 것 정도. 그래서 집에 들어가서는 챠로와 함께 미친듯이 수정했다.

다행히 개선한 뒤 둘째 날부터는 기획 의도에 맞게 작동했다. 좋아요/싫어요 소셜 액션이 적어서 UX를 추가로 수정한 것 말고는 괜찮았다. 이건 실험 데이터 글과 댓글로도 썼지만 오히려 정상적인 비율이었다. 메인은 블록을 놓고 헬프를 누르는 것이었으니까. 정신 승리로서 말하자면 좋아요와 싫어요에 의존하지 않고도 선한 블록과 사악한 블록을 분류할 수 있었기 때문에 데이터에는 문제가 없었다. 잘됐군, 잘됐어.

셋째 날이 되니, 이제는 두려움에 떨면서 지켜봐야 하는 일이 사라졌다. 그냥 뒤에서 플레이를 지켜보면서 웃고 떠들기만 하면 됐다. 그 동안 데이터는 착실하게 쌓여서 실험 분석의 밑거름이 되었다. 즐거운 성공. 앞으로도 또 이런 기회가 있었으면 좋겠다.

그리고 OOI 기획단에도 정말 너무너무 감사했다. 첫 날 전광판 기능을 위해 서브 모니터를 들고 왔었는데, 더 큰 모니터로 전시 제안을 해주셔서 사람들이 더 즐거워하며 실험에 참여할 수 있었다. 뭔가 얻어먹기만 했다는 감정이 드는데 다음 전시가 열리면 다양한 방법으로 돌려드려야겠다고 생각했다. Out of Index 화이팅.

그래서 출시해요?

Please One More Block은 위의 기획에서만 봐도 알겠지만 철저히 전시용으로 기획된 게임이었다. 출시하더라도 서버비만 나올 것 같은 게임이라고 생각했다. 그런데 사람들이 방송용 게임으로 재미있겠다고 계속 말씀들을 하셔서 그에 맞게 출시할 것 같긴 하다. 이전 기획과는 다르게 날마다 맵이 바뀌고, 모드가 다양하고, 블록이 다양하고, 랭킹이 다르겠지. 싱글 게임으로 재기획하게 되겠다.

How We Die때 함께했던 퍼블리셔에 또 신세를 지게 되었다. 무난하게 넥스트 페스트 등을 거쳐서 3~6월 중으로 출시할 예정이다. 기대된다면 위시리스트를 부탁한다 ^w^; 상점 페이지는 이미 나와 있는 상태다.

별개로 기회가 온다면, 전시용 빌드로 또다시 사람들에게 즐거움을 줄 예정이다.

회고 끝.

Please One More Block 데이터 분석 보고서 (OOI 2025)

Doublsb — Sun, 14 Dec 2025 06:07:25 +0900

이 글은 실험게임 페스티벌인 Out of Index 2025에서 전시한 'Please One More Block'의 데이터 분석 보고서이다.
거창하게 제목을 짓긴 했지만, 그렇게 무거운 건 아니다. 그냥 전시 기간 동안에 사람들이 어떤 경향을 가지고 행동했는지 알아보는 것에 가깝다.

개발 후기는 다른 글에서 다루도록 한다 :P

이 게임에서 하고 싶었던 것들

https://youtu.be/EKaxyUVq9Gk?si=seb057i_8qzrDEWS

Please One More Block은 '타인과 영향을 주고받는 게임'으로 기획되었다.
플레이어는 타인에게 자신의 행동이 영향을 줄 것을 예측할 수 있고, 그에 따라 평가를 받을 것을 예상할 수 있다.
또한 플레이어는 스스로 요청해서 다른 사람의 영향을 받을 것을 선택할 수 있다.
이것을 직관적인 게임으로 표현하기 위해 플랫포머 장르를, 그리고 블록 놓기를 선택했다.

단순 데이터의 나열

이번 전시 기간동안 얻은 순수 데이터를 정리하면 다음과 같다.

총 통계

블록 별 좋아요 / 싫어요 개수 순위

블록 별 제작 개수 / 호출 수 순위

블록 별 반응 수 / 반응 비율 순위

좋아요 1위 ~ 10위까지의 블록들

싫어요 1위 ~ 10위까지의 블록들

개인적으로 재밌었던 블록들

자세한 분석

위의 데이터들을 정리하면, 2025 Out of Index 참여자에게서 아래의 경향성을 얻어낼 수 있다.

블록들의 개수 대비 좋아요 비율은 17.5%이다.
블록들의 개수 대비 싫어요 비율은 10%이다.
사람들은 평균 6.5개의 블록을 만들었다.
사람들은 평균 14.6번의 도움 요청을 했다.
게임 중 마주칠 수 있는 사악한 블록의 비율은 15%이다.
사람들은 좋아요/싫어요를 평균 1.7번 정도 눌렀다.
35%정도의 사람들만이 유의미한 코멘트를 작성한다. (빈 코멘트/미리 정해진 코멘트/3글자 이내가 아닌 것들)
유의미한 코멘트의 개수 대비 좋아요 비율은 19%, 싫어요 비율은 12%로, 일반 블록들보다 2%정도 높다.
사람들은 좋아요를 대부분 자신을 직접적으로 도와주는 치트급 블록에 준다.
사람들은 싫어요를 대부분 자신을 직접적으로 공격하는 블록에 준다.
사악한 블록들에게도 좋아요가 10개나 된다.
무적 블록의 싫어요가 10개나 된다.
점프 블록은 좋아요/싫어요가 고루 분포하는 양면적인 블록이다.
사람들은 주로 치트급 블록을 만들었다.
사람들은 주로 치트급 블록을 마주했지만, 전시장에서 사람들은 사악한 블록들을 더 많이 기억했다.
사람들은 칼날 블록에 20%만큼 좋아요/싫어요로 반응했다. (1위)
사람들은 무적 블록에 11%만큼 좋아요/싫어요로 반응했다. (10위)
리스폰 지점에 대부분의 블록들이 만들어졌다.
컨트롤이 어려운 지점에 좋은 블록들이 주로 만들어졌다.
도착 지점에 사악한 블록들이 주로 만들어졌다.

주관적 분석

평가 액션은 적다

Out of Index 2025는 비버락스와 함께한 특별관에서 열렸다.
적극적으로 실험에 참여하려는 유저와 그저 재밌는 게임을 즐기려는 유저로 반반이었다고 생각된다.
이런 특수 상황에도 불구하고 적극적인 액션을 하는 유저가 많지 않다는 것에 놀랐다.

2일차 오전까지 나는 UX로 인해 양질의 좋아요/싫어요 데이터를 모으지 못했다고 생각했다. 그러나 문제가 해결되고 나서도 사람들은 평가 액션에 소극적이었다. 3일차에 강제로 좋아요/싫어요를 유도했을 때에도 스킵 기능을 찾는 유저들이 많았다.

유저 당 만든 평균 블록 6.5개
유저 당 도움 요청 평균 14.6번
유저 중 유의미한 코멘트를 작성한 비율 35%
유저 당 평균 평가 액션 1.7개
유의미한 코멘트는 평가 유인이 2% 정도 더 높음

이 수치는 다소 충격으로 다가왔다. 유의미한 코멘트 비율까지는 기획한 대로 흘러갔는데, 정작 인당 평균 평가 액션은 1.7개였다.
사람들은 자기 표현에 비해서, 타인에 대한 직접적 평가는 소극적으로 하고 있었다.

유의미하고 재미있는 코멘트는 블록 평가의 큰 요인이 될 것이라는 예상도 그닥 들어맞지 않았다.
해당 블록들에 대한 평가 액션은 2% 정도 밖에 증가하지 않았기 때문이었다.

협력과 배신의 구간

컨트롤이 어려운 구간에서는 사악한 블록은 거의 없고 도움 블록만 가득하다는 것,
그리고 시작 부근과 성공 직전에 대부분의 사악한 블록들이 몰려 있다는 것도 흥미로웠다.

어쩐지 실제 사회에서 이런 양상을 자주 본 것 같기도 하다.
진짜 주관적인 생각으로 이 데이터를 평가하자면, 시작할 때 어려움에 절망하지 말고 마무리 직전에 정신을 바짝 차려야겠다는 생각이 든다 (?)

좋은 것보다 나쁜 것에 더 반응하는 사람들

인간이 부정성 편향을 가지고 있다는 것은 유명한 사실이다. 생존을 위한 본능적인 사고라나 뭐라나.
이 게임에서도 그것이 증명되었다. 데이터로 봤을 때, 사람들은 사악한 블록에 5 ~ 10% 정도 더 평가 액션을 했다.
전시장에서는 "남에게 복수할 수 있어서 좋네요" "사람들이 참 사악하네요" 등의 반응을 주로 들었다.
정작 데이터로는 사악한 블록은 15%의 확률로 마주칠 수 있었는데 말이다. 게다가 도움 요청을 누르면 대부분 무적 블록이 나오고.

대포 블록의 알 수 없는 매력

전시 내내 골머리를 앓았던 것이 대포 블록이다.
첫날에는 왼쪽/오른쪽 키가 아닌 위/아래 키 조작에만 반응해서 가이드를 해야 했고, 나머지 날에는 대포 발사 후 이동 키를 눌렀을 때 더 날아가지 않고 떨어지게 해 두어서 사람들이 조작하는 데 어려워하는 것을 지켜봤었다.
그러나 이게 웬걸, 사람들은 이 블록을 사실은 좋아했던 것이다. 제작 순위 3위, 반응 수 2위, 반응 비율 중위권의 아주 핫한 블록이었지 뭔가.

심지어는 전시 내내 사람들은 대포 블록 조작에 고통받으면서도, 심지어는 대포 발사가 더 느릴 수 있는 상황에도 불구하고 번번이 대포로 달려가 날아갔다. 어째서?!

왜 사과하면서 사악한 블록을 만드는건데

코멘트들을 하나씩 보면서 재밌었던 건, 나쁜 블록을 배치해놓고 사과하는 경우가 생각보다 많았다는 것이다.
물론 블록을 무작위 세 개중에 고르도록 되어 있기에, 나쁜 블록을 반드시 만들어야 하는 경우도 있을 수 있다.
하지만 그 블록들은 반드시 누군가를 방해할 수 있는 위치에 있었다. 그렇다면 왜 사과하는 것인가. 재밌군.

전시 중에 본 재미있는 플레이

1. 사실 이거 건축 게임이에요
첫날에는 죽을 때마다 블록 생성을 생성할 때 제한이 없었다. 어떤 플레이어는 어려운 맵을 마주쳤을 때 죽으면서 한 칸씩 계단을 만들어 클리어하는 광기를 보였다.

2. 친구끼리 사이좋게 공격해요
A와 B는 친구. A가 먼저 게임을 플레이해서 사악한 블록들을 만들었다. 재미있는 스크린샷에 있는 '깨시좋아너무좋아'가 A의 작품이었다. 끝난 뒤에 B가 곧바로 이어서 플레이하다가 A의 블록에 화려하게 사망했다.

3. 스스로 불러온 재앙을 즐기는 편
죽고 나서 블록을 배치할 때, 그게 자기 맵에도 그대로 배치된다는 걸 모르던 뉴비 플레이어는 자기 블록에 화려하게 사망하고 말았다. 모두가 즐겁게 웃었다.

4. 맵이 망가졌어
도움 버튼을 미친듯이 누르고 다니는 플레이어 유형이 있었다. 맵이 구제불능 상태가 되었고 부활하자마자 사악한 블록에 당해 죽는 무한 루프가 되어 버렸다. 리셋 버튼을 추천해드렸다.

전시장의 특수성

전시라서 그런 것이겠지만, 욕설 등의 '진짜 나쁜 블록'을 만드는 경우는 없었다.
이 게임을 집에서 플레이한다면 재미도가 급감할 것이라고 예상하고 있다. 출시 때에는 익명일테니 비속어 필터를 달아야겠군...
오히려 좋아요/싫어요는 집에서 플레이하면 누르지 않을까 싶다. 등 뒤에서 지켜보고 있으면 평가를 못하게 되는 것일지도.

데이터 분석 후기

전시 2일차에 OOI 주최측과 앉아서 인터뷰를 진행했었을 때 하셨던 말이 기억난다.
이 환경이 '한국'이고, 'Out of Index 2025 관람객'의 특성이기 때문에 소셜 액션이 적지 않았을까, 라는 말이었다.
그걸 다른 전시에서 증명할 수 있는 기회가 있으면 좋을 것 같다.

양질의 데이터를 못 얻었다고 생각했는데, 막상 정리해보니 좋아요/싫어요를 제외하고는 분석할 게 많아서 즐거웠던 것 같다.
플레이어 대부분도 재미있게 느꼈으니 게임성도 잡았고, 분석도 무난하게 했으니 이번 전시는 성공이라고 할 수 있겠다.

다음에도 재미있는 기획으로 두마리 토끼를 다 잡아보도록 하자. :D

스크립트, 기획자들에게 어디까지 열어줘야 좋은가

Doublsb — Mon, 18 Aug 2025 22:56:15 +0900

이번 회사에서는 좋은 기획자들을 만나서 호의호식(?)하고 있다. JSON, 스크립트 뿐만 아니라 AI 사용에도 능해서 그렇다.

기존 개발자가 기획자들이 JSON으로 동작을 짤 수 있도록 토대를 잘 만들어놓은 것도 컸다.

아무튼, 이 상황을 살려서 이번 프로젝트에서는 기획자들이 더 잘 일할 수 있게 만들고 싶었다.

그래서 유사 스크립트 구조를 짜서 기획자들에게 배포했다. 이번 글은 그에 대한 회고이다.

로그라이크 덱빌딩 게임이고, 유물 작동 스크립트를 기획자가 짤 수 있게 만든 것이니 참고 바란다.

결론부터

결과적으로는 옳고, 어려운 기능이나 연출이 많이 들어가야 하는 부분만 개발자가 손대는 것이 바람직한 것 같다.

아래에서 설명하겠지만 스크립트 초보를 위해 Lua를 사용하지 않고 비교적 쉬운 문법을 사용했는데, 결과적으로는 러닝 커브가 있더라도 업계 표준을 쓰는 게 좋은 것 같다.

스크립트 포맷

일단 포맷부터 보자.

아래는 전기 카드를 뽑은 뒤, 1/3 확률로 전기 {0}장을 덱 맨 위에 임시로 놓는 효과다.

[
    {
        "Trigger": "start",
        "Condition": "true",
        "Effect": "setLocalVar(0, -1)"
    },
    {
        "Trigger": "draw",
        "Condition": "getElementCount('electric', true, 1) == 1 && random(1,3) == 1",
        "Effect": "activateArtifact(1);addCard('top', 'electric', 'add', getLocalVar(0), 'none', 1, false); addLocalVar(0, -1)"
    }
]

구조는 JSON이고, Trigger/Condition/Effect를 유사 코드처럼 서술할 수 있게 되어 있다.

해당 프로젝트에 특화되었기에 다들 기획자가 단번에 이해할 수 있다며 긍정적으로 평했다.

왜 JSON인가? 왜 Lua가 아니었나?

루아 스크립트 언어가 버젓이 있는데도 이렇게 만들어놓은 건, 루아 스크립트와 유사 스크립트중에서 기획자들이 고르게 한 결과다.

1. JSON은 괜찮은데 코드 문법에는 익숙하지 않은 기획자가 있어, 문법 에러에 대한 우려가 있었다.

2. 이게 더 관리하기 편하고 잘 읽힌다고 생각했다.

구조는 어떻게 짰나?

Trigger는 해당 이벤트의 발생 타이밍을 정하는 것이고, Condition은 발생 시 조건을 체크한다.

그리고 Effect에서는 Condition이 True일 때 내용을 수행한다.

Trigger는 당연히 인게임 내에서 자체 구현했기에 패스하고,

Condition과 Effect를 수행하기 위해서는 마치 Eval문을 수행하는 것처럼 만들어야 했기에 라이브러리를 찾아보았다.

결과로 가볍고 성능이 괜찮은 NCalc라는 라이브러리를 찾을 수 있었다.

https://github.com/ncalc/ncalc

GitHub - ncalc/ncalc: NCalc is a fast and lightweight expression evaluator library for .NET, designed for flexibility and high p

NCalc is a fast and lightweight expression evaluator library for .NET, designed for flexibility and high performance. It supports a wide range of mathematical and logical operations. - ncalc/ncalc

github.com

NCalc는 어떤 라이브러리인가?

.Net Calculation의 줄임말인 듯 하다. 본래는 string을 계산한 결과값을 object 타입으로 돌려주는 라이브러리다.

작게는 수학 계산을 위해 쓰이고, 나의 경우 간단한 함수를 호출하는 데에도 사용했다.

var expression = new Expression("Round(Pow([Pi], 2) + Pow([Pi2], 2) + [X], 2)");

expression.Parameters["Pi2"] = new Expression("Pi * [Pi]");
expression.Parameters["X"] = 10;

expression.DynamicParameters["Pi"] = _ => {
    Console.WriteLine("I'm evaluating π!");
    return 3.14;
};

Debug.Assert(117.07 == expression.Evaluate());

위와 같은 방식으로 변수를 등록하여 계산하는 것도 가능하고,

var expression = new Expression("SecretOperation(3, 6)");
expression.Functions["SecretOperation"] = (args) => {
    return (int)args[0].Evaluate() + (int)args[1].Evaluate();
};

Debug.Assert(9 == expression.Evaluate());

위와 같은 방식으로 함수를 등록해서 계산하는 것도 가능하다.

기타

다만 실제로는 성능 최적화나 await를 수행해야 하는 케이스가 있어서, 완전히 NCalc를 사용한 건 아니고...

결과를 바로 제공해야 하는 Condition 구문이나, await를 쓰지 않고도 작동하는 getVar(), setVar(), addVar()등의 커스텀 함수들은 NCalc에 붙여서 요긴하게 사용했다.

그 외의 Effect는 작은 모듈들로 만들어 객체로 async Action() 함수를 구현했다. 자세히는 설명하지 않고 넘어가겠다.

프로젝트에서 잘 기능했는가?

지금이야 익숙해져서 만족스럽지만, 좀 아쉬웠던 몇 가지 부분을 적어보겠다.

개발자가 생산하지 않은 버그는 생각보다 고통스럽다

개발 초기에는 이 JSON 스크립트에 대한 검증기가 없었기에, 테스트 빌드에서 버그가 났을 때 개발 코드가 문제인지 데이터 코드가 문제인지 바로 파악하기가 힘들었다. 그리고 그게 꽤 스트레스였다. 어쨌든 버그가 발생하면 보통 개발자를 찾고 기획자를 찾지는 않으니까.

이건 금방 해결했다. 스크립트 문법 검증과 작동 검증을 하는 툴을 만들어서 배포했기 때문.

왜 검증기부터 만들지 않았냐는 의문이 들 수 있는데, 이 프로젝트는 현재까지 개발 기간이 6개월이므로 다른 개발로 바빴다 ^^;;

AI를 효율적으로 사용할 수 없었다

초기에는 어느 정도 스크립트를 만든 후에 LLM에게 학습시켜서, 원하는 기획을 입력하면 스크립트로 출력하게 할 생각에 모두 들떠 있었다. 그러나 결과물은 만든 적도 없던 커스텀 함수를 넣어서 내놓거나, 문법에 맞지 않는 스크립트를 내놓았다. 즉, 할루시네이션이 심했다.

만약 Lua 스크립트였다면 업계 표준이기에 학습 데이터가 많아 그래도 쓸만한 결과물을 내놓았을텐데 말이다.

포맷의 가독성이 생각보다 안 좋고 IDE를 활용하지 못했다

처음에는 읽기 쉬운 스크립트가 될 거라고 생각했다. 하지만 언제나 창의적인 생각을 내놓는 것이 기획자였기 때문에...

[
    {
        "Trigger": "enable",
        "Condition": "true",
        "Effect": "setVar('서류철',0)"
    },
    {
        "Trigger": "draw",
        "Condition": "true",
        "Effect": "addVar('서류철',1)"
    },{
        "Trigger": "draw",
        "Condition": "getVar('서류철')>=50",
        "Effect": "activateArtifact(1);sortCard('top','stone','any','any',-1,'any',-1,false);sortCard('top','electric','any','any',-1,'any',-1,false);sortCard('top','water','any','any',-1,'any',-1,false);sortCard('top','fire','any','any',-1,'any',-1,false);setVar('서류철',0)"
    }
]

위 스크립트는 카드를 총 50회 뽑고 난 뒤 덱을 불-물-전기-돌 순서로 정렬하는 스크립트인데, 가독성이 좋지 않다.

우선 sortCard라는 함수에 모든 조건을 때려넣게 되는 부분이 문제였다. Lua였다면 이름 기반 매개변수처럼 작성할 수도 있었을 텐데. 심지어는 검증기 사용 이전에 IDE가 기본 문법 체크를 해주는 경우도 있었을 테니 이래저래 아쉬웠다.

정리, 그리고 다음 프로젝트에서는?

만약 스크립트 형태가 아니라 개발자가 직접 구현하는 형태였다면 안정성은 보장되었겠지만 시간이 엄청나게 들었을 것이다.

지금 데이터에 있는 몬스터 스킬이나 유물 데이터만 해도 200개가 넘어가니까...

다만 스크립트에 능한 기획자가 있어야만 이 모든 일이 가능한 것이 어려운 부분이긴 하다. 인수인계도 어려울 거고.

마음 한 켠에서는 스크립트 툴을 블록코딩 형태로 주는 것도 나쁘지 않겠다 싶다. ^Q^...

기획자와 협의해서 다음에는 Lua 스크립트를 써 보자고 얘기했다. 그 때에는 또 글이 올라갈지도 모르겠군...

그래도 이번에 유사 스크립트를 사용하게 만들었기에 Lua도 별 고통 없이 도입할 수 있는 것일지도 모르겠다.

이펙트 스터디 #1: 의문의 불 회오리 그리기

Doublsb — Thu, 17 Jul 2025 15:26:37 +0900

공부 및 기록용으로 쓰는 것이라 글이 다듬어지지 않고 대충 작성되어 있습니다.
양해를 구합니다.

사내 스터디로 이펙트 그리기 & 미감 키우기를 시작했다.

삽질의 시간이었다... 일단 금주의 결과물부터 보도록 하자.

아래는 과정.

앱 선택하기

프로크리에이트 드림을 쓰려고 했는데 앱 평점이 개발살나있어서 대체재를 찾아봄
Callipeg의 평이 괜찮아서 정착

불의 애니메이팅 방식은 이미 유튜브에 많았다

보통 선을 그려놓고 그 방향으로 불을 그리길래 똑같이 그림
근데 마음에 안듬 한프레임씩 그리는데 중심부 크기랑 위치가 일정치 않으니까 퀄리티가 떨어져보임
다시하자 결심함

애초에 불은 어떻게 그리는건데

https://monggus.tistory.com/525

[드로잉] 불 그리는 법 : 채그애봐라

방법1. 실루엣 잡기 (택일) - 덩어리 연결 방식 - 또는 큰덩어리에서 제거 방식 - 또는 바로 그리기 (펜툴, 라소툴) 2. 명암 1단계 표현하기 3. 외곽 다듬기 (디테일 표현) - 날카롭게 다듬는다. 네거

monggus.tistory.com

서칭을 해봤는데 리본형이 가장 예뻐보이고 명암넣기도 쉬워보임 굿굿

그래서 아래처럼 프레임을 잡음 돌려보니까 어 ㅋㅋ 괜찮을거같음

그래서 밥아저씨

많은 시행착오가 있긴 했음 그냥 보셈…

저 리본에 맞게 붉은 선을 그리고 그 위에 노란색 선을 덧입히는 방식으로 그렸음

원형으로 둥글리게 그리는게 아니라 날카로운 선으로 그린다는게 포인트임

그리고 약간의 그… 불의 흐름이 공중으로 상승하는 점같은것도 넣어줌

다음에 뭐할거임

아무래도 결과물이 불 회오리가 되어있어서 마음에 안듬 난 모닥불이 만들고싶었어…

불 미감을 더 볼 필요가 있어서 새로 그리고 이것저것 효과까지 넣어오는걸로

창작욕

Doublsb — Mon, 2 Jun 2025 19:54:01 +0900

무언가를 정성을 다해 만들고 싶다는 생각을, 또 한다.
주기적인 생각이다.

그래봤자 길지 않을 것을 안다.
언제나처럼 껍데기만 만들어놓고는 쌓아 두겠지.

그렇게 쌓인 것만 몇 개인가.
이제는 시체의 산이다.

이 무덤이 훗날 도움이 될 거라고 믿어보고는 있다.
그러나 유용하게 쓴 적은 없었다. 웃기는구만.

오히려 별 생각 없이 만든 것들이 나의 대표작이 되어 세상으로 나간다. 그러면 조금 억울하다.

이 글조차 창작욕을 어떻게든 진정시키려는 의도로 쓰여지고 있다.

옛날에는 왜 나는 엄청난 것을 만들지 못하는가 좌절할 때도 있었는데, 이제는 그냥 이해한다.

그게 그냥 내 역량이다. 나이 먹는 건 최고로군. 이걸 상처받지 않고 받아들일 수 있게 되다니.

그래서 약간 방향을 바꿨다. 빠르게 만들어도 일정 이상의 퀄리티를 뽑아내는 사람이 되자.

그치만 가끔 이렇게 몸이 못 받아들이고 폭주할 때가 있는 거다. 그럼 뭐... 해야지. 하고 또 쌓아놓고, 그렇게 살면 되지.

바라기는 한다.
언젠가 모든 구간에서 진심을 다한 작업물을 세상에 내기.

그래서 그냥 버킷 리스트로만 남겨 놓으려고.
꿈은 꿈일때만 좋을 수도 있으니까.

행복은 어디에서 오는가

Doublsb — Thu, 29 May 2025 00:55:20 +0900

요새 그는 불면증을 겪지 않는다. 현재의 잠이 더 귀중함을 알고 있기 때문이다. 그는 미래에 대한 짐을 덜었다. 미래를 위해 고통받는 건 그 미래에도 여전히 고통받게 된다는 것을 알고 있기 때문이다.

아직 멀었다고 했던가.

맞다. 정말 갈 길이 멀다. 해야 할 일은 많고, 목표에 도달하기 위해서는 끊임없이 달려야 하며, 그 과정에서 '나'는 도구로 소모된다. 자기애는 자기실현의 성장 동력으로 치환되며, 원하는 결과값을 얻기 위해 스스로를 몰게 될 것이다.

하지만 이럼에도 행복할 수 있다니, 어떻게 한 거냐고 묻고 싶다. 과거의 그는 그 비결이 너무나도 궁금했다. 나도 행복해지고 싶어. 어떻게 하면 달리면서 행복할 수 있는건데?

"운동을 해."

...아주 명확한 대답이다. 그래. 거창하게 썼지만 그가 얻은 결론은 그것이었다.

자아 실현을 성공하고, 실패하고 자시고, 어차피 결과값에 따라 기분은 갈리게 된다. 기쁜 것도 잠시이고 슬픈 것도 잠시이다. 고정값이 아닌 행복은 의미가 없다.

운동을 해라.

몸이 정기적으로 도파민과 세로토닌을 분비하게 해라.

"아 그럼, 성공했다는 감각은 쓸모가 뭣도 없나요?"

과거의 그가 물었다. 그러자 현재의 그가 고개를 끄덕였다.

"그건 조건값이 너무 많잖아."

그렇구나. 그는 황당했지만 조언을 따르기로 했다. 인생은 인간인 이상 별 거 없구나.

로컬 LLM을 게임에 넣어보자 #1 : 준비

Doublsb — Tue, 1 Apr 2025 22:22:40 +0900

바야흐로 대 AI 시대이다. 비용과 성능의 사이에서 몸을 비틀며 게임을 만들고 있는 사람들이 많을 거라 생각한다.

나는 그 중에서 최적화 빌런답게 비용에 집중해보기로 했다. 돈 한푼 안 들이고 생성형 AI를 사용하는 프로젝트를 만드는 게 목표다.

한계

뭘 시작하지도 않았는데 한계부터 제시한다.

사실 Llama나 Deepseek 등 저사양 로컬 모델을 일정 기간 사용해봤는데, 완벽한 성능을 기대하는 것은 어려웠다. 한글이 깨지기도 하고, 할루시네이션도 많이 뱉고... 맥락을 제대로 읽지도 못하는 경우가 많았다. (허깅페이스에서 한국어 파인튜닝 모델을 사용했다)

또한 로컬 모델은 컴퓨터 사양에 따라 생성 속도가 달라지는 결정적인 문제점을 가지고 있었다.

일단 이번 프로젝트는 문제점이 해결될만한지 각을 보는 정도로만 하고, 스팀에 무료 출시하는 등의 작업만 하려고 한다.

스펙 정하기

Llama 3.2의 3b 모델로 간다. 왜냐고 물으면 그냥 벤치마크도 그렇고 경험론적으로도 그렇고 제일 괜찮았음.

어차피 나는 AI 개발자가 아니기 때문에 더 이상의 말을 붙일 수는 없다! 몸을 비틀며 생성형 AI를 게임에 넣고 싶은 개발자일 뿐이므로 넘어간다.

게임 기획하기

- 모델이 답변을 생성하는 동안 시간이 걸리므로, AI와의 상호작용은 알림이나 메신저처럼 구현한다.

- 알림이나 메신저가 오기 전까지 플레이어는 다른 짓을 하고 있다. 미니게임 로그라이크를 하고 있자. (??)

- AI와의 대화에 따라 게임 내용이 해금되는 방식을 취하자. 그 해금 기준을 판단하는 것도 AI가 한다.

- AI가 플레이어의 게임 진행에 따라 게임 난이도를 높이거나 낮출 수 있다.

기타

정보를 찾다가, r/LocalLLM과 r/LocalLLaMA 레딧 채널을 찾았다. 최신 로컬 모델 소식을 받기 위해 구독해놓고 매일매일 들어가봐야 할 듯.

How We Die: 우리들이 죽는 방법 회고 (4) - 기타

Doublsb — Thu, 10 Oct 2024 18:50:35 +0900

이제 마무리다. 다른 기타 일감들을 어떻게 처리했는지를 알아보고, 앞으로는 어떻게 해야 할지를 써 보자.

사실 다른 글들은 작업방식에 관한 이야기였는데 이번 글은 홍보 등이 들어 있어서 오히려 가장 회고할 거리가 많은 글인듯.

마케팅 이슈

우리 게임 해주세요~ 같은 글을 정말 못 쓰는 편이다. SNS에 아 오늘 일 끝났다 ^w^ 같은 글만 잔뜩 올리는데 홍보 글을 쓸 리가 만무하다. 스팀 성공 공식인 벤치마크에 따르면 출시 전까지 최소 위시리스트 7,000개는 모아야 중박은 칠 수 있다고 한다.

이 정보를 출시 3개월 전까지 모르고 있었기에, 우리 게임은 아쉽지만 위시리스트가 1000개인 상태로 출시하게 되었다.

작은 갯수지만 이 위시리스트를 어떻게 모았는지 효과가 있었던 것과 없었던 것으로 구분해서 정리해보겠다.

효과가 있었던 것

1) 텀블벅 펀딩

펀딩 페이지를 여는 것 자체만으로 홍보가 됐다. 펀딩 페이지 방문 수는 6000명 정도였는데, 위시리스트 전환으로 이어지는 비율이 소소하게 있었다.

펀딩 기간인 7월부터 8월까지의 그래프를 보면 ~~그래도 이전보다는~~ 기울기가 상승한 것이 보인다.

2) BIC 참가

그렇다. 이건... 가능하다면 반드시 해야 한다. 그래프를 보면 8월부터 갑자기 기울기가 상승한다. BIC의 효과다.

감사하게도 주목을 받아 몇몇 기사에서 게임이 언급되었는데, 이 부분도 큰 도움이 되었다. 역시 게임은 창의적으로 만들어 볼 일이다(?)

다만 기대하게 만든 것 치고는 출시 퀄리티가 애매해서 실망했을 수도 있었을 듯 ^w^... 업데이트로 해결 중이다.

3) 출시

그렇다. 출시하면 된다. 다른 사례를 봤을 때 출시하면 위시리스트가 2배 정도로 증가하는 것 같다.

이 사람들은 할인 기간까지 버티겠지... 가을 세일이나 겨울 세일 때 판매량 증가를 기대해볼 수 있을 것이다.

그때까지 나는 미친듯이 폴리싱을 하고 업데이트를 하면 된다. 다음 세일은 11월 27일이니 화이팅하자.

효과가 없었던 것

1) 레딧

해외야말로 중요한 시장이라고 생각하고 있었기에, 인디 선데이에 가서 r/Games에 글을 썼다.

그치만 카르마가 0인 사람의 글은 효과가 없었다. 죄송합니다... 열심히 양질의 글과 댓글 써내겠습니다...

2) 트위터 영문 홍보

조회수가 337이다. 이 이후로 현타가 와서 올리지 않았음.

3) 틱톡

조회수가 0이다. 뭘... 뭘 어떻게 해야 되는 거야?

아쉽게 못한 것

스팀 넥스트 페스트에 참가를 못한 게 위시리스트 1000개가 된 근본적인 원인이다.

이걸 기간 상 참가를 못하고 출시했기 때문에 해외 홍보가 되지 않았고, 판매량의 95%가 국내에서 나오게 되었다.

차기작을 한다면 데모를 열어놓고 온갖 행사에 참여하며 위시리스트 7000개가 될 때까지 버틸 생각이다. 2년 후에 개발을 시작한다고 가정하면 4년 뒤에나 나오겠군. ^w^;;

번역에 대하여

기획 파트에서 썼듯이, 본래 스토리 콘텐츠는 들어가지 않을 계획이었다.

데모까지 작업을 하고 난 뒤 로컬라이징 시트를 살펴보니 4000단어 정도의 스토리 분량이 만들어져 있었다.

본래는 자체적으로 이를 번역하는 식으로 출시하려고 했으나, 번역이 Rough하다는 리뷰가 달려 번역업체를 고민하게 되었다.

마일스톤 상 번역은 일정에 들어 있지 않았던 부분인데, 이를 빠르게 진행하여 홍보 일정을 짜는 바람에 재능마켓 등의 서비스를 이용하게 되었다. 그리고 거기서 사기 당함 ^w^... 일정이 어그러졌지만 환불받기는 했다. 번역기를 썼는지 AI를 썼는지는 모르겠지만 같은 스토리 안에서 화자의 성별이 남성이었다가 단체였다가 여성으로 바뀌질 않나, 느려 터졌다는 구문이 진짜 exploded로 번역되 오질 않나... 난리도 아니었음.

진짜 믿을만한 업체에 맡겨야겠다고 생각해서 다른 인디개발자분들도 자주 이용하시는 갤럭틱 엔터테인먼트에 신세를 지게 되었는데, 작업도 높은 퀄리티로 해 주시고 작성 의도에 따라 표현을 제안해주시는 등 너무 감사했다. 게임 자체가 많은 루프를 돌려야 하기에 테스트가 어려운 게임이었는데도 불구하고 LQA까지 완벽하게 완료해서 주셨음. 다음에도 신세를 질 수 있다면 꼭 지고 싶다.

바이럴같이 썼는데 바이럴되라고 이렇게 쓰는 거다. 잘해주시는 분들은 잘한다고 외쳐야 함.

별개로 스토리가 주가 되는 게임은 기간을 무조건 넉넉하게 잡고 만들어야 한다는 것을 깨달았다.

건강 이슈

또, 또, 또! 건강 관리에 실패했다. 회사의 출퇴근 시스템이 없으니 7일 중에 7일을 일했고, 주간 업데이트 일정은 정해져 있으니 낮밤이 바뀌었다. 밤 12시에 출근해서 아침 8시에 퇴근하는 등 건강 관리하는 데 최악의 조건만 골라서 일했다.

헬스장도 3월부터 7월까지는 잘만 다니다가 출시 2개월 전부터는 바쁘다는 핑계로 가지 않았다. 물론 진짜 바쁘기도 바빴지만 가는 게 더 효율적으로 일할 수 있었을 것이라 생각하니 눈물이 난다. 어 그래... 아무리 J인 척을 해도 INTP는 INTP인 것이다. ^w^...

지금은 원래 작업량과 시간대로 회복 중임. 나는 계획을 세우고 그대로 행동해야 행복하게 살 수 있는 타입이라는 걸 요새 뼈저리게 느끼고 있다.

금전 이슈

사실 이게 좀... 정말 체감이 안 됨. 통장 잔고가 늘었다가 줄었다가 했다.

버틸 만큼 모아놓은 돈으로 작업에 들어갔던지라 스트레스는 없었는데, 내가 얼마만큼을 쓰고 벌었는지가 가시적으로 보이지 않았다.

일단 주식 이슈로 잔고가 늘었다 줄었다하고, 도중에 텀블벅 정산이 들어왔고, 도중에 팀원들 정산도 하고, 도중에 외주도 하고 그래서... 어... 분명 적자이긴 적자인데 통장 잔고로 판단하다보니 체감이 안 됨. 내역을 까보면 당연히 얼마나 썼는지 알겠지만 일단 모르겠다. 아무튼 아직까지 이 프로젝트는 적자다! 출시한 지 3주밖에 안 되어서 어떻게 될지는 모르겠지만 ^w^

차기작

차기작 생각할 시간이 어디 있어! 업데이트부터 계속 쳐야 한다.

이번 프로젝트를 하고 나니 아직도! 배워야 할 게 많다고 생각하기에 일단 다른 직장으로 갈 것이다.

그러면 아마 2년 뒤에는 작업을 시작하지 않을까. 콤보 미친듯이 넣어야 하는 액션게임.

음... 해치웠나는 또 언제 만들지... 미래에 보이는 게 일밖에 없다. 스불재의 인생 화이팅.

How We Die: 우리들이 죽는 방법 회고 (3) - 그래픽

Doublsb — Thu, 10 Oct 2024 17:46:10 +0900

결국 그래픽 회고를 쓸 때가 와버렸다. 나는... 나는 아트를 못한다! 아니, 못하기도 못하는데 못하겠다!

어떻게 이 감각으로 몸을 비틀며 아트를 만들어냈는지 그 작업방법을 소개한다.

미드저니 사용

우선 짚고 넘어가자. 이 게임은 아트에 AI를 사용한 게임이다.

3D인데 어떻게 AI를 썼다는거임? 하는 사람들이 종종 있다. 화면에서 AI가 만든 부분들만 표시해보면 다음과 같다.

1. 맵 배경 이미지

이건 아주 정직하게, 보드 뒷편에 깔리는 맵 배경 이미지이다.

게임에는 20장 정도 들어갔는데 해당 이미지 위에 오브젝트가 올라가기 때문에 어차피 가려지고 마는 비운의 리소스다 (...)

2. 선택지 상황 배경 이미지

해당 캐릭터들이 처한 상황을 더 쉽게 알아볼 수 있도록 1:1 사이즈로 나타낸 스토리 배경 이미지이다.

이걸 뽑는게 난관이었는데, 어쨌든 아트 스타일을 맞춰야 했기에 흑백/스케치/코믹 스타일 태그를 넣어가며 뽑았다.

하지만 AI가 늘 그렇듯이 작업자가 직접 그려주는 것만 못하다. 통일성도 없고, 바닥을 보면 온갖 말도 안되는 것을 다 넣어서 생성함.

차기작부터는 우리 일러레한테 전부 맡겨서 행복해지거나, 무료 개인작이면 내가 배경을 배워서 리터칭하는 방식으로 써야 할 듯...

3. 캐릭터 토큰 이미지

3D화도 해야 해서 가장 손이 많이 가는 리소스다. 사실 처음에는 우리 일러레가 그리기로 했었는데 남은 시간을 봤을 때 우리 일러레에게 너무 많은 작업량을 넘겨주고 싶지 않아서 AI를 택했다.

캐릭터 토큰을 3D화하는 과정은 다음과 같다.

두번째가 Midjourney, 세번째가 리터칭

우선 일러스트레이터가 그려 준 의상과 분위기를 참고해서 원하는 구도가 나올 때까지 이미지를 뽑는다.

그리고 원본 일러스트와 비슷한 분위기가 될 때까지 리터칭해서 맨 오른쪽처럼 만든다.

그리고 이 이미지를 블렌더로 불러와서 버텍스로 선을 딴다. 그리고 입체화시킨 뒤에 UV를 만듬. 이 UV 이미지를 Export해서 포토샵으로 불러온다.

그리고 UV 이미지에 리터칭한 이미지를 얹고, 유니티에서 머티리얼화하면 완성... 개노가다 작업이다.

익숙해져서 1시간에 1마리씩 만드는 것으로 공정을 최소화했지만 눈이 아팠던 건 어쩔 수 없음.

3D 모델링하기

이외의 배경 기물은 모델링이 불가피했다. 덕분에 블렌더 사용 방법 하나는 확실하게 알았다.

아트 감각이 없어도 되는 수준의 레퍼런스가 존재하는 로우폴리는 만들 수 있게 됨 (...)

다행히 이번에 만든 것들은 실생활에서 쉽게 볼 수 있고, 핀터레스트에서 레퍼런스를 찾아볼 수 있는 것들이었음.

보드판, 타일 등은 직접 모델링했다. 다만 동그라미 친 것들은 당연하게도 무료 3D 모델링 사이트에서 가져온 것임.

동그라미는 가져온 리소스

이펙트 만들기

여기에서 제일... 제일 고통 받음. 이 게임의 이펙트가 직관적이고 투박한 이유는 당연히 내가 이펙트를 잘 못 만들어서임.

에셋으로도 커버를 못 하는 부분이 많다. 대부분은 판타지나 2D 에셋이고 우리 게임은 미묘한 실사풍 그래픽이었기 때문에 에셋을 찾는 데에도 애를 먹었고, 수정하거나 만드는 데에도 애를 먹었음.

아래의 것 정도가 내 최대치가 아니었나 싶다.

다만 아직 어떻게 될지는 모르지만 우리 일러스트레이터가 이펙터로 진화하고 있다.

만약 그렇게만 된다면........... 아아.......................... 행복해

팀원에게 도움 받기

혼자 하는 것이 불가능하고 에셋으로도 커버할 수 없는 작업은 팀원들이 해 주었다... 캐릭터 일러스트와 UI/UX가 그것이다.

역시 협업이 짱이다. 리소스가 올 때마다 나는 눈물을 흘리며 행복하게 게임에 적용시켰다.

약간 죄책감이 드는 것은 사실 UI/UX 팀원이 UX에서 고쳐야 할 점을 정리해서 엄청나게 말해주었는데, 출시하느라 바빠서 전부 다 적용하지 못했다(...) 이 부분은 업데이트로 해결해가고 있다. UX로 인해 돌을 던진다면 전부 다 내가 맞아야 한다. 그는 잘못이 없다. ^w^...

느낀 점

사람은 잘하는 것을 해야 한다.