라벨이 "게임 설계"인 게시물 표시

사랑을 직접 올리지 않는 설계

  이전 편에서 3계층 감정 모델을 설계했다. 그 중 가장 중요한 원칙이 하나 있다.  사랑이라는 변수는 시스템에 존재하지 않는다. love += 1은 없다. 대신 사랑은 다른 변수들의 조합에서 "발생"한다. 이게 이 시스템의 핵심이고, 기존 호감도 시스템과의 가장 큰 차이다. 왜 사랑을 직접 변수로 두면 안 되는가 AI와 이 주제로 대화했을 때, AI가 흥미로운 관점을 제시했다. "사랑은 다른 감정과 같은 급이 아니다." 슬픔, 분노, 질투, 두려움. 이것들은 단발적 감정이다. 특정 사건에 반응해서 올라가거나 내려간다. 하지만 사랑은 다르다. 사랑은 보통 단발 감정보다  누적된 관계 해석의 결과 에 가깝다. 신뢰가 높다. 의존이 있다. 친밀감이 쌓였다. 질투도 약간 있다. 상실 공포가 있다. 상대를 반복적으로 우선 선택한다. 이 조합을 플레이어가 "사랑"으로 읽는 거다. 시스템적으로 이걸 표현하면 이렇다. love_state = ( trust >= 70 and intimacy >= 60 and fear_of_loss >= 30 and chosen_priority >= 5 ) love를 직접 올리는 게 아니라, 사랑이 발생하는 조건을 설계하는 것이다. 이 차이가 크다. 왜 이 방식이 더 자연스러운가 현실을 생각해보자. 누군가를 사랑하게 되는 순간을 정확히 짚을 수 있는 사람이 있는가? 대부분은 없다. 어느 날 문득 "아, 내가 이 사람을 좋아하는구나"를 깨닫는 거다. 사랑은 시작 버튼을 누르는 게 아니라, 이미 쌓여 있던 것을 인식하는 거다. love += 1 시스템에서는 이 경험을 재현할 수 없다. 선택할 때마다 사랑이 올라가니까, 플레이어는 "지금 사랑이 몇 점쯤 되겠지"를 계산하게 된다. 감정이 아니라 점수 관리가 된다. 조건 조합형에서는 다르다. 플레이어는 사랑 수치를 모른다. 사랑이라는 변...

감정을 변수로 옮기다 — 3계층 감정 모델

  이제 본격적으로 감정을 설계할 차례다. 호감도+1의 한계를 파악했으니, 그걸 대체할 시스템을 만들어야 한다. AI에게 말했다. "호감도 하나가 아니라, 사람의 감정을 좀 더 현실적으로 표현할 수 있는 변수 시스템을 만들고 싶어." 그리고 여기서부터 AI가 본격적으로 힘을 발휘하기 시작했다. 감정을 구조화하는 작업, 즉 추상적인 것을 변수와 계층으로 분해하는 작업은 AI가 잘하는 영역이다. 감정은 몇 개가 필요한가 첫 번째 질문이 이거였다. "감정 변수를 몇 개 두면 될까?" AI의 답은 의외로 신중했다. "많으면 많을수록 좋은 게 아니다. 변수가 많아지면 오버엔지니어링이 된다." 그리고 핵심적인 구분을 제안했다. 표현해야 하는 감정의 종류는 많아도 된다. 하지만 시스템이 직접 추적하는 상태값은 구조적으로 정리되어야 한다. 무슨 뜻인가. 사랑, 슬픔, 분노, 자만, 시기, 질투, 믿음, 신뢰, 긴장, 갈등, 두려움, 공포, 선망. 이런 감정을 전부 독립 변수로 나열할 수는 있다. 하지만 그러면 상호작용 규칙이 폭증한다. 어떤 이벤트가 뭘 얼마나 바꾸는가, 사랑과 신뢰가 동시에 오를 수 있는가, 시기와 선망의 차이는 어떤 조건에서 갈라지는가. 정의 없이 변수만 많으면 게임이 더 가짜가 된다. 그래서 AI가 제안한 건 감정을 레이어로 나누는 것이었다. 3계층 모델 AI와 반복적으로 대화하면서 정리된 구조가 이거다. A층: 근본 성향 / 욕구  — 캐릭터의 고유값. 쉽게 안 바뀐다. 게임 시작 시 설정되고, 플레이 중에는 거의 변하지 않는다. 애정 욕구 (need_for_affection) 거절 공포 (fear_of_rejection) 자존심 (pride) 불안정감 (insecurity) 이건 캐릭터의 "성격"이다. 왜 이 사람이 이런 행동을 하는지의 근본 이유. B층: 현재 감정 상태  — 장면이나 사건에 반응해서 흔들린다. 순간적이고 유동적이다. 애정 (affection) 분노 (anger...