← PROJECT ARCHIVEGAME DEV

GAME DEV / 완료

따끈따끈 붕어빵

손님의 주문을 맞추며 작은 붕어빵 가게를 5일 동안 운영하는 2D 타이쿤 게임

밤의 붕어빵 가게와 주인공이 그려진 따끈따끈 붕어빵 대표 이미지PROJECT / BUNGEOPPANG-TYCOON
기간2025.05.04–2025.06.22
참여 인원1명
내 역할게임 기획 및 전체 클라이언트 개발
엔진Unity
플랫폼Windows

손님의 주문을 확인하고 반죽과 속재료를 조합해 붕어빵을 구운 뒤 제한 시간 안에 제공하는 2D 가게 경영 게임입니다.

매일 오후 6시부터 11시까지 가게를 운영하고 매출에서 재료비를 뺀 순이익을 정산합니다. 5일 동안 모은 금액과 운영 결과에 따라 파산, 일반, 성공의 세 가지 엔딩을 확인할 수 있습니다.

사용자가 실제로 경험하는 핵심 기능입니다.

01

단계별 붕어빵 조리

틀에 아래 반죽, 팥·슈크림·피자 중 선택한 속재료, 위 반죽을 순서대로 넣습니다. 알맞게 구운 붕어빵은 손님에게 전달하거나 진열대에 보관할 수 있고, 너무 오래 구우면 타버립니다.

02

손님 주문과 대기 시간

손님마다 붕어빵 종류와 수량이 무작위로 정해집니다. 기다리는 시간이 길어질수록 화남 수치가 올라가며, 주문을 모두 제공하기 전에 한계에 도달하면 손님이 떠납니다.

03

드래그 앤 드롭 상호작용

완성된 붕어빵을 마우스로 끌어 손님이나 진열대에 놓습니다. 주문 종류와 일치할 때만 판매가 처리되도록 조리 상태와 목적지를 함께 검사합니다.

04

5일 운영과 멀티 엔딩

영업 종료 후 판매 개수, 손님 수, 매출, 재료비와 순이익을 정산합니다. 5일째 보유 금액을 기준으로 세 가지 결말 중 하나를 보여줍니다.

담당 역할

  • 게임 기획 및 전체 클라이언트 개발
  • 조리·주문·손님 시스템
  • UI·일일 정산·멀티 엔딩

팀 구성

  • 개인 프로젝트
Unity 6000.0.39f1C#URP 2DUGUITextMeshPro

기능을 만들기 위해 직접 설계하고 구현한 기술 영역입니다.

01

조리 상태 머신

`FishBunController`에서 아래 반죽, 속재료, 위 반죽, 굽는 중, 완성 상태를 순서대로 관리합니다. 각 상태에서 가능한 클릭과 드래그 동작을 제한해 잘못된 조리 순서를 막았습니다.

02

주문 생성과 처리

`CustomerController`가 전체 주문 수를 속재료별 수량으로 나누어 저장합니다. 붕어빵을 전달할 때 주문과 조리 상태를 확인하고, 일치하면 남은 수량과 결제 금액, 판매 통계를 갱신합니다.

03

시간·날짜·경제 시스템

`GameManagerEx`가 영업 시간, 날짜, 보유 금액과 당일 판매 기록을 관리합니다. 영업 종료 시 매출과 재료비를 계산하고 정산 화면을 거쳐 다음 날 또는 엔딩으로 이동시킵니다.

04

공통 UI 프레임워크

UI 기본 클래스에서 버튼과 텍스트 같은 요소를 일관된 방식으로 연결합니다. 인트로, 상점, 게임, 정산, 엔딩 화면을 각각 분리해 게임 상태에 맞는 UI를 표시하도록 구성했습니다.

공통 매니저가 시간과 날짜, 경제 상태를 관리하고, 각 조리 도구와 손님은 자신의 상호작용을 담당하는 컴포넌트 구조입니다.

