플레이어와 스테이지가 완벽하지는 않아도 어느 정도 갖춰졌다고 하면, 자연히 '적'에 대한 설계도 필요해집니다. 캐릭터가 없이 진행되는 퍼즐 게임, 혹은 일부 횡스크롤 플랫포머나 어드벤처에서는 적이 등장하지 않긴 합니다. 다만 제가 만들고 있는 게임은 일반적인 횡스크롤 플랫포머, 즉 함정이나 지형물 그리고 적을 극복하면서 나아가는 구성이기 때문에 적을 필히 등장시킬 필요가 있었죠. 예를 들어 쿠파가 없는 마리오나 닥터 와일리가 없는 록맨을 떠올려보면 되겠습니다.
적들에 대한 설정은 앞에서 언급하긴 했지만, 좀 오래됐기 때문에 다시 간단하게 요약해보도록 하죠.
1) 차원의 경계를 붕괴시키고 있는 '뫼비우스'라는 존재들
2) 애셋을 빨리 만들어야 하는 사정상 조무래기들은 간단한 도형으로 만들었다.
3) 보스급은 좀 더 복잡한 모습을 하고 있다.
4) 이들은 차원의 경계를 붕괴시킨 뒤 세계를 재구축, 장악하려고 한다.
'제 13차원'이라는 제목만큼이나 중2병의 느낌이 풀풀 나는 설정에, 그나마도 폼나게 만들 만한 능력이 없기 때문에 흑역사로 길이길이 남을 건 확실합니다. 아마 오늘밤에도 이불이 남아나지 않을 정도로 걷어차지 않을까 싶고요.
어쨌든 이런 설정을 녹여낸 방식은 게임을 만들면서가 아닌, 만든 이후에 총평을 하면서 더 자세하게 말씀드릴 수 있을 것 같습니다. 소설을 읽기 전에, 작가가 의도한 바를 먼저 듣고 나서 읽으면 좀 김이 샐 수 있는 것과 비슷한 이치죠.
물론 그런 걸 걱정할 만한 모양새가 나올지 의문이긴 합니다만, 게임을 만들면서 대다수의 개발자들이 거쳐가야 하는 '적 캐릭터 만들기', 제가 어떻게 해서 만들어가고 있고 지금은 어떤 작업을 진행하고 있나 이야기해볼까 합니다.
게임만들기 기사 모아보기
ㄴ[게임만들기 ①] 1인 게임 개발에 한 번 도전해보았습니다 - 예고 및 기획 단계편
ㄴ[게임만들기 ②] 1인 게임 개발에 한 번 도전해보았습니다 - 캐릭터 디자인편
ㄴ[게임만들기 ③] 1인 게임 개발에 한 번 도전해보았습니다 - 중간 점검 및 기획 수정편
ㄴ[게임만들기 ④] 1인 게임 개발에 한 번 도전해보았습니다 - 배경 및 스테이지 설계편
ㄴ[게임만들기 ①] 1인 게임 개발에 한 번 도전해보았습니다 - 예고 및 기획 단계편
ㄴ[게임만들기 ②] 1인 게임 개발에 한 번 도전해보았습니다 - 캐릭터 디자인편
ㄴ[게임만들기 ③] 1인 게임 개발에 한 번 도전해보았습니다 - 중간 점검 및 기획 수정편
ㄴ[게임만들기 ④] 1인 게임 개발에 한 번 도전해보았습니다 - 배경 및 스테이지 설계편
■ 적 캐릭터 만들 때 필요한 것은? 애셋, 애니메이션, 스크립트
"적 캐릭터를 어떻게 해야 맛깔나게 만들 수 있을까?"
창작자라면 누구나 다 꿈꾸는 일입니다. 실제로 잘 만들어진 적 캐릭터는 모든 창작물에서 몰입감을 배가하는 요소 중 하나죠. 실제로 적 캐릭터를 어떤 식으로 만들어야 하나에 관련한 작법서도 나올 만큼, 적 혹은 악역 캐릭터는 창작물에서 중요한 한 축을 담당하고 있습니다.
다만 그 주제와 방법은 창작물 전반에 걸친 만큼, 게임 만들기에서 다루기엔 너무 포괄적이긴 합니다. 그리고 작품의 장르나 주제, 기법에 따라서도 다 달라지는 것이고요. 그런 작품 내외적인 부분까지 포괄해서 언급하는 개념이 아니라 순수하게 게임 플레이, 레벨 디자인에 관련되서 적 캐릭터를 어떻게 만들어갈지에 대해서 이야기하고자 합니다.
게임 플레이, 레벨 디자인 측면에서 보면 적 캐릭터에게 필요한 것은 크게 세 가지였습니다. 애셋, 애니메이션, 그리고 스크립트죠. 자연히 제가 하고 있는 작업도 이 세 가지의 초점이 맞춰진 채 진행이 되고 있습니다.
이 방식은 사실 개인 차가 있긴 하지만, 대략적으로 보면 캐릭터 기획, 디자인, 아트, 애셋 제작, 애니메이션 제작 및 스크립트 작성 이런 식으로 작업이 이루어집니다. 이 중에서 캐릭터 기획 및 디자인, 아트, 애셋에서 소요되는 시간을 최소화하기 위해서 최대한 단순하게 캐릭터를 디자인했다는 것을 지난 캐릭터 디자인편에서 설명 드린 바 있습니다.
그렇게 해서 만든 애셋들을 엔진으로 불러온 뒤에, 애니메이션을 만들어가는 작업을 거칩니다. 애니메이션은 처음에는 스프라이트 애니메이션을 생각했지만, 조금 더 시간을 절약할 수 있는 본 애니메이션을 선택했습니다. 이 본 애니메이션은 주인공인 채림의 애니메이션을 만들 때도 썼지만, 적 캐릭터를 만들 때에도 일부 개체를 제외하면 많이 사용했습니다. 이런 작업이 얼추 끝나고 나면, 어떤 조건에서 어떤 움직임을 취하도록 스크립트로 설정하는 작업이 이어졌죠.
이 내용들은 사실 캐릭터 디자인편, 그리고 중간점검 및 기획편에서 언급했던 부분들과 많이 겹쳐있긴 합니다. 적 캐릭터를 만들 때만 이렇게 만드는 것이 아니라, 캐릭터를 게임에 구현할 때 거쳐야 하는 공통적인 작업이기 때문이죠. 다만 디테일한 부분에서 조금 다른 데다가, 플레이어블 캐릭터를 만들 때와는 또 다른 것들을 고려해야 했기 때문에 그 부분을 좀 더 자세히 언급하겠습니다.
■ 본 애니메이션 제작, 그리고 난제 1: 인간형이 아닌 적은 어떤 식으로 움직일까?
앞서 언급한 것처럼 제가 캐릭터 애니메이션을 만들 때 주로 사용한 것은 본 애니메이션과 키 프레임 애니메이션입니다. 본 애니메이션은 말 그대로 스프라이트에 뼈대를 입히고, 그 뼈대를 움직이면서 애니메이션을 만들어가는 기법이죠. 중간점검 및 기획수정편에서 채림의 애니메이션을 만들 때 잠시 소개했지만, 다시 그 과정에 대해서 간단하게 소개하자면 이렇습니다.
우선 포토샵으로 스프라이트를 만든 뒤, 스프라이트를 png로 저장했습니다. 이때 유의할 점은 배경 레이어는 끈 상태에서 저장해야 한다는 점이죠. 그렇지 않으면 배경의 디폴트색이 통째로 이미지에 같이 저장이 되어버립니다.
스프라이트 이미지 크기는 512x512로 설정해둔 상태에서 저장했고, 예전에는 스프라이트마다 png를 따로 줘서 저장했지만 이번에는 각 파트를 따로 정렬해둔 파일 하나만을 저장해서 애셋 폴더로 옮겼습니다. 유니티 엔진 자체에서 스프라이트 에디터를 활용해서 각 파트별로 따로따로 스프라이트를 저장할 수 있기 때문이죠. 이때 인스펙터 창에서 우선 스프라이트 모드를 싱글에서 멀티플로 바꿔야 한다는 걸 깜빡하고 헤매긴 했지만, 어쨌든 이걸 활용해서 번거로운 작업을 좀 더 줄일 수 있었습니다.
그렇게 따로따로 나뉜 스프라이트들을 한 데 묶기 위해서 빈 오브젝트를 하나 만들고, 적 캐릭터의 이름을 집어넣어서 따로 구분해뒀습니다 그 아래에 스프라이트들을 다 모았습니다. 스프라이트 메시로 바꾸기에 앞서서 스프라이트 메시와 본을 구분하기 위해서 다시 빈 오브젝트를 만들고, 그 아래에 스프라이트를 모으는 식으로 짰죠.
그리고는 뼈대를 넣기 전에 뼈대들을 모아둘 폴더처럼 빈 오브젝트를 하나 만들고, 그 아래에다가 본들을 하나하나씩 추가해나갔습니다. 그리고 기존에 넣었던 스프라이트들을 스프라이트 메시로 변환해서 본에 바인드시키면 완성이지만, 한 가지 주의할 점이 있습니다. 본을 만들면서 스프라이트 메시를 붙이는 것이 아니라, 본을 만든 뒤에 마치 피규어나 혹은 미술에서 사용하는 뼈대 인형처럼 이음새를 움직여보고, 매끄럽게 잘 움직이나 확인하는 과정을 거쳐야 할 필요가 있다는 것이죠. 이유는 간단합니다. 한 번 바인딩을 하거나, 스프라이트 메시로 바꾼 뒤에는 원 위치나 각도를 수정하기가 어렵기 때문이죠.
실제로 제가 급해서 뼈대를 대강 만든 뒤에, 스프라이트 메시로 바꾼 것들을 바인딩했다가 의도한 대로 안 움직이자 처음부터 작업을 다시 했던 것이 한두 번이 아니었습니다. 특히나 뼈대를 설계할 때, 인체는 어느 정도 지식이 있지만 인체가 아닌 동물을 본땄을 경우에는 이런 일이 벌어질 수 있다는 것을 느꼈죠.
사람은 인체 구조에 대해서 아주 자세하지는 않더라도 본능적으로 알고 있고, 또 인체가 어떤 동작을 취할 때 어떤 식으로 움직이는지도 대강 알고 있습니다. 어떻게 표현해야 할지 모른다고 해도, 예시 그림 하나만 보면 대강 어떻게 만들어야 한다는 것은 알게 되죠. 예를 듣자면 걷는 모습이나, 달리는 모습을 표현하는 것이 그렇습니다.
하지만 이번에 만든 것 중에서는 벌을 단순화해서 만든 개체, 'B클라인'은 착오가 상당히 있었습니다. "벌이 어떻게 날더라?" 이런 난관에 봉착해버렸죠. 물론 문자 그대로의 의미가 아니라, "어떤 식으로 날갯짓을 표현해야 할까"가 더 정확한 표현일 겁니다. 공중으로 난다는 것 자체는 x축과 y축으로 나타낼 수 있지만, 그 날아다니는 것을 묘사하기 위해서 어떤 식으로 애니메이션을 만들어가야 할까 하는 문제가 발생해버린 것이죠.
뿐만 아니라 공격 패턴을 애니메이션으로 만들 때도 문제가 생겼습니다. 앞서 말한 것처럼 본을 대강 설계해서 스프라이트 메시를 바인딩했는데, 움직일 때마다 본과 스프라이트 메시가 왜곡되는 현상이 여러 건 발발했기 때문이죠. 그 이유는 정확히 파악하지 못하고 여러 번 시도하다가, 결국 Hierachy창에서 배열한 대로 본을 부모-자식 배열로 놓지 않고 따로 만들어둔 뒤에 Hierachy창에서 계층 순위만 바꾼 뒤에 스프라이트 메시를 적용하는 것으로 얼추 문제를 해결했습니다.
사실 본 애니메이션, 특히 2D 본 애니메이션은 이번에 처음 써보는 것이기 때문에 왜 이런 문제가 발생했나는 아직도 정확히 모릅니다. 다만 이 문제로 한 가지 알 수 있던 건, 본 애니메이션을 만들 때는 일단 뼈대를 다 만든 뒤에 구동을 해보고, 본이 왜곡되지 않나 혹은 각도대로 잘 움직이나 확인한 뒤에 스프라이트 메시를 바인딩하는 것이 좋다는 점이죠. 앞서 말씀드린 것처럼 스프라이트 메시는 본을 따라서 움직이는데, 단순히 움직이는 것뿐만 아니라 뼈대의 크기나 길이가 바뀌어버리면 따라서 크기와 길이가 바뀌어버리거든요.
인간형을 어느 정도 따오긴 했지만, 마찬가지로 인간이 아닌 '클라인봄'의 애니메이션을 만들 때는 다른 의미에서 문제가 있었습니다. 발은 인간형이기 때문에 걷기나 뛰기는 있는데, 양 팔이나 허리, 허벅지, 무릎, 정강이 같은 부위가 없어서 허공에 떠있는 발과 몸통만 갖고 자연스럽게 이 모션을 연출해야만 했기 때문이죠.
사실 엔진에서 본 애니메이션을 만드는 과정은 흔히 말하는 노가다, 즉 단순 반복 작업에 가깝습니다. 아마 클레이 애니메이션, 혹은 피규어 애니메이션을 떠올리면 편할 겁니다. 뼈대를 계속 움직이고, 녹화하면서 움직임을 만들어나가는 과정이죠. 그 동작의 흐름을 보면서 어색하면 수치를 조정하고, 키 프레임 중간중간에 새로운 동작을 삽입하거나 빼는 등 여러 가지 조정을 거치면서 완성이 되죠. 결론은 그런 식으로 계속 수정해서 클라인봄의 걷기 및 뛰는 애니메이션을 어찌저찌 만들기는 했지만, 좀 더 자연스럽게 만들려면 아직도 그 과정을 거쳐야 한다는 것이죠.
■ 애니메이터, 스크립트, 그리고 난제 2: 핵심은 알고리즘이었다
"문제는 알고리즘이다"
프로그래머들이 종종 프로그래밍에 대해서 언급할 때 자주 나오는 말이죠. 알고리즘을 사전적으로 정의하면 '수학적인 문제를 해결하거나 컴퓨터 프로세스를 완결하기 위해서 차례로 뒤따르는 단계의 집합'입니다. 즉 어떤 프로세스를 최종까지 진행하면서 단계별로 처한 상황이나 해당 단계로 넘어가기 위한 규칙 등을 파악하고 해결해나가는 것이라고 볼 수 있겠습니다.
사실 채림의 애니메이션을 작업하는 단계에서는 그냥 anim.SetBool("string", bool 타입 변수) 이런 것만 잘 쓰면 되지 않을까, 라고 막연히 생각했었습니다. 하지만 적 캐릭터는 그게 아니라는 것을 깨닫는 건 그리 오래 걸리지 않았습니다.
예전에 제가 사운드, 특수 효과 부분에서 게임을 하면서 그냥 지나칠 수 있는 부분도 개발자 입장에선 하나하나 만들어야 한다고 했었는데, 적 캐릭터를 만드는 과정도 똑같았습니다. 특정 상황에서 특정 동작을 취하게 하려면, 그 조건을 일일이 개발자가 입력해둬야 했던 것이죠. 그걸 간과하고 단순히 "이런 애니메이션이 필요하겠네?"라는 식으로 대강대강 하나씩 만들어갔기 때문에 앞으로 이걸 어떻게 연결해야 하나, 이 부분이 조금은 막연해졌습니다.
물론 그 연결고리를 어떤 식으로 만드는지는 대강은 알고 있습니다. 유니티 엔진 내에서 애니메이션을 만들게 되면, 애니메이터 창에 애니메이터가 생성이 되죠. 어느 한 애니메이션에서 다른 애니메이션으로 넘어갈 때는 트랜지션을 설정하고, 그 트랜지션이 일어나는 조건을 네 가지 타입(Float, Int, Bool, Trigger)으로 나타낼 수 있습니다. 그 조건에 대한 세부 설정은 스크립트에 코드를 짜넣어서 활용할 수 있고요.
그렇지만 그걸 어떤 방식으로 AI에게 설명해야 할까? 하는 질문이 남습니다. 이 부분이 프로그래밍을 공부한 사람과, 그렇지 않은 사람의 결정적인 차이일 겁니다. 저는 프로그래밍을 속성으로 6개월, 그마저도 사운드 및 그래픽, 2D 아트 등 여러 종목까지 같이 속성으로 하는 국가 교육을 받은 게 전부이기 때문에 이걸 어떤 식으로 짜야 하는지가 막막할 수밖에 없던 거죠.
그렇다고 누가 만들어주지는 않으니, 차근차근히 하나하나 설계를 해나갔습니다. 우선 알고리즘적으로 적 캐릭터의 움직임을 하나하나 체크해나간 것이죠. 일단 레퍼런스가 있고, 포지션 변화가 없이 고정된 자리에 있는 포탑부터 먼저 설계했습니다. 2D 횡스크롤 플랫포머를 보면 포탑들 중에는 땅에 숨어있다가, 플레이어가 어느 정도 거리에 다가오면 공격을 하고 거리가 멀어지면 공격을 멈추는 그런 종류들이 있습니다. 이게 제일 난관이고, 이 문제만 해결되면 다음 포탑은 순조롭게 만들 수 있을 거라고 생각해서 이 부분에 도전했죠.
일단 포탑에서 필요하다고 생각한 애니메이션은 얼추 맞췄습니다. 숨어있다가 공격하는 포탑들의 패턴을 곰곰히 생각하면 숨어있다가 -> 특정 범위에 적이 있으면 -> 공격 -> 특정 범위에 적이 계속 있으면 -> 공격 -> 없거나 죽으면 -> 공격을 안 함 -> 숨음 이런 패턴인 경우가 많았고, 여기에 맞춰서 필요한 애니메이션들을 구축했습니다. 숨어있을 때, 올라올 때, 공격, 이렇게 세 가지로 애니메이션을 만들어뒀죠.
그렇게 애니메이션을 만든 뒤에는, 애니메이터에서 트랜지션을 어떤 식으로 설정할까를 고민해야 했습니다. 앞서 유니티에서는 네 가지 타입으로 트랜지션을 만들 수 있다고 했는데, 그 각각의 타입을 모르는 분들을 위해서 간단히 말씀드리자면 Float과 Int는 숫자로 표현이 되는 데이터 타입이고, Bool은 참과 거짓, 즉 용어로 말하자면 True/False로 나타낼 수 있는 데이터 타입입니다. Trigger는 특정 조건이 발생했다, 라는 것을 뜻하는 타입이죠. 이런 것들을 활용해서 애니메이션이 특정 조건에 따라서 다른 애니메이션으로 전환이 되게끔 스크립트를 짜야 하는 일이 남은 것입니다.
이 부분은 사실 GucioDevs의 Unity 5 2D Platformer Tutorial 18, 19를 많이 참고했습니다. 영어로 설명하긴 하지만 포탑의 메커니즘이나, 코드에 대해서 간결하게 이야기해서 많은 도움이 됐거든요. 그 중에서 저는 포신을 좌우로 옮기는 것은 구현하지 않았기 때문에, 그것과 관련된 코드는 일부 편집을 했습니다.
그렇게 해서 특정 범위에 플레이어, 즉 채림이 들어오면 반응을 하도록 만드는 것까지는 구현을 했습니다. 그 과정에서 그간 잊고 있던 함수를 다시 떠올려야 했죠. x, y축 상에서 특정 오브젝트가 어떤 위치를 기준으로 어디에 와야, 혹은 몇을 뺀 거리에 와야 조건이 오는가? 이런 식으로 범위를 산출하는 식을 짜야 했거든요. 즉 함수의 이동 같은, 예전에 재수할 때 손을 뗀 이후로 다시는 쳐다보기도 싫은 그 개념을 상상하면서 공식을 짜야 했습니다.
이 구성이 완벽하지 않아서 지금은 포탑이 플레이어에게 반응은 하지만, 포탄은 쏘고 있지 않은 상태입니다. B클라인과 클라인봄은 유니티엔진 AI에 있는 NavMesh 기능을 예전에 배웠다가 까먹어서, 특정 구역을 왔다갔다 하는 구성을 미처 구현하고 있지 못하고 있죠.
어떻게 해야 적 캐릭터가 이렇게 움직일까? 하는 부분은 사실 플레이어블 캐릭터가 어떻게 움직이게 하는 것보다는 체감상 더 어려웠습니다. 플레이어블캐릭터는 GetButton 등으로 어떤 키를 쓰면 어떻게 움직인다, 라고 간단하게 정리할 수 있지만 적 캐릭터는 그렇진 않으니까요. 특정 범위를 산출한다고 하면 어떻게 해서 그 범위를 산출할 것이며, 또 어떤 지점을 왔다갔다해야 한다면 그 지점을 어떤 식으로 인식하게 할 것인가 등등 다양한 문제가 남습니다.
게다가 더 큰 문제는, 그걸 처리해주는 게 컴퓨터라는 것이죠. 사람은 그냥 뭉뚱그려서 설명해도 척하면 알아듣지만, 컴퓨터는 0과 1로 해석하니까요. 하나라도 불분명하거나 명확하지 않으면, 아예 이해를 못하는 것과 마찬가지인 셈입니다.
이걸 명확히 하기 위해서 알고리즘을 짜고, 그 알고리즘을 보면서 코드를 명확하게 짜나가는 과정을 앞으로 쭉 진행해야 될 것입니다. 사실 이 부분은 기획에서 어느 정도 했어야 하지만, 이런 간단한 것에서 설마 이런 게 필요하겠어? 라고 간과했기 때문에 그 부담을 지금 와서 떠안고 가는 셈이죠.
비교적 간단한 패턴을 보이는 일반 몹 제작도 이 정도인데, 보스 몹 제작은 어떻게 진행해야 할지 벌써부터 걱정이긴 합니다. 그래도 기본 이론 자체는 크게 다르지 않기에, 이 부분이 어느 정도 해결되면 어떻게든 되지 않을까, 하면서 작업을 계속 이어나갈 계획이죠.
일단 보스의 생명은 패턴이고, 그 패턴을 더 완벽하게 만들어내기 위해서는 알고리즘을 더 정교하게 설계할 필요가 있는 만큼 알고리즘에 관련된 설명이나, 설계 중 시행착오 과정은 그때 가서야 좀 더 자세히 말씀드릴 수 있지 않나 싶습니다. 그게 언제가 될지 말씀드리긴 어렵지만, 적어도 점차 2D 횡스크롤 플랫포머의 모습을 갖춰나가는 모습만큼은 꾸준히 보여드릴 수 있도록 계속 작업해나가겠습니다.
※그래서 요약하자면?
1) 적 캐릭터를 만들 때 창작자들은 어떻게 해야 멋있게 만들 수 있을까를 먼저 고민한다. 그렇지만 게임 플레이, 레벨 디자인 측면에서 볼 때 적 캐릭터를 만들 때 필요한 건 애셋, 애니메이션, 스크립트다.
2) 방식은 개인차가 있지만 캐릭터 기획 및 디자인, 아트, 애셋 제작, 애니메이션 제작, 스크립트 작성으로 작업이 이루어진다.
3) 제 13차원은 시간 절감을 위해서 최대한 단순하게 캐릭터를 디자인하고, 본 애니메이션을 채택했다. 적 캐릭터도 대부분 본 애니메이션을 활용했다.
4) 스프라이트를 만들 때 유의할 점은 배경은 알파값으로 남도록 해야 한다는 것. 그렇지 않으면 하얀 배경색이 파일에 남아있다. 유니티 엔진에서 스프라이트 에디터를 활용해서 나뉘어진 파트별로 따로 스프라이트를 저장할 수 있기 때문에 일일이 레이어를 정해서 png로 저장하는 수고는 덜 수 있다. 이때 인스펙터창의 스프라이트 모드를 싱글에서 멀티플로 바꾸어야 한다.
5) 본 애니메이션은 스프라이트를 그대로 본에 바인딩하는 것이 아니라, 스프라이트를 스프라이트 메시로 변환한 다음에 본에 바인딩한다. 유의할 점은 본의 길이나 크기 변화에 따라서 바인딩이 된 스프라이트 메시의 크기가 변해버리기 때문에, 본 단계에서 움직임이 자연스러운지, 특정 각도에서 왜곡이 일어나는지 여부를 체크를 마친 뒤에 스프라이트 메시를 바인딩하는 것이 좋다.
6) 사람은 인체 구조에 대해서는 이해도가 있지만, 인간 외의 생물체의 움직임을 구현하는 것은 상당히 어렵다. 예를 들어서 벌이 어떻게 날갯짓을 하면서 나는지 당장에 떠올리기가 어려운 것처럼. 그 외에 일부분이 인간형이지만 일부분이 인간형이 아니어도 애니메이션을 만들 때도 난관에 봉착할 수 있다.
7) 애니메이션은 단순 반복 작업에 가깝다. 계속 움직이고 녹화하고, 어색하게 느껴지면 수정하는 것이 반복된다.
8) 알고리즘은 프로그래밍에만 중요한 것이 아니다. 게임 전반에 중요하다.
9) 애니메이션에서도 중요하다. 애니메이션은 단순히 한 동작을 표현하기 위한 것이라면, 알고리즘은 그 동작에서 다른 동작으로 넘어가는 과정을 어떤 식으로 나타내야 할까? 하는 설계이기 때문이다.
10) 특히 적 캐릭터는 더 곤란한 것이, 플레이어블 캐릭터는 특정 키를 누르면 움직이고 특정 스킬을 쓴다는 것이 다수고, 어떤 상황에서 어떤 스킬을 쓸지는 플레이어가 판단해서 그 정해진 동작을 취한다. 그렇지만 적 캐릭터는 순전히 AI에 맡겨야 한다. 즉 AI에 맞게 그 조건을 전달해줘야만 인지하고 그에 맞게 행동한다.
11) 유니티 엔진에서 한 애니메이션에서 다른 애니메이션으로 전환할 때 사용되는 것이 트랜지션(Transition)이다. 트랜지션은 Float, Int, Bool, Trigger의 네 타입으로 나타낼 수 있으며, 그 세부 설정은 스크립트에 코드를 짜넣어서 활용할 수 있다.
12) 숨어있다가 플레이어를 공격하는 포탑의 패턴을 생각해보면, 숨어있다가 -> 특정 범위에 적이 있으면 -> 공격 -> 특정 범위에 적이 계속 있으면 -> 공격 -> 없거나 죽으면 -> 공격을 안 함 -> 숨음 이런 패턴이 많다. 여기에 필요한 애니메이션, 즉 숨어있을 때, 올라올 때, 공격 세 가지 애니메이션을 만들었다.
13) GucioDevs의 Unity 5 2D Platformer Tutorial 18, 19를 참고해서 코드를 짰다. 다만 이 예시에는 포신을 좌우로 움직이는 것까지 설명이 되어있는데, 그 부분은 제외하고 코드를 짰다.
14) 특정 범위에 적이 온다는 것을 계산할 때 프로그램이 쓰는 수식은 함수의 이동과 연관이 있다. 특정 지점을 기준으로 x, y축 상의 좌표를 빼거나 하는 식으로 산출하는 것이다. 이외에도 함수 등 수학적인 사고방식을 요구하는 것이 있다. 이 부분이 익숙하지 않은 데다가, 구성이 완벽하지 않아서 일부 기능은 완벽하게 구현하지 못했다.
15) 컴퓨터는 0, 1로만 대화한다는 말처럼 프로그램은 명확하지 않으면 이해를 못한다. 그렇게 명확하게 짜기 위해서는 알고리즘을 확실하게 짤 필요가 있다. 원래 이 과정은 기획에서 어느 정도 고려를 했어야 하지만, 설마 간단한 2D 횡스크롤 플랫포머에서 이런 게 필요할까 싶어서 간과했던 것이 지금 부메랑이 되어서 돌아왔다.
16) 패턴이 비교적 단순한 잡몹을 만드는 것도 이런데, 보스를 만드는 과정은 어떨지 짐작이 가지 않는다. 하지만 기본 이론은 비슷하기 때문에 이번 단계를 넘으면 어느 정도 설계가 가능할 것이라고 예상하고 있다. 2D 횡스크롤 플랫포머의 모습을 좀 더 갖춰나갈 수 있도록 작업을 계속 해나갈 예정이다.
2) 방식은 개인차가 있지만 캐릭터 기획 및 디자인, 아트, 애셋 제작, 애니메이션 제작, 스크립트 작성으로 작업이 이루어진다.
3) 제 13차원은 시간 절감을 위해서 최대한 단순하게 캐릭터를 디자인하고, 본 애니메이션을 채택했다. 적 캐릭터도 대부분 본 애니메이션을 활용했다.
4) 스프라이트를 만들 때 유의할 점은 배경은 알파값으로 남도록 해야 한다는 것. 그렇지 않으면 하얀 배경색이 파일에 남아있다. 유니티 엔진에서 스프라이트 에디터를 활용해서 나뉘어진 파트별로 따로 스프라이트를 저장할 수 있기 때문에 일일이 레이어를 정해서 png로 저장하는 수고는 덜 수 있다. 이때 인스펙터창의 스프라이트 모드를 싱글에서 멀티플로 바꾸어야 한다.
5) 본 애니메이션은 스프라이트를 그대로 본에 바인딩하는 것이 아니라, 스프라이트를 스프라이트 메시로 변환한 다음에 본에 바인딩한다. 유의할 점은 본의 길이나 크기 변화에 따라서 바인딩이 된 스프라이트 메시의 크기가 변해버리기 때문에, 본 단계에서 움직임이 자연스러운지, 특정 각도에서 왜곡이 일어나는지 여부를 체크를 마친 뒤에 스프라이트 메시를 바인딩하는 것이 좋다.
6) 사람은 인체 구조에 대해서는 이해도가 있지만, 인간 외의 생물체의 움직임을 구현하는 것은 상당히 어렵다. 예를 들어서 벌이 어떻게 날갯짓을 하면서 나는지 당장에 떠올리기가 어려운 것처럼. 그 외에 일부분이 인간형이지만 일부분이 인간형이 아니어도 애니메이션을 만들 때도 난관에 봉착할 수 있다.
7) 애니메이션은 단순 반복 작업에 가깝다. 계속 움직이고 녹화하고, 어색하게 느껴지면 수정하는 것이 반복된다.
8) 알고리즘은 프로그래밍에만 중요한 것이 아니다. 게임 전반에 중요하다.
9) 애니메이션에서도 중요하다. 애니메이션은 단순히 한 동작을 표현하기 위한 것이라면, 알고리즘은 그 동작에서 다른 동작으로 넘어가는 과정을 어떤 식으로 나타내야 할까? 하는 설계이기 때문이다.
10) 특히 적 캐릭터는 더 곤란한 것이, 플레이어블 캐릭터는 특정 키를 누르면 움직이고 특정 스킬을 쓴다는 것이 다수고, 어떤 상황에서 어떤 스킬을 쓸지는 플레이어가 판단해서 그 정해진 동작을 취한다. 그렇지만 적 캐릭터는 순전히 AI에 맡겨야 한다. 즉 AI에 맞게 그 조건을 전달해줘야만 인지하고 그에 맞게 행동한다.
11) 유니티 엔진에서 한 애니메이션에서 다른 애니메이션으로 전환할 때 사용되는 것이 트랜지션(Transition)이다. 트랜지션은 Float, Int, Bool, Trigger의 네 타입으로 나타낼 수 있으며, 그 세부 설정은 스크립트에 코드를 짜넣어서 활용할 수 있다.
12) 숨어있다가 플레이어를 공격하는 포탑의 패턴을 생각해보면, 숨어있다가 -> 특정 범위에 적이 있으면 -> 공격 -> 특정 범위에 적이 계속 있으면 -> 공격 -> 없거나 죽으면 -> 공격을 안 함 -> 숨음 이런 패턴이 많다. 여기에 필요한 애니메이션, 즉 숨어있을 때, 올라올 때, 공격 세 가지 애니메이션을 만들었다.
13) GucioDevs의 Unity 5 2D Platformer Tutorial 18, 19를 참고해서 코드를 짰다. 다만 이 예시에는 포신을 좌우로 움직이는 것까지 설명이 되어있는데, 그 부분은 제외하고 코드를 짰다.
14) 특정 범위에 적이 온다는 것을 계산할 때 프로그램이 쓰는 수식은 함수의 이동과 연관이 있다. 특정 지점을 기준으로 x, y축 상의 좌표를 빼거나 하는 식으로 산출하는 것이다. 이외에도 함수 등 수학적인 사고방식을 요구하는 것이 있다. 이 부분이 익숙하지 않은 데다가, 구성이 완벽하지 않아서 일부 기능은 완벽하게 구현하지 못했다.
15) 컴퓨터는 0, 1로만 대화한다는 말처럼 프로그램은 명확하지 않으면 이해를 못한다. 그렇게 명확하게 짜기 위해서는 알고리즘을 확실하게 짤 필요가 있다. 원래 이 과정은 기획에서 어느 정도 고려를 했어야 하지만, 설마 간단한 2D 횡스크롤 플랫포머에서 이런 게 필요할까 싶어서 간과했던 것이 지금 부메랑이 되어서 돌아왔다.
16) 패턴이 비교적 단순한 잡몹을 만드는 것도 이런데, 보스를 만드는 과정은 어떨지 짐작이 가지 않는다. 하지만 기본 이론은 비슷하기 때문에 이번 단계를 넘으면 어느 정도 설계가 가능할 것이라고 예상하고 있다. 2D 횡스크롤 플랫포머의 모습을 좀 더 갖춰나갈 수 있도록 작업을 계속 해나갈 예정이다.
Ruudi@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
