[멈춰 충동적 행동] 전투 시스템 구현을 위한 커밋 시작

지금 화면에서 체크인(커밋)하는 방법

아래 3단계만 그대로 따라하시면 됩니다.

1. 체크인 할 파일 선택하기

'추가된 비공개 항목' 리스트에 있는 파일들이 바로 새로 추가된 폰트 에셋들입니다. 이 파일들을 서버에 올리려면 먼저 체크박스를 클릭해서 선택해야 합니다.

• 전부 다 올리려면: '추가된 비공개 항목' 이라고 쓰여진 글자 앞의 네모난 체크박스를 클릭해서 66개 항목을 전부 선택하세요.
• 일부만 올리려면: 올리고 싶은 파일들만 개별적으로 체크박스를 클릭하세요.

체크를 하면 '비공개' 상태였던 파일들이 '추가됨' 상태로 바뀔 겁니다.

2. 체크인 코멘트(메모) 작성하기

왼쪽 아래에 있는 "여기에 체크인 코멘트 입력" 이라고 쓰인 칸에 작업 내용을 간단하게 적어주세요. 나중에 봐도 알 수 있게요!

• 예시: 메이플스토리 폰트 에셋 추가

3. '체크인' 버튼 누르기

코멘트까지 작성했다면, 바로 옆에 있는 '체크인' 버튼을 누르면 모든 과정이 끝납니다!

버튼을 누르고 잠시 기다리면 선택했던 파일들이 모두 클라우드 서버로 올라가고, '대기 중인 변경사항' 목록은 깨끗하게 비워질 겁니다.

 

 

 

 

 

저장방법에 대해

'데이터베이스' 같은 어려운 거 전혀 몰라도 JSON만으로 충분히 가능합니다.

---

요리책과 나만의 노트, 두 권의 책을 상상해 보세요.

1. '게임 데이터' = 절대 변하지 않는 '요리책' 📖

• 게임에 들어가는 모든 카드의 정보, 몬스터의 능력치 같은 것은 **'요리책'**과 같습니다.
• 요리책에는 "김치찌개 레시피", "된장찌개 레시피"가 적혀있죠. 이 레시피 자체는 우리가 요리를 100번 해도 바뀌지 않습니다.
• 어떻게?
  • 개발자인 당신이 cards.json이라는 '요리책' 파일을 미리 만들어 게임에 넣어둡니다.
  • cards.json 안에는 이렇게 적혀있습니다: {"이름": "화염구", "효과": "3데미지 주기", "이미지": "fireball.png"}
  • 게임은 이 요리책을 읽기만 합니다. "아, '화염구'는 이런 카드구나." 하고 배우는 거죠.

2. '세이브 데이터' = 계속 쓰는 '나만의 노트' 📝

• 플레이어가 게임을 하면서 얻는 레벨, 골드, 내가 가진 카드 목록 같은 것은 **'나만의 노트'**와 같습니다.
• 이 노트에는 "오늘은 김치찌개 요리에 성공했다!", "내일은 된장찌개에 도전해야지." 하고 계속 새로운 내용이 적히죠. 내용이 계속 바뀝니다.
• 어떻게?
  • 플레이어가 게임을 하다가 끄려고 할 때, 게임은 이 '나만의 노트'를 작성합니다.
  • save.json이라는 '나만의 노트' 파일에 이렇게 적습니다: {"내 레벨": 5, "내 골드": 100, "내가 가진 카드": ["화염구", "얼음 화살"]}
  • 이 파일을 플레이어의 스마트폰 저장 공간 구석에 저장해 둡니다. (PlayerPrefs라는 작은 메모지 대신, 아예 노트 한 권을 통째로 저장하는 거죠.)

게임이 켜지고 꺼질 때 일어나는 일 (가장 중요!)

• 게임 시작할 때:
  1. 먼저 **'요리책(cards.json)'**을 쫙 펼쳐서 세상에 어떤 카드들이 있는지 공부합니다.
  2. 그다음, 스마트폰 구석에 내가 숨겨둔 **'나만의 노트(save.json)'**가 있는지 찾아봅니다.
  3. 노트를 찾으면, 그 내용을 읽고 "아! 내 레벨은 5였고, 가진 카드는 화염구랑 얼음 화살이었지!" 하고 그 상태 그대로 게임을 이어갑니다. (불러오기/로드)
  4. 노트가 없으면? "처음 시작하는구나!" 하고 레벨 1, 골드 0으로 시작합니다.