01

Presentation

  • 인트로, 상점, 플레이, 일일 정산, 엔딩 UI
  • 주문 말풍선과 시간·금액 표시
  • UGUI와 TextMeshPro 기반 화면 구성
02

Gameplay

  • 붕어빵 조리 상태와 굽기 시간
  • 손님 주문, 대기 시간과 화남 수치
  • 드래그 앤 드롭 판매와 진열
  • 붕어빵 틀과 조리 도구 상호작용
03

Core

  • `Managers` 공통 진입점
  • `GameManagerEx` 시간, 날짜, 경제 상태 관리
  • 씬과 UI 전환
04

Assets

  • 붕어빵, 손님, 조리 도구 프리팹
  • 화면과 엔딩 스프라이트
  • Resources 기반 에셋 로딩
01일일 정산 금액이 서로 맞지 않는 문제
문제

정산 화면의 매출, 재료비, 순이익과 다음 날에 반영되는 금액이 서로 다르게 계산됐습니다.

원인

판매 금액과 재료비를 계산하고 차감하는 시점이 나뉘어 있었고, 화면에서도 별도 계산을 사용했습니다.

해결

당일 매출, 재료비, 순이익을 각각 분리하고 영업 종료 처리에서 한 번만 계산하도록 모았습니다. 정산 UI는 계산된 값을 받아 표시하도록 변경했습니다.

결과

화면에 표시되는 정산 내역과 실제 보유 금액이 같은 계산 결과를 사용하도록 통일했습니다.

02주문 수량을 나누는 과정에서 0개가 생기는 문제
문제

여러 종류의 붕어빵 주문을 무작위로 만들 때 특정 종류의 수량이 0개가 되거나 남은 주문 수를 정상적으로 나누지 못하는 경우가 있었습니다.

원인

남은 수량을 기준으로 난수를 뽑는 범위가 너무 작아 경계값에서 유효한 주문 수량을 보장하지 못했습니다.

해결

남은 붕어빵 수를 기준으로 난수 범위를 다시 설정하고, 계산 결과가 0이면 최소 1개를 배정하도록 보정했습니다.

결과

생성된 주문에 실제로 요청하지 않는 종류가 포함되지 않고, 전체 주문 수가 각 속재료 주문에 정상적으로 분배되도록 개선했습니다.

기획부터 게임 로직과 UI까지 개인 프로젝트로 전체 제작조리, 주문, 판매, 정산이 이어지는 5일간의 완전한 플레이 흐름 구현운영 결과에 따른 파산, 일반, 성공의 3가지 엔딩 구현실제 플레이 과정을 확인할 수 있는 실행 영상 제작

잘된 점

  • 붕어빵의 조리 단계를 상태로 나누어 복잡한 클릭과 드래그 조건을 명확하게 관리했습니다.
  • 하루 영업과 정산, 다음 날, 엔딩까지 게임의 시작과 끝을 혼자 완성했습니다.
  • 손님 대기 시간과 재료비를 넣어 빠른 조리와 수익 관리가 함께 필요한 플레이를 만들었습니다.

아쉬운 점

  • 게임 상태와 화면 전환이 공통 매니저에 집중되어 기능이 커질수록 수정 범위가 넓어질 수 있습니다.
  • 가격과 조리 시간 같은 설정값이 코드 여러 곳에 있어 밸런스를 반복해서 조정하기 어렵습니다.

다시 만든다면

  • 가격, 조리 시간, 손님 성향을 ScriptableObject 데이터로 분리해 에디터에서 쉽게 조정하겠습니다.
  • 주문 생성과 일일 정산처럼 경계값 오류가 생기기 쉬운 규칙에는 자동화 테스트를 추가하겠습니다.
  • 게임 진행 상태와 UI 표시를 분리해 각 화면을 독립적으로 수정할 수 있게 구성하겠습니다.