〈더 지니어스 in CLS: Frostbite〉 진행 결과 및 후기

새로운 게임과 함께 반년만에 돌아온 더 지니어스 오프라인 모임

2025-02-16

-

소개

  • 게임 명칭: 더 지니어스 in CLS: Frostbite
  • 게임 일시: 2025년 2월 16일 일요일 2시 ~ 6시
  • 게임 장소: 서울대학교 220동 204호, 206호
  • 호스트: 이현서, 백장운
  • 플레이어: 김수민, 임채준, 김상혁, 박영민, 김리, 백승진, 황준석, 김건희, 연제혁, 윤성원, 이성훈, 박도현 (총 12명)

실명 기재 및 얼굴 공개에 대해 플레이어의 허락을 구했음을 알려드립니다.
해당 글은 플레이어들과의 인터뷰를 바탕으로 작성한 것으로, 실제 플레이어의 생각이나 진행 과정과는 차이가 있을 수 있습니다.


메인매치: 흥부와 놀부

오늘의 메인매치는 흥부와 놀부입니다.
흥부와 놀부는 적절한 마을로 이동, 역할을 선택해 엽전을 얻는 게임입니다.

흥부와 놀부 룰지흥부와 놀부 룰지

룰지 pdf 파일로 보기

메인매치 진행

각 라운드 결과를 위주로 전체적인 흐름만 간단하게 살펴보겠습니다.

룰 공개

흥부와 놀부 룰 공개흥부와 놀부 룰 공개

해당 게임은 선택 단계에서 그룹 별로 역할 선택이 진행됩니다. 라운드가 진행됨에 따라 플레이어들과의 제출 시간 전후 관계는 계속해서 바뀌는 반면, 같은 그룹의 플레이어와는 항상 같은 제출 타이밍을 가집니다. 자연스럽게 같은 이해관계를 가지고 있는 각 그룹 플레이어들끼리 대화를 하기 시작했습니다.

한편 지난 회차 우승자인 [9 연제혁] 플레이어는 한개 더 많은 엽전을 가져 우위에 서있습니다. 그러나 만약 다른 플레이어와 동률이 될 경우 18번 규칙에 의해 우선 순위에서 밀리게 되므로 반드시 단독 1등을 해야만 한다는 압박도 존재합니다.

1라운드

1라운드는 탐색전입니다. 아직 전략을 세우기에는 많은 정보가 나오지 않아 연합이 탄생하지 않았습니다. 플레이어들은 우선 1라운드 결과를 보고 그에 따라 유동적으로 연합을 구성하려고 합니다.

처음부터 터져버린 게임처음부터 터져버린 게임

그런데 1라운드 결과 [9 연제혁] 플레이어가 윗마을에서 엽전 4개를 몰아먹습니다. 윗마을에서 아무도 거짓말을 하지 않아 '흥부'와 '놀부'의 수가 동률이 되었고, 유일하게 '제비'를 선택한 [9 연제혁] 플레이어가 엽전을 모두 얻은 것입니다. 엽전 1개의 베네핏을 추가로 가지고 있던 [9 연제혁] 플레이어는 총 8개의 엽전으로 압도적인 우세를 가져갑니다.

2라운드

전략을 세우는 플레이어들전략을 세우는 플레이어들

1라운드 결과를 바탕으로 그룹 5, 6, 1의 플레이어들은 [9 연제혁] 플레이어의 우승을 목표로 연합을 구성합니다. 나머지 플레이어들은 엽전의 수가 거의 비슷하기에 뚜렷한 목표를 가진 연합이 나오지 않았습니다.

2라운드 진행 결과 [5 김 리], [12 박도현] 플레이어가 엽전을 2개씩 얻어 총 5개, [7 황준석], [8 김건희] 플레이어가 엽전을 1개씩 얻어 총 3개의 엽전을 가지게 됩니다. 5개의 엽전을 가진 플레이어가 2명이 되면서 플레이어간 격차가 조금씩 줄어들기 시작합니다.

3라운드

