오늘은 역할분담이 완료되었으므로, 개인적인 RnD를 진행한다

장르 가이드

• 이미 탄막 슈팅 게임으로 프로젝트의 방향성이 정해져 있지만, 다른 게임들과 같이 어떤 식으로 프로젝트를 진행해야 할 지에 대한 가이드를 알아본다

---

탄막 슈팅

특징

단순한 조작감. 고난이도의 회피. 지속적인 일방향 공격을 통한 액션 중심의 게임
패턴 설계. 점진적 난이도 조절이 필요

프로그래밍 적으로는 물리처리가 중요한 게임이다

레퍼런스

• SkyForce Reloaded

• 1945

• 드래곤 플라이트

• 니어: 오토마타(3D 환경 탄막)

• 엔터더건전(로그라이크를 접목할 수도 있다)

• 브롤스타즈(멀티 배틀로얄 탄막)

필수구현 기능

• 플레이어
  이동, 공격이 기본 시스템. 추가적으로 회피, 스킬, 아이템 사용 등을 고려할 수 있다. Transform 이동이 아니여야 한다. 유니티에서는 FixedUpdate와 Update의 Rigidbody 경우 서로 라이프사이클이 달라서 충돌 문제가 정확하지 않다. Rigidbody의 velocity를 통해 구현하는 것이 추천된다. AddForce의 경우 회피에 적합하지 않다. MoveTowards의 경우, 가속이 추가되기 때문에 게임의 컨셉에 따라 고려할 만 하다.

  물리 엔진 처리에서 Translate든 MoveTowards든 충돌의 범위가 일치할 필요가 있다.

• 몬스터 패턴
  두 가지 종류가 있다. 상태패턴으로 플레이어 인식해서 추적, 공격하는 몬스터가 있는 반면, 정해진 루트대로 이동하면서 정해진 패턴으로 공격하는 적도 있을 수 있다. 애니메이션으로 모든 행동을 정해놓는 것도 방법이다. 애니메이션으로 이동 경로를 짜고, 이동 경로를 움직이는 중에 Fire 함수를 수행하는 애니메이션 이벤트를 짜면 된다. 이 경우 애니메이션은 코드와 달리 수정하기도 쉽다. 코드로 경로를 짤 경우, 처음부터 다시 짜야 되지만, 애니메이션이면 녹화를 추가하면 될 뿐이다.

• 물리 충돌 처리
  Rigidbody로 이동하는 것이 중요하다. 충돌처리는 Update가 일치시킬 필요가 있다.
  레이저 공격의 경우, Fire와 동시에 Trigger 충돌체를 경로상에 생성해서 해당 충돌체에 검출된 collider(적)들을 피격 시키는 것도 방법이다.

• 아이템

• 스테이지

• 점수

도전

• 플레이어 기믹
  • 차지공격, 스킬 등
• 회피 패턴
• 보스 : 몬스터 패턴을 노가다로 작업하는 걸로 구현한다. 본인의 정해진 패턴을 시간 순서대로 계속 반복할 뿐이다. 페이즈가 존재할 수 있다. 페이즈마다 다른 패턴을 적용시키면 된다.
  
  상태 패턴에서 Pattern A, Pattern B... 등등으로 상태를 만들고, 해당 상태들을 순환 또는 랜덤으로 계속 패턴들을 반복한다. 패턴에는 이동, 공격등이 포함되어 있다. 카메라 바깥으로 벗어나지 않기 위한 알고리즘 작성이 필요. 해당 부분의 레퍼런스는 1945 III의 보스들을 참고하자

---

로그라이크

특징

• 무작위(랜덤) 요소 :
• 반복적인 게임 경험 :
• 영구적인 죽음 :

레퍼런스

• 탕탕특공대
• 아이작
• 던그리드
• 리스크 오브 레인 2(3D)
• 발라트로(UI를 기반으로 한 조작)

기능구현 리스트

• 캐릭터

  • RND 안됨. 기획에 따라 천차만별임. rigidbody,collider 부착.
  • 만약, 3D 환경의 로그라이크면 유니티의 Character Controller를 사용하는것을 추천함.
  • 발라트로와 같은 로그라이크의 경우, 이전의 특강 내용(Point Handler)를 사용하면 됨
  • 가속도를 가지며 종단속도도 있는 이동의 경우 MoveTowards를 쓰는 것이 좋음. 입력을 멈춰도 가속도를 가지며 멈춤(미끄러지며)

• 몬스터 AI
  스스로 움직이는 몬스터 구현 필요.

  • 경로탐색 : 추적의 경우 3D면 NavMesh, 2D면 A* 알고리즘을 추천한다.
  • 상태머신 : 유한상태머신(FSM)을 통해서 구현하는 것을 추천함. 아이들, 추적, 공격 상태 등
  • 프리팹으로

• 재화/ 성장 : DontDestroyOnLoad를 통해 어느 씬을 가도 파괴되지 않게 함. 싱글톤을 통해 참조하는 식으로 구현 가능.
  타이틀 씬에서 게임 시작을 눌렀을 때, 초기 값을 세팅하는 경우에서 싱글톤에 있는 데이터들을 초기값으로 세팅해주는 리셋 데이터 기능이 필요.

