8월, 중간 보고

 

레퍼런스는 디아블로, 이스케이프 프롬 타르코프의 인벤토리 시스템으로 삼고 있다. 그 외에도 프로젝트 좀보이드. UI의 디자인은 Modern Minimalism 웹 디자인, 영상 "イワシがつちからはえてくるんだ"의 같은 작곡자 영상들, 톰 클랜시의 더 디비전을 참고하였다.

 

 

 

 

 아무래도 그림 자체는 잘 못 그리기 때문에 최소한의 리소스를 이용하는 것을 목적으로 한다. 다만, 아이템 칸을 차지하는 블록 시스템과 위의 컨셉과 어울릴지는 아직 미지수다. 우선 컨셉은 이러하나 추후 얼마든지 변경될 것이다.

 

• Item-Parser
  • 미구현
  • Bolt를 이용한 Prefab 불러오기 우선.
• Item pooling Manager
  • 생성 기능을 구현
  • 출납 기능을 구현
  • Try-catch 구문? | 예외 처리에 대해서는 아직 모른다.
  • Randomize? | 미구현
• Inventory Manager
  • 출납 기능을 구현
  • 예외 처리 미구현
• Item
  • ScriptableObject 상속 데이터를 클래스 멤버로 갖고 있음.
    하지만 접근 방식을 열어둬야 될지 모르겠음.
  • Inventory 상호작용 미구현.

 

 

 

 

 

 데이터 측면으로서의 시스템 구현은 임시적이나마 구현했다고 판단한다.

 

 instantiate으로 인한 지연을 완화하기 위해, 로딩 시점을 어디로 잡을지. 그리고 어느정도의 수량으로 초기 오브젝트 풀을 채워둘지와 같은 것들은 아직 미지의 영역이다. 또한 퍼포먼스, 코드 정리에 대해서는 후일 재고하기로 한다. 좀 더 진척이 된다면 오류가 생길 것은 당연하므로, 예외 처리에 대해서 공부는 그 기회를 살린다.

 

 그 외에도 모든 데이터가 Monobehaviour를 상속받은 오브젝트로 있을 이유는 없으니, 이 부분을 잘 활용할 수 있도록 궁리한다.

 

 

위에서 언급했던대로 아이템-인벤토리 상호작용이 당면한 문제다. 타르코프의 인벤토리와 흡사한 것 자체는 본의가 아니다.

 

 유니티 자체 기능, 9-slicing Sprites을 통해서 인벤토리 칸을 표현은 할 수 있었다. 하지만 이 기능은 인벤토리 칸 하나하나의 스프라이트에 접근하기 어렵지 않을까.

 그렇다면 수많은 칸들을 직접 깔면 되겠고, 이 자체는 상관은 없다. 다만 기존 스프라이트를 이용할 경우에는 붙어있는 칸들의 선이 굵어진다는 점이고, 새로운 스프라이트로 실험해보면 되겠지만..

 

 다시 생각해보면, 굳이 인벤토리 칸 하나하나에 접근할 필요가 있는지를 고민하게 된다. 단순히 덮어 씌우면 될 문제라고 판단한다. 아이템 하나를 표현하고 상호작용할 때, 어차피 외곽선과 배경색 같은 요소를 사용할 생각이었으므로.

 

 인벤토리에는 해당 아이템의 위치와 용량만을 담기로 한다. 인벤토리 파트에서 아이템은 격자형으로 고정되도록 한다.

 

---

 

또 다른 자문자답이다.

 

 여러 게임들을 하면서 느끼길, 윈도우 창과 똑같은 UI. 조절 가능한 UI 자체는 편하면서도 불편하기도 했다. 하지만 문제는 내가 구현 가능한가, 일 것이다. 솔직히 불안하지만, 어거지를 쓴다면 되기야 할 것이다. 그냥 패널에 넣어서 옮기기만 한다면 특별할 것도 없을 것이다. 그러나 이 자체로도 시간을 많이 잡아먹으리라 생각한다. 아무래도 시도해보지 않은 것이기도 하고, 감안할 것들이 많아진다.

 

 그러나 이러한 형태의 UI 구조는 동시에 여러 정보들을 읽어 들일 필요가 있을 때 필요한 것이 아닐까. 그런 부분에서 타르코프는 모호하긴 하다.

 

 그래서 지금 만들고 있는 게임에 윈도우 창을 상시 켜놓고, 주시할 상황이 필요할까. 좋을 것 같지만, 나중을 기약한다.

 