그룹 3의 [6 백승진] 플레이어는 엽전을 5개 가지고 있는 [5 김 리] 플레이어에게 엽전을 몰아줘 우승시킬 계획을 세웁니다. 그리고 그룹 6, 1의 플레이어들([11 이성훈], [12 박도현], [1 김수민], [2 임채준]) 또한 연합을 구성합니다. 우승을 계획하는 연합이 있는 반면 엽전을 한두개라도 더 얻어 탈락후보라도 피하려는 플레이어들도 있습니다.

[5 김 리] 플레이어는 엽전 획득에 실패한다[5 김 리] 플레이어는 엽전 획득에 실패한다

아쉽게도 [5 김 리] 플레이어는 엽전 획득에 실패합니다. 탈은 '제비'로 제출하고 실제 역할은 '노비'로 제출한 뒤 흥부의 수를 5개 이상으로 높여 노비에게 몰아주려고 했지만 팀원 모두가 앞 순서여서 뒤 플레이어들을 통제할 수 없었습니다. 불행중 다행으로 [5 김 리] 플레이어를 제외한 나머지 플레이어들은 엽전을 하나씩 획득합니다.

한편 아랫마을에서는 정직하게 '놀부'를 제출한 [11 이성훈], [1 김수민] 플레이어가 엽전을 하나씩 획득합니다.

4라운드

4라운드부터 플레이어간 연합이 조금 더 명확해집니다.

  • 그룹 1, 6: [1 김수민], [2 임채준], [11 이성훈], [12 박도현]
    이들은 탈락후보를 피하는 것이 목표입니다. 거짓말은 하지 않되 엽전을 한두개 얻을 수 있는 기회를 확률을 높이고자 합니다.

  • 그룹 2, 5: [3 김상혁], [4 박영민], [9 연제혁], [10 윤성원]
    [9 연제혁] 플레이어의 우승을 만드는 것이 목표입니다. [9 연제혁] 플레이어는 [10 윤성원] 플레이어를 최하위에서 구제하고 생명의 징표를 주려는 목표도 추가로 가지고 있지만, 나머지 팀원들이 별로 달갑게 생각하지 않는 것 같습니다.

  • 그룹 3, 4: [5 김 리], [6 백승진], [7 황준석], [8 김건희]
    아직은 뚜렷한 목표를 가지고 있지 않습니다. 하지만 이 이후부터 우승 후보가 연속으로 생기며 중요한 연합으로 떠오르게 됩니다.

4라운드 결과 공개중4라운드 결과 공개중

4라운드 결과 윗마을에서 흥부가 총 5명으로 넘쳐 모든 엽전은 노비에게 돌아갑니다. 이에 따라 [2 임채준], [5 김 리] 플레이어가 엽전 2개를 얻게 됩니다. [5 김 리] 플레이어는 총 6개의 엽전을 가지게 되어 우승권에 들어섭니다.

한편 아랫마을에서는 모두 정직하게 역할을 선택했습니다. 흥부를 선택한 [8 김건희], [10 윤성원] 플레이어가 엽전 1개씩을 추가로 얻습니다. [10 윤성원] 플레이어는 총 엽전 3개가 되어 단독 최하위에서 벗어나게 되었습니다.

5라운드

5라운드에서도 플레이어들간 연합은 비슷하게 유지됩니다.

첫 순서에 걸린 [9 연제혁] 플레이어는 엽전을 얻기 위해 [10 윤성원], [3 김상혁], [4 박영민] 플레이어와 함께 계획을 세웁니다. 나머지 팀원들을 모두 윗마을 흥부로 제출하게 해 흥부 수를 5명 이상으로 늘리고 자신은 노비를 제출하여 엽전을 얻을려고 합니다. 나머지 플레이어들 중 적어도 한두명 정도는 윗마을 흥부를 내지 않을까 생각한 것 같습니다.

5라운드 결과5라운드 결과