• 게임 종료할 때 (혹은 자동 저장 시):
  1. 플레이어가 열심히 게임해서 레벨 6이 되고, 골드 150을 벌었다고 칩시다.
  2. 게임은 기존의 '나만의 노트' 내용을 지우고, 새로운 내용으로 덮어씁니다.
  3. save.json 파일에 이렇게 새로 적습니다: {"내 레벨": 6, "내 골드": 150, "내가 가진 카드": ["화염구", "얼음 화살"]} (저장/세이브)

결론: 그래서 어떻게 JSON만으로 되는가?

1. **'요리책(원본 데이터)'**은 개발자가 미리 만들어 둔 JSON 파일을 게임이 그냥 읽기만 하는 것이고,
2. **'나만의 노트(세이브 데이터)'**는 플레이어의 상태를 담은 JSON 파일을 스마트폰에 통째로 썼다 지웠다(덮어쓰기) 하는 것입니다.

PlayerPrefs는 이 '나만의 노트'를 적기에는 너무 작은 '포스트잇 메모지' 같은 거라, 아예 save.json이라는 파일을 직접 만들어서 읽고 쓰는 방식을 사용하는 것뿐입니다.

 

 

 

 

 

 

 

 

 

1. JSON을 여러 개 만들면 느려지나요?

결론: 아니요, 오히려 더 빨라지고 똑똑해집니다.

하나의 거대한 JSON 파일은 **"모든 물건을 때려 넣은 하나의 큰 창고"**와 같습니다.
여러 개의 작은 JSON 파일은 **"주방용품", "운동기구", "책"처럼 라벨이 붙은 여러 개의 작은 상자"**와 같습니다.

• 하나의 큰 창고 (거대 JSON 1개):
  • 내가 지금 당장 '골드' 정보만 필요한데도, 이 창고 전체를 뒤져야 합니다. (파일 전체를 읽고 분석해야 함)
  • 창고에 물건이 많아질수록(데이터가 쌓일수록) '골드' 하나 찾는데 점점 더 오랜 시간이 걸립니다. 이게 바로 앱이 느려지는 원인입니다.
• 여러 개의 작은 상자 (JSON 파일 분리):
  • '골드' 정보가 필요하면, 나는 "플레이어 정보"라고 쓰인 상자만 열어보면 됩니다. 다른 상자들은 건드릴 필요도 없습니다.
  • 훨씬 빠르고 효율적이죠.

따라서 **"플레이어 UI(골드, 스탯) JSON"**과 **"전투 시스템(보유 카드 덱 등) JSON"**을 나누려는 생각은, 의미 없는 일이 아니라 아주 좋은 생각이고 전문적인 관리 방식입니다.

---

2. 두 개의 JSON을 만들어도 되나요?

네, 당연히 괜찮습니다! 2개가 아니라 10개를 만들어도 됩니다.
위에서 설명한 것처럼, 데이터의 '종류'에 따라 파일을 나누는 것은 성능과 관리를 위해 적극적으로 권장되는 방법입니다.

• player_info.json (레벨, 골드, 스탯 등 자주 변하고 가벼운 정보)
• player_inventory.json (보유 카드, 아이템 목록 등 양이 많아질 수 있는 정보)
• game_settings.json (사운드 볼륨, 언어 등 환경 설정 정보)

이렇게 나누면 각자의 역할이 분명해져서 관리하기가 훨씬 편해집니다.

 

 

 

방법 A: 데이터를 '스크립트 코드' 안에 직접 썼을 때

유니티 어딘가에 이런 C# 스크립트가 있을 겁니다.

CardDatabase.cs

codeC#

 

public class CardDatabase
{
    // 카드의 정보를 코드 안에 직접 정의
    public Card Fireball = new Card("화염구", 3, "적에게 데미지를 줍니다.");
    public Card IceArrow = new Card("얼음화살", 2, "적을 얼립니다.");
    // ... 카드 100개가 이렇게 코드 안에 있음 ...
}

"화염구 데미지를 4로 바꾸려면" 해야 하는 일:

1. Visual Studio 같은 코드 편집 프로그램을 켭니다.
2. CardDatabase.cs 스크립트 파일을 엽니다.
3. new Card("화염구", 3, ...) 부분을 찾아서 new Card("화염구", 4, ...)로 코드를 직접 수정합니다.
4. 파일을 저장합니다.
5. 유니티 에디터로 돌아가면, 스크립트가 바뀌었기 때문에 **'컴파일(Compile)'**이라는 재조립 과정을 기다려야 합니다. (프로젝트가 크면 몇 초에서 몇 분까지 걸림)
6. 게임을 **'빌드(Build)'**해서 새로운 앱 설치 파일(.apk)을 만들어야만 수정된 내용이 최종적으로 반영됩니다.