• 스테이지(랜덤)

  • 스테이지가 랜덤 : 게임 Skull을 레퍼런스로 볼 수 있다. 스테이지를 여러개 준비 해두고, 랜덤으로 스테이지를 로드 하는 식으로 구현할 수 있음. 절차적 맵 생성 알고리즘이 아님. 맵 풀로 맵들을 저장해두고 그 중 하나를 선택해서 로딩함.
  • 맵 자체가 랜덤 : 시드 시스템을 통해 랜덤으로 절차적 맵 생성 알고리즘을 통해 레벨을 생성함.

• 반복 요소

  • 죽음 후 재시작
    
    리셋을 하면서 초기값으로 세팅 필요. 플로우를 구상할 필요가 있음.
    

도전

• 무기 / 상점 : 재화를 통해서 구매 (소비시스템)
• 절차적 맵 생성 알고리즘
  • BSP 알고리즘 : 스프레드 식으로 방을 흩뿌린 다음, 각 방을 통로로 연결하는 식으로 구현하는 알고리즘. 엔터더건전이 레퍼런스.
  • 엘러 알고리즘 : 미로 알고리즘. 아이작과 같은 통로가 없는 랜덤 맵 생성 게임을 만들 때 사용할 수 있는 알고리즘이다.
• 어빌리티 기능(죽음 이후 모인 재화/레벨을 통해 성장)

---

서바이벌

특징

• 자원관리
• 생존전략
• 환경적응

스스로 목표를 세우고, 살아남는 것 자체가 목적인 게임

레퍼런스

• 좀보이드
• 돈스타브
• 마인크래프트

필수구현 기능

• 플레이어 생존

  • 체력, 갈증, 허기, 공포 등의 수치. 싱글톤으로 관리

• 도구

  • 다음 단계가 언락되는 방식. 스킬이 언락되는 것과 비슷하다.
  • 삽, 도끼, 낫 등의 들고 다니는 도구
  • 생존에 도움이 될 수 있는 것들을 제작하는 경우
  • 총, 검과 같은 무기 개념도 가능
  • 곡괭이는 돌과는 상호작용 가능. 하지만, 나무랑은 상호작용 불가능. 상호작용 가능 여부가 결정이 되어 있다. 오브젝트 기준으로 레이어를 통해 상호작용 여부를 결정할 수 있다. 나무의 경우 도끼 레이어만 상호작용 가능. 몬스터의 경우 도끼, 총, 검 레이어에만 상호작용 가능 등

• 제작

  • 원재료를 특정 조건의 절차를 걸쳐서 도구와 같은 새로운 아이템을 만드는 과정이다.
  • 도구를 제작한다. 재료를 필요로 함. 돌, 나무 등. 조합이 제작의 방식이 될 수 있다
  • 파밍 -> 재료 -> 제작 -> 도구 순으로 워크 플로우가 구성될 수 있다.
  • 시간이라는 변수가 들어갈 수 있음. 제작 단계에서 습득, 조합 등 여러 방법을 통해서 구현할 수 있음
  • 개발 방법
    • 1. 하드코딩 : 모든 조합법을 전부 훑어보는 식으로 코딩하는 것이 가장 빠른 구현 방법이다. 하드코딩이지만, 개발하기에는 용이하다
    • 2. 해싱 : 아이템들을 각각 고유의 ID를 부여한다. 딕셔너리를 통해 가장 낮은 조합 원재료 아이템 ID 번호를 기준으로 조합법을 탐색한다. 최대 8개의 아이템까지만 조합으로 사용된다고 가정할 때, 각 자리에 4자릿수의 숫자를 넣는다. int의 길이를 상정해서 8개다. 낮은 숫자 순으로 정렬 후, 해당 키 값을 딕셔너리에 넣으면 해당 조합 완성 아이템이 나오는 식으로 구현 가능.
    • 3. string은 무적이다 : "나무, 돌", "나무, 돌X2" -> "곡괭이". 2번의 해싱 방법에서 숫자 ID 대신 string을 쓰는 것이다. Resources 폴더에서 찾아서 만들어주는 시스템을 생각해볼 수 있다.

기획과의 대화를 통해 오버 엔지니어링이 되지 않게 조심하자. 그냥 하드 코딩하는 것이 나을 수 있다

• 인벤토리
  • Scriptable Object를 사용하는 것을 추천함. 이전 특강을 참고. 3D 오브젝트를 2D 스프라이트로 변환하는 과정이 어려울 수 있음. ItemData를 구성하고, 이를 통해 불러오는 식으로 구현. 해당 ItemData 클래스에 3D 오브젝트 모델과 2D 스프라이트 이미지를 들고 있으면 된다.
  • 인벤토리의 UI를 구현하는 방식은 MVC, MVP 패턴을 적용
• 파밍
  • 여러 게임 아이템 오브젝트들이 흩뿌려져 있을 필요가 있음.
  • 많은 아이템 종류가 필요함
  • 수집 및 활용 시스템에 대한 구현이 필요함
  • 습득 : 다형성이 확보되어 있어야 함. 습득 시 다음 스테이지 해금, 사용, 습득 즉시 사용 등 여러가지 방식으로 상호작용이 이루어 질 수 있기 때문임. 모든 아이템이 인벤토리에 들어갈 수 있는 경우가 아닐 수 있음. 어댑터 패턴을 사용하는 것을 추천함. 같은 Use라는 인터페이스 함수를 사용하지만, 아이템마다 다른 방식을 적용시킬 수 있음. 다른 속성을 부여해줄 수 있음

---

방치형