그러나 5라운드 결과 윗마을에서 흥부의 수가 딱 4명이 되어 이들이 각각 1개씩 엽전을 획득합니다. 흥부가 많아 놀부를 내 균형을 맞추려는 플레이어들, 그리고 균형이 맞춰질걸 예상하고 제비를 제출한 플레이어들 때문에 흥부의 수가 4를 넘지 못한 것입니다. 오히려 탈과 역할을 다르게 제출했던 [9 연제혁] 플레이어는 엽전 1개를 잃게 됩니다.

한편 아랫마을에서는 놀부를 제출한 [8 김건희] 플레이어가 엽전을 2개 획득하게 됩니다. 마지막 제출이라는 순서의 이점을 잘 살린 결과입니다. 총 엽전 개수가 7개가 되면서 [9 연제혁] 플레이어와 동점이 됩니다.

6라운드

이제 엽전 7개를 가진 두 플레이어 [8 김건희]와 [9 연제혁]은 우승을 하기 위해 마지막 계획을 세웁니다. 하지만 우승을 하지 못할바에는 깽판을 치겠다는 앞 순서 플레이어들 때문에 결과를 예측하기가 쉽지 않습니다. 6라운드 결과를 포함한 최종 결과는 아래 영상에서 보실 수 있습니다.

공교롭게도 윗마을에서 흥부와 놀부의 수가 맞아 떨어지면서 제비를 선택한 [4 박영민] 플레이어가 엽전 4개를 독식하게 됩니다. 아랫마을에서도 흥부와 놀부의 수가 같아져 [5 김 리] 플레이어가 엽전 2개를 독식하지만 1개가 부족하여 우승에는 미치지 못했습니다. 결과적으로 [4 박영민] 플레이어가 총 엽전 9개로 최종 우승하게 됩니다.


데스매치: 같은 숫자 찾기 II

오늘의 데스매치는 같은 숫자 찾기 II 입니다.

같은 숫자 찾기 II 룰지같은 숫자 찾기 II 룰지

룰지 pdf 파일로 보기

우승자 [4 박영민] 플레이어가 탈락후보중에 파트너로 [5 김 리] 플레이어를 선택하였습니다. 이에 따라 데스매치는 1팀 [4 박영민], [5 김 리] 플레이어와 2팀 [6 백승진], [9 연제혁] 플레이어의 대결로 진행되었습니다.

플레이어들은 이렇게 팀별로 앉아 문제를 풀고,플레이어들은 이렇게 팀별로 앉아 문제를 풀고,
저는 컴퓨터를 통해 데스매치를 진행했습니다.저는 컴퓨터를 통해 데스매치를 진행했습니다.

결과적으로 [4 박영민], [5 김 리] 팀이 7:2로 승리하면서 1팀의 [4 박영민] 플레이어가 최종 우승을, 2팀의 [6 백승진] 플레이어가 최종 탈락을 하게 되었습니다.


회고

게임 기획 과정에서의 고민들

메인매치

메인매치 게임 종류를 고민하면서 아래와 같은 조건들을 고려하게 되었습니다.

  • 너무 시시하게 끝나버리면 안됨
    단발성 게임이기 때문에 적어도 2시간 이상은 진행이 되어야 한다고 생각했습니다. 정체가 들통나면 바로 게임이 끝나는 마피아류 게임처럼 진행 시간의 편차가 큰 게임은 피하게 되었습니다.

  • 처음에 실수하더라도 끝까지 존재감이 있어야 함
    위 조건과 거의 동일한 이야기입니다. 모두가 즐길 수 있도록 하기 위해 시작에 삐끗하더라도 충분히 한 플레이어로서 충분히 활약할 수 있는 게임을 만들고 싶었습니다.

위 두 조건을 생각하다 보니 저번 게임처럼 플레이어 전체가 서로 영향을 주며 재화를 획득하는 게임 느낌으로 가게 되었고, 이번에는 더 지니어스 106의 〈도둑잡기〉와 406의 〈가넷도둑〉을 합쳐 새로운 게임을 만들게 되었습니다.