문제점: 아주 작은 숫자 하나 바꾸는데도, 프로그래밍 도구를 열고, 코드를 건드리고, 컴파일과 빌드라는 무거운 과정을 거쳐야 합니다.

---

방법 B: 데이터를 'JSON 파일'로 분리했을 때

유니티 프로젝트의 Assets 폴더 어딘가에 이런 JSON 파일이 있습니다.

cards.json

codeJSON

 

[
  {
    "name": "화염구",
    "damage": 3,
    "description": "적에게 데미지를 줍니다."
  },
  {
    "name": "얼음화살",
    "damage": 2,
    "description": "적을 얼립니다."
  }
]

"화염구 데미지를 4로 바꾸려면" 해야 하는 일:

1. 메모장, VS Code 같은 아무 텍스트 편집 프로그램을 켭니다. (프로그래밍 도구가 아니어도 됨)
2. cards.json 파일을 엽니다.
3. "damage": 3, 부분을 찾아서 "damage": 4,로 텍스트를 수정합니다.
4. 파일을 저장합니다.
5. 끝.

이게 전부입니다!

유니티 에디터에서 게임을 바로 실행하면, 코드는 그대로지만 게임 시작 시 cards.json이라는 **'텍스트 파일'**을 새로 읽어오기 때문에 즉시 데미지가 4로 적용됩니다. 코드를 단 한 줄도 건드리지 않았으므로 '컴파일'이나 '빌드' 과정이 전혀 필요 없습니다.

핵심 비유 정리

• 코드에 데이터를 넣는 것 = 자동차의 '엔진' 설계도 자체를 바꾸는 것
  • 엔진 출력을 조금 바꾸려고 해도, 설계도를 고치고, 부품을 새로 만들고, 엔진 전체를 다시 조립해야 합니다. 매우 복잡하고 위험한 일입니다.
• JSON으로 데이터를 빼는 것 = 자동차의 '주유구'에 다른 기름을 넣는 것
  • 자동차(코드)는 그대로 두고, 에너지원(데이터)만 '일반 휘발유'에서 '고급 휘발유'로 바꾸는 것과 같습니다. 엔진을 뜯을 필요 없이, 주유만 새로 하면 차의 성능이 바로 달라집니다.

 

 

 

1. 빌드의 어려움 & "읽을 데이터가 추가되니 안 좋은 거 아닌가?"

"다시 빌드하는 것 빼고는 큰 어려움인지 모르겠다"는 말은, 지금처럼 혼자서 작은 프로젝트를 할 때는 전적으로 맞는 말입니다. 불편하긴 해도 감수할 만하죠.

하지만 이 방식의 진짜 가치는 **'협업'**과 **'유지보수'**에서 드러납니다.
만약 당신이 코드를 짜는 '개발자'이고, 게임의 재미를 조절하는 '기획자'가 따로 있다고 상상해 보세요.

기획자: "유저들이 '화염구'를 너무 안 쓰네요. 데미지를 3에서 5로 올리고, 코스트는 1로 낮춰서 테스트해보고 싶어요."

• 스크립트 방식: 개발자가 코드를 열어서 수정하고, 컴파일하고, 새 빌드를 만들어서 기획자에게 전달해야 합니다. 기획자는 이 간단한 테스트를 위해 개발자의 시간을 뺏어야만 합니다.
• JSON 방식: 개발자는 "여기 cards.json 파일 여시고, '화염구' 찾아서 damage랑 cost 숫자만 바꾸고 게임 켜보세요" 라고 말하면 끝입니다. 기획자는 개발자를 전혀 귀찮게 하지 않고도 수십 번의 밸런스 테스트를 혼자서 할 수 있습니다.

"휴대폰이 읽어야 할 데이터가 추가되니 안 좋은 거 아닌가?"
이것은 매우 합리적인 걱정입니다. 하지만 실제로는 전혀 그렇지 않습니다.

핵심은 "언제, 어떻게 읽는가" 입니다.

• JSON 파일은 게임 로딩 시 단 한 번만 읽어서 메모리(RAM, '작업대' 같은 공간)에 올려둡니다.
• 요리사가 요리를 시작하기 전에 '요리책'을 한 번 쫙 펴서 작업대 위에 올려두는 것과 같습니다.
• 요리하는 동안에는 이미 펼쳐놓은 작업대의 레시피를 보는 것이지, 창고에 있는 요리책을 계속 들락날락하며 읽지 않습니다.
• 현대 스마트폰에게 몇십 킬로바이트(KB)짜리 텍스트 파일을 읽는 것은 눈 깜빡하는 것보다 훨씬 빠른, 0.001초도 안 걸리는 작업입니다. 성능에 미치는 영향은 0에 수렴합니다.

---