어쩌다 보니 한 달 치 분량을 몰아 쓰게 되었다.
처음 배우는 거다 보니 프로젝트 진행 속도가 필요한 기능의 난이도에 따라 천차만별이었고,
회의 날짜가 고정되지 않아서 주마다 이렇다 할 끝맺음을 짓지 못했던 게 원인이었다.
일단 약 한 달 정도 진행된 지금까지의 진행 상황을 적어본다.
우선 팀원 세 명 중 두 분이 각각 플레이어와 인벤토리의 구현을 맡아 주셨고,
나는 아이템 구현에 집중하기로 했다.
1. 아이템 - “큐브” 구현
이 게임에서 가장 핵심이 되는 아이템, “큐브”이다.
현재의 큐브는 총 네 가지 색깔과 그에 따른 능력치를 갖는데,
- 빨간색 큐브 : Health + 3
- 보라색 큐브 : Movement Speed + 2
- 노란색 큐브 : Defense + 2
- 초록색 큐브 : Attack Power + 3
이다. 플레이어가 가지고 있는 능력치는 위 네 가지가 전부이고, 나중에 확장할 것이다.
큐브 프리펩이 가지는 컴포넌트들이다.
- 다른 물체들과 충돌하기 위해
Box Collider추가 - 플레이어가 근접했을 때 줍는 기능을 위해 큐브를 크게 둘러싸는
Sphere Collider추가 - 큐브가 부서질 때 나는 소리를 넣기 위해
Audio Source추가 - 큐브의 hp, 능력치 등의 데이터와 각종 기능을 추가하기위해
Script추가 - 큐브의 색깔을 16진수 코드로 관리하기 위한
Material/Shader추가
HexCode표 보기
R,G,B 각각 0~255(16진수 2자리)로, 6자리 숫자로 색깔을 표현한다.
큐브는 총알에 맞고 데미지를 입으면 작은 아이템이 된다.
그리고 플레이어가 가까이 가서 줍기 (Z키)를 누르면 인벤토리에 들어간다.
이 간단한 아이템 하나를 만드는 데 2주나 쓰다니. 인생이 참 쓰다.
2. 아이템 - 총 구현
총은 게임에서 워낙 자주 쓰이는 무기다 보니, 에셋도 구하기 쉽고 스크립트도 참고 서적의 내용에서 거의 수정할 게 없었다.
Ready(발사 준비)/Empty(총알이 비어있음)/Reloading(재장전중) 세 가지 상태를 가지고 있고,
총의 종류의 확장성을 위해 데이터를 ScriptableObject로 관리했다.
바라보는 방향으로 총알을 발사하기 위해, 1인칭 카메라의 cameraTransform을 변수로 갖고 있게 해주었다.
에셋은 opengameart 사이트에서 CC0(사용에 제한이 없는 무료 저작물)인 텍스쳐, 사운드 파일을 쉽게 구할 수 있었다.
총이 잘 안 보여서 잠시 손에서 총을 멀리 떨어뜨려 놓았다.
총알이 총구가 아닌 몸쪽에서 발사되는 이유는 아래에 나와 있다.
구현하면서 힘들었던 점
큐브
메이플스토리나 마인크래프트처럼, 큐브가 부서진 후 아이템이 되었을 때 캐릭터가 아이템을 통과하게 만들고 싶었다. 그런데 Item-Player 간의 Layer Collision Matrix를 꺼버리니, 두 오브젝트가 상호작용을 안 하게 된다. 서로 존재하는지 인식 자체를 못하는 것이다. 그래서 아예 BoxCollider의 크기를 1/1000 크기로 아주 작게 만들어버렸다. 더 좋은 방법이 있을 텐데 아직 못 찾았다.
총
처음에는 총알이 정면으로 날아가지도 않았다.
총알 프리펩의 Z축 방향이 탄두 방향이 아닌 90도 꺾인 방향이었는데,
transform.forward 가 가리키는 방향이 Z축 방향인 것을 깨닫고 난 후에야 정면으로 날아갈 수 있었다.
그런데 또 문제가 있었다.
총알이 날아가는 방향이 문제였다.
손에 들려있는 총구에서부터 총이 바라보는 방향으로 총알이 발사되게 구현해놨는데,
정면의 크로스헤어를 향해 쏘면 총알이 오른손에서 바라보는 방향을 지나 왼쪽으로 날아가게 된다.
그래서 실제로는 총알이 눈앞의 한 점까지 가다가, 그 점에서부터 정면을 향해 날아가는 방식을 사용한다고 한다.
그런데 총알이 중간에 꺾이는 것을 구현하는 게 너무 어려웠다.
그래서 이렇게..
총알을 눈앞에 위치한 1인칭 카메라 위치에서 발사되게 한 후, 총구에서 화염 이펙트를 넣어주려고 한다.
이게 더 어색한가..?? 어떻게 해야 할 지 모르겠다. ㅠㅠ
느낀점
솔직히 유니티에 엄청난 벽을 느꼈다.
코딩을 처음 접하고 지금까지 집중적으로 연습했던 부분은 CP(Competitive Programming)였다.
즉, 주어진 문제를 혼자서, 제한된 시간 안에 얼마나 빨리 해결할 수 있는가 였다.
그런데 게임개발은 결이 다르다.
협업과 확장성을 위해 아주 사소한 부분까지 코드를 구조화하는 게 필수적이었고,
이 때문에 코드를 리팩토링하는 일이 너무 잦아서 프로젝트 진행 속도가 늦어졌다.
지금은 최적화보다는 일단 결과물을 뭐라도 만들어놓고 싶은데, PS하던 버릇 때문에 자꾸 그쪽에 눈길이 간다.
그리고 객체 지향적 코드가 익숙하지 않아서 팀원분들의 코드를 이해하는 데에 너무 오랜 시간이 걸리는 것 같다.
Inspector에 Object를 할당해 주지 않아서 생기는 간단한 에러를 잡는 데 한 시간씩 걸리는 일도 다반사였다.
한 달치 분량을 적었는데도 적을 내용이 그렇게 많지 않았다.
매일 한 건 아니었지만, 그래도 코딩이라면 자신 있다고 생각했는데.. 뭔가 내 코딩 인생을 송두리째 부정당하는 느낌이었다.
게임 개발자들은 다 신인가..? 여러분 존경합니다.