해당 게임에서 중요한건 각 마을별 엽전의 개수였습니다.. 406의 〈가넷도둑〉에서 라운드별 가넷의 개수(4)가 플레이어의 수(8)의 절반이었던 점을 참고해, 저희 또한 전체 플레이어 수(12)의 절반(6)으로 엽전의 개수를 설정하였습니다. 그리고 윗마을과 아랫마을의 적당한 분배가 8명, 4명이라고 생각하여 엽전을 4개, 2개로 나누었습니다.

게임을 준비하며 6라운드동안 같은 규칙을 사용하면 지루하지 않을까 하는 고민을 했었습니다. 그래서 각 플레이어별로 미션을 준다던가, 갑자기 새로운 캐릭터를 출현시킨다던가 하는 대안을 떠올렸습니다. 하지만 그런 요소들 중에 기존 규칙과 어울리면서도 간결하게 정리되는 것이 없었기에 아무것도 적용하지 않았습니다.

결과적으로 돌이켜보면 라운드마다 엽전 개수가 변하는 등 변칙적인 룰이 필요했던 것 같습니다. 이러한 룰이 없다보니 6라운드 전체가 비슷한 흐름으로 흘러갔고, 빈틈을 파고드는 획기적인 전략보다는 엽전 개수를 유지하는 보수적인 전략이 채택되어 예측 불가능성이 줄어들게 되었다고 느낍니다.

데스매치

작년 8월달에 진행한 지니어스에서는 데스매치를 미처 준비하지 못해 즉석에서 Excel로 흑과백 II를 구현하여 진행했었습니다. 데스매치에 참여한 플레이어들은 재밌게 게임을 하였고 진행도 순조롭게 되었지만, 관전 플레이어들은 지루함을 느끼는 모습을 보게 되었습니다. 그 이유는 흑과백 II 게임 특성상 각 플레이어의 남은 점수는 스스로만 알 수 있기 때문입니다. 아무 정보도 알지 못하는 관전 플레이어들은 전략을 세울수도, 상황을 즐길수도 없게 된 것입니다.

따라서 이번 데스매치는 모두가 즐길 수 있는 게임으로 준비하게 되었습니다. 가장 쉬운 방법은 〈결! 합!〉이나 〈같은 숫자 찾기〉와 같은 퀴즈류의 게임이라고 생각했고, 그중에서도 2대2 게임에 어울리는 같은 숫자 찾기 게임을 응용한 〈같은 숫자 찾기 II〉게임을 준비하게 되었습니다.

주어진 타일로 만들 수 있는 모든 숫자들과 각 조합의 수주어진 타일로 만들 수 있는 모든 숫자들과 각 조합의 수

타깃 넘버를 정할 때는 플레이어들이 더욱 쉽게 게임에 적응할 수 있도록 숫자의 난이도가 처음에는 쉽다가 조금씩 올라가도록 하였습니다. 이를 위해 주어진 숫자들로 나올 수 있는 모든 조합과 경우의 수를 계산하였고, 이를 토대로 각 숫자의 난이도를 측정하였습니다.

또한 두 팀 점수의 최댓값을 기준으로 게임을 초반(0~2), 중반(3~4), 후반(5~6)으로 나누었습니다. 전체적으로는 난이도가 우상향하도록 하고, 각 단계에서는 진행에 어려움이 없도록 적당히 난이도를 세부조정하였습니다.

결과적으로 선정된 타깃 넘버 목록과 난이도를 정리해보면 다음과 같습니다.

나름대로 고민 좀 했습니다나름대로 고민 좀 했습니다

타깃 넘버 오른쪽에 괄호로 적혀있는 수는 해당 타깃 넘버를 만들 수 있는 조합의 수입니다. 해당 수가 클수록 쉽고, 작을수록 어려워진다고 가정했습니다. 또한 빨간색 실선은 해당 구간에서 필수적으로 풀어야 하는 문제, 빨간색 점선은 풀수도 있고 안풀수도 있는 문제들입니다. 위 그림에는 적지 않았지만 타깃 넘버가 패스될 것을 고려하여 각 구간별로 여유분의 타깃 넘버를 추가하였습니다. 이들은 그래프에서 검은색 실선으로 표시되어 있습니다.