---

 

 오히려 난항인 부분은 메인 플레이 부분이다. Forgive Me Father나 둠을 보면서 느끼길, 2D 리소스로도 3D와 같은 공간감을 줄 수 있다는 것에는 확신은 했었다. 2.5D라 표현되는 작품들도 꽤 많다. 당장 기억에 나는 것만 하더라도 옥토패스 트래블러가 있다.

 

 다만, 그림에 자신이 없는지라 제약 또한 크기도 하다. 하지만 어차피 3D보다는 낫다.

 

 그러나 어디까지나 아이소매트리? 시점의 시뮬레이션을 기반으로 하려 한다. 복셀 또한 고려했었으나, 도트로 가면 오히려 문외한이 되므로 망설여진다. Teardown과 같은 물리 효과를 기대하는 바이지만, 복셀이라는 환경 기반으로 여기까지 가는 과정 자체가 문제다. 내겐 시간도, 돈도 그다지 많지 않다.

 

 또, 상용 게임으로 만들어 출시한다고 하더라도 기대가 크지 않은 것도 사실이다. 스팀 출시 비용이 100$여서 .. 패트리온과 itch.io을 고려하고 있으나 W-8BEN을 발급 받기 전에 게임부터 만드는 것이 무엇으로 보아도 최우선이다.

 

 난 내가 하고 싶은 게임을 만들고 싶은 거지, 프레젠테이션 하기 위해서 게임을 만들고자 생각한 적 따윈 단 한 번도 없다.

 

 그래서 원론으로 돌아가자면, 메인 플레이로 만들고자 하는 것은 세 가지다. 전투, NPC와의 상호작용, 그리고 제작.

 

 

 후자의 두 가지는 웬만하게 구상된 바가 있다. 그러나 전투는 그러한 것이 없다. 좀보이드의 전투는 원하는 바가 아니며, 타르코프 또한 그러하다. 두 게임의 공통점은 리얼리즘을 바탕이 될 터이나, 실제 플레이 경험은 불편하고 고통스럽다. 이것들이 말하는 바는 알겠고, 충분히 와닿는다.

 

 이 게임들은 동시에 파일럿이 뛰어나다면, 더욱 현명하게 대처할 수 있음을 주장하고 있을까? 그럴지도 모른다. 분명 숙련된 게이머들이 잘 헤쳐나가는 것도 맞다. 그러나 운적인 요소가 많이 된 두 게임이고, 로그라이크의 허무함까지 겸비한 게임이다. 그러나 위의 명제에서 가장 유명한 게임인 다크소울은 다른 감각이다.

 

 레벨 디자인이 고정된 게임이니, 이 게임들을 비교하는 건 육상 동물과 해상 동물을 비교하는 느낌이지만, 해보자면 이 게임들은 각자 주제나 테마도 다르고, 완결성이 있고 없음의 차이도 컸다. 좀보이드가 생의 우울함과 괴로움의 연속이라면, 타르코프는 긴장과 총성의 연속이다. 그에 비해서 소울본 시리즈에서 느낀 바는 탐험과 도전의 연속이라는 느낌이다.

 

 주요한 차이점은 내막이 있는 보스와 엔딩으로 향하는 환경 변화를 포함한 내러티브라 생각한다. 더불어 두 게임과는 다르게 소울본 시리즈는 비웃음이 섞일지언정 실패와 도전을 격려하고 있지 않던가. 실로 도전 외에 아무것도 없기 떄문이다. 타르코프와 좀보이드는 도망칠 구멍이 있다. 숨고 기어다니며, 낮은 리스크만큼 낮은 보상은 얻을 수 있으니.

 

 그러면 운 요소를 매 시도마다 조정할 수 있고, 더불어 세이브 - 로드까지 지원한다면 어떨까. 그저 진부한 노가다의 연속이 될지도 모른다. 이런 관점으로부터 이탈하기 위해서 Hades에서의 스토리 진행 같은 요소가 의미가 있을지도 모른다. 근데 하데스는 리스크 자체가 없기 보다는, 공 들인 탑이 어찌됐던 무너질 뿐이 아닐까. 오히려 이런 점이야말로 로그라이크에 가까울지도 모른다.

 

 몇 가지 상정으로, 3인칭에서 1인칭으로의 전환이나 톱다운 뷰 슈터. 그 외에는 .. 턴제 장르. 세 가지 외에 떠오르는 건 딱히 없다. 앞서 아이소매트리라 했으니, 그에 맞추기로 한다.

 

---

 

• 인벤토리 구조 완성
• 인벤토리-아이템 상호작용 완성
• 가방 아이템 구현

 

• 아이소매트리 초안 / 찾아보기
• 다이얼로그 시스템 재구성

https://youtu.be/DiCIdJOUVPI