디스플레이 개발

이번 오프라인에서도 강의실 스크린에서 계속해서 보여줄 디스플레이 화면과, 플레이어가 역할 제출에 사용할 UI가 필요했습니다. 저번에 웹 개발을 통해 구현했을 때 굉장히 편리했기 때문에 이번 오프라인 또한 동일한 방법으로 준비했습니다. 개발 스택 역시 Next.js + supabase + tailwindCSS 로 동일합니다.

다만 이번에는 상태 관리 라이브러리인 zustand를 새롭게 도입해 보았습니다. 이는 실제 게임 진행시 사용감과 별개로 개발 경험(Developer Experience)가 좋지 않았기 때문인데, 잦은 Props Drilling이나 간결하지 못한 코드구조로 인해 개발 속도의 지연 등 불편한 점들이 있었기 때문입니다. 자세한 내용은 다음과 같습니다.

플레이어 정보 관리

id, 이름, 선택한 마을/역할 등의 정보를 담은 players 테이블의 데이터는 해당 웹 사이트의 모든 페이지에서 사용하는 정보입니다. 때문에 하위 컴포넌트가 추가될수록 계속해서 Props를 내려줘야 하는 Props Drilling 현상이 발생하였습니다. 또한 해당 데이터는 한번 다운받았다고 끝이 아니라 supabase의 realtime 기능을 사용하여 실시간 동기화도 구현해주어야 합니다. 이 과정에서 각 페이지의 page.tsx 파일마다 realtime을 연결하는 긴 코드가 작성되는 등 간결한 구조를 유지하기가 어려워졌습니다.

이러한 문제는 zustand를 도입하자 매우 쉽게 해결되었습니다.

stores/players.ts
import { create } from "zustand";
import { supabase } from "@/utils/supabase/client";
 
interface PlayersStore {
  players: Player[];
  shiftedPlayers: (round: number) => Player[];
  groupedPlayers: (round: number, size: number) => Player[][];
  loading: boolean;
  fetchPlayers: () => Promise<void>;
  subscribeRealtime: () => () => void;
}
 
export const usePlayersStore = create<PlayersStore>((set, get) => ({
  players: [],
  shiftedPlayers: (round: number) => {
    // ...
  },
  groupedPlayers: (round: number, size: number) => {
    // ...
  },
  loading: false,
  fetchPlayers: async () => {
    set({ loading: true });
    const { data: players, error } = await supabase
      .from("players")
      .select("*")
      .order("id");
    if (error) {
      console.error("Error fetching data:", error);
    } else {
      set({ players, loading: false });
    }
  },
  subscribeRealtime: () => {
    const channel = supabase
      .channel("realtime:players")
      .on(
        "postgres_changes",
        { event: "*", schema: "public", table: "players" },
        (payload) => {
          // ...
        },
      )
      .subscribe();
 
    return () => {
      supabase.removeChannel(channel);
    };
  },
}));

위와 같이 전역 저장소에 players 테이블의 데이터를 다운받고 realtime을 연결하는 함수를 작성해줍니다. 그 다음에 아래처럼 FetchPlayers 클라이언트 컴포넌트를 만들어 루트 layout.tsx 파일에 넣어주면 손쉽게 작업이 끝납니다.

components/common/FetchPlayers
"use client";
 
import { usePlayersStore } from "@/stores/players";
import { useEffect } from "react";
 
export default function FetchPlayers() {
  const { fetchPlayers, subscribeRealtime } = usePlayersStore();
 
  useEffect(() => {
    fetchPlayers();
    const unsubscribe = subscribeRealtime();
 
    return () => {
      unsubscribe();
    };
  }, []);
 
  return null;
}

위에서 볼 수 있듯이 단순히 플레이어 데이터 리스트 뿐만 아니라 shiftedPlayers, groupedPlayers 등 유틸 함수도 구현해놓아 프로젝트 어디서든 쉽게 플레이어 데이터를 가공하여 사용할 수 있습니다.

장면 이동 정보 관리

디스플레이의 각 장면은 키보드 왼쪽 화살표와 오른쪽 화살표를 눌러 이동할 수 있습니다. 기존에는 라운드, 장면 타입과 같은 정보들을 최상단 클라이언트 컴포넌트에 useState로 선언하고 Props로 내려주는 방식으로 구현해 Props Drilling 문제가 심각했습니다. 또한 키보드 이벤트를 각 컴포넌트 내에서 관리했기 때문에 유지보수가 힘들었습니다. 이 또한 zustand를 사용하여 다음과 같이 수정하였습니다.

우선 라운드 · 턴과 같은 장면 정보와 함께, 장면 이동시 각 변수가 어떻게 변해야 하는지를 설명하는 함수를 구현해 전역 저장소에 넣어줍니다.

stores/progress.ts
import { create } from "zustand";
 
interface ProgressStore {
  scene: Scene;
  round: number;
  turn: number;
  next: () => void;
  prev: () => void;
}
 
export const useProgressStore = create<ProgressStore>((set) => ({
  scene: "idle",
  round: 0,
  turn: 0,
  next: () =>
    set((state) => {
      switch (state.scene) {
        case "idle":
          return { scene: "rule" };
        case "rule":
          return { scene: "select", round: 1 };
        case "select":
          if (state.turn < 6) {
            return { turn: state.turn + 1 };
          } else {
            return { scene: "result", turn: 0 };
          }
        // ...
      }
    }),
  prev: () =>
    set((state) => {
      switch (state.scene) {
        // ...
    }),
}));

다음으로 page.tsx 파일에서 해당 저장소를 불러와 useEffect 함수로 키보드 이벤트를 등록해주기만 하면 됩니다.

app/main/page.tsx
"use client";
 
import { useEffect } from "react";
import { useProgressStore } from "@/stores/progress";
import Idle from "@/components/main/Idle";
import Rule from "@/components/main/Rule";
import Select from "@/components/main/Select";
import Result from "@/components/main/Result";
import Final from "@/components/main/Final";
import QR from "@/components/main/QR";
 
export default function Page() {
  const { scene, next, prev } = useProgressStore();
 
  useEffect(() => {
    const handleKeydown = (e: KeyboardEvent) => {
      if (e.key === "ArrowRight") {
        e.preventDefault();
        next();
      }
      if (e.key === "ArrowLeft") {
        e.preventDefault();
        prev();
      }
    };
 
    document.addEventListener("keydown", handleKeydown);
 
    return () => {
      document.removeEventListener("keydown", handleKeydown);
    };
  }, [next, prev]);
 
  return (
    <div className="flex h-full flex-grow flex-col items-center">
      {scene === "idle" && <Idle />}
      {scene === "rule" && <Rule />}
      {scene === "select" && <Select />}
      {scene === "result" && <Result />}
      {scene === "final" && <Final />}
      {scene === "qr" && <QR />}
    </div>
  );
}

이렇게 전역 상태 관리 라이브러리를 활용해 상태를 관리하니 개발 경험과 함께 개발 속도도 비약적으로 좋아졌습니다.

기타

더 많은 인원 모집

이전 게임에서는 총 9명의 플레이어를 모집해 게임을 진행했었습니다. 더 많은 사람들을 모았을 때도 게임 준비 및 실제 게임 운영을 순조롭게 진행할 수 있을지 궁금해졌고, 이번에는 3명을 더 추가한 12명의 플레이어로 확장해보았습니다.

그러나 게임을 마치고 돌아보니, 12명을 전부 관리하는 것이 쉽지 않았습니다. 우선 플레이어의 수가 늘어나면서 각 플레이어의 중요도는 반비례하여 낮아지게 되었고, 그 결과 일부 플레이어는 소외되거나 집중을 잃는 경우도 발생하게 되었습니다. 또한 호스트 입장에서 바라보았을 때도, 이전에는 몇 명과 인터뷰 하는것 만으로도 연합 관계나 게임의 전체적인 흐름을 파악할 수 있었지만, 이번에는 플레이어가 많아지면서 정보량이 기하급수적으로 늘어났고, 게임 흐름을 정리하고 파악하는데 난항을 겪었습니다.

앞으로도 만약 12명과 같이 많은 플레이어를 모아 게임을 진행하게 된다면 플레이어에게 동기부여를 줄 수 있는 수단을 제공하거나, 더 많은 호스트를 구하는 등의 조치가 필수적일 것입니다.

준비 일정

전체적인 일정전체적인 일정

다음에 또 오프라인을 운영할 때 참고하기 위해 준비 과정도 간단하게 정리해보았습니다. 준비 자체는 1월 1일부터 시작되었지만, 처음부터 많은 시간을 투자하지는 않았습니다. 메인매치와 데스매치의 큰 틀을 잡아놓고 밸런스를 잡으며 세부적인 룰을 수정하는 과정이 기간상 한달 정도 걸렸던 것 같습니다. 그 이후 게임 일주일 전부터 소품 준비, 장소 대여, 디스플레이 개발 등 전체 업무의 절반 이상을 처리하게 되었습니다.

참고로 참가자 모집 공고가 게임 기획보다 이전에 있는 것은 동기부여 때문입니다. 일단 사람을 모집해보고, 모이면 하고 안모이면 하지 말자는 생각으로 진행했습니다. 이렇게 하니 게임 제작이 힘들 때도 재밌게 즐겨줄 플레이어분들을 생각하면서 힘낼 수 있었습니다.

운영 비용 계산

게임 준비 및 운영에 사용된 비용을 모두 계산해 정리해보았습니다. 이는 앞으로 오프라인을 운영할 때 예산 계획을 세우고, 예상치 못한 비용 지출을 줄이기 위함입니다. 또한 향후 참가비 책정과 같은 예산 관련 쟁점이 발생했을 때 참고하려는 목적도 있습니다.

  1. 지출 (총 31800원)
  • 리갈패드 A5 노랑 1500원 * 12개 = 18000원
  • 명찰 종이 출력 7장 컬러 단면 300원 * 7개 = 2100원
  • 메인매치 룰지 12부 컬러 양면 600원 * 13개 = 7800원
  • 데스매치 룰지 12부 컬러 단면 300원 * 13개 = 3900원
  1. 수입 (총 40000원)
  • 플레이어 미참가로 인한 보증금 회수 20000원 * 2명 = 40000원

지출 31800원, 수입 40000원으로 총 8200원의 수입을 냈습니다.

플레이어 후기 및 앞으로의 계획

  • 게임 규칙의 타당성 및 만족도: 4.9/5
  • 호스트의 진행 능력과 게임 진행 속도: 5/5
  • 제공된 물품들의 만족도(노트, 필기구, 화면 UI 등): 5/5

플레이어 한줄평플레이어 한줄평

이번 게임을 준비하면서, 저번에 아쉬웠던 점들을 보완하기 위해 데스매치를 추가로 제작하거나 참여 플레이어 수를 늘리는 등 다양한 새로운 시도를 해보았습니다. 플레이어분들이 저희가 만든 게임에 몰입하여 전략을 세우는 모습을 지켜보며 큰 보람과 성취감을 느낄 수 있었습니다.

하지만 몇몇 플레이어 분들이 지적해주신 것처럼 많은 인원수로 인한 집중력 감소나 메인매치의 단조로운 규칙 등 여전히 해결해야 할 과제도 남아있다는 것을 느꼈습니다. 또한, 단순히 우승이라는 타이틀뿐만 아니라 상금이나 상품 같은 실물 보상이 주어진다면 게임의 긴장감과 흥미가 더욱 높아질 것 같다는 생각도 들었습니다. 앞으로도 다양한 도전을 이어가며 한층 더 업그레이드된 더 지니어스 in CLS로 돌아오겠습니다.

그럼, 다음 게임에서 뵙겠습니다.

© 2025 geniusLHS. All rights reserved.