들어가며
오랜만에 여유가 생겨 근 두 달 만에 글을 연다. 블로그에서 글을 쓰기 시작한 이래로 이렇게 길게 비워놓은 적이 손에 꼽는 것 같은데.. 오랜만에 쓰려니 어색하기도 하고 즐겁기도 하다.
글을 열면서 현업자 분들이랑 멘토링을 한 걸 적을지, 개인적으로 진행하던 프로젝트의 경과에 대해 적을지, 그것도 아니면 조금 더 구체화된 성장 방향에 대해 적을지 고민을 했는데, 이전의 기록들을 살펴보니 수확제(收穫祭)라는 좋은 콘텐츠를 만들어놓은 게 생각이 났다.
그래서, 오늘은 문을 열었던 지난 '수확제 : 개(開)'에 이어, '바로 서다.'라는 의미의 '수확제 : 입(立)'으로써 글을 작성해보려고 한다.
오늘은 오랜만에 글을 적는 것이기도 하니 가벼운 주제부터 시작해서 조금씩 깊이를 만드는 방식으로 글을 적어보려고 한다. 그럼 오늘 작성할 글의 목차를 살펴보도록 하자.
목차
- 독서 : 자유를 위한 기본
- 계획 : 책임을 통한 자유
- 학교 생활 : 내가 바라는 건 졸업, 졸업, 그리고 다시 한번 졸업!
- <Breath in Winter> 개발 : C++와 Blueprint 사이의 균형
- <Breath in Winter> 발표 : 도비는 자유예요!
- 우화 : 증명하는 디자인을 향해서
수확했습니다!
독서 : 자유를 위한 기본
첫 번째 항목은 '독서 : 자유를 위한 기본'이다. 솔직히 내가 독서를 많이 하는 편은 아니었다. 이전까지만 해도 1년에 3~4권 정도 읽는 편이었고 그마저도 <오브젝트>나 <Game Mechanics>와 같이 기술적인 부분에 치중된 책들이었다.
그런데, 이런 나도 종종 자기 계발서나 인문학 쪽 책을 읽는 때가 있는데, 바로 우울하고 공허할 때다. 가끔 공허함에 잠을 이루지 못할 때면 유튜브나 게임보다는 책이 끌린다. 모두가 잠들어있는 시간, 정적 속에서 홀로 소리 내어 책을 읽으며 서성이던 그 시간들이 나를 만들었다고 해도 과언이 아닐 거다.
아무튼 내가 왜 첫 번째 항목으로 독서를 선택했냐 묻는다면, 바로 독서가 경험치 버프라는 걸 깨달았기 때문이다.
언젠가 블로그에 분야를 가리지 않고 탐독을 해보겠다고 한 적이 있는 것 같은데, 실제로 해 본 결과 생각보다 훨씬 유익했다. 단순히 지식을 늘리는 것을 떠나 의식을 고양시키고 확장하는 느낌이라고 해야 할까?
이전에는 작은 창으로 세상을 바라봤다면 탐독 이후에는 보다 여유로운 마음으로 상황을 관조할 수 있게 된 것 같다. 나의 사고 모델 자체를 내 스스로 설계할 수 있게 됐고, 그 과정에서 나의 가장 큰 문제였던 조급함과 불안함을 크게 개선할 수 있었다.
그리고, 무엇보다 내가 품고 있는 고민들에 대한 선인들의 결론을 저렴한 가격에 살펴볼 수 있었다는 점이 가장 큰 것 같다.
올해 초, 내가 오랫동안 품고 있던 창작에 대한 고민이 이미 책에 결론이 내려진 걸 확인할 수 있었는데, 허무함과 동시에 머리가 명료해졌다. 이때부터 내가 하고 있는 모든 고민에 대해 책을 구매하고 관련된 칼럼들을 찾아 읽기 시작했는데 확실히 성장 속도가 이전보다 훨씬 빨라진 것 같다.
아직은 고집이 남아있어 의심하면서 읽기는 하는데 그래도 참고할 만한 자료가 있다는 점에서 고민에 어떤 식으로 접근해야 좋을지 알 수 있게 된 것 같다.
맨땅에 헤딩해 가며 직접 배우는 것도 좋지만, 나에게 주어진 시간과 자원은 한정적이기에 일단 계속 책을 읽으면서 시야를 넓히는 게 우선인 것 같다는 생각을 했다.
이를 통해 나는 보다 자유로운 사고를 하고, 보다 자유롭게 나의 세계관을 구축할 수 있을 거라고 기대한다. 아래에 그냥 범용적으로 읽기 좋은 책들을 소개하고 다음 항목으로 넘어가겠다.
계획 : 책임을 통한 자유
나는 올해 4월 들어서부터 계획을 세우지 않고, 그냥 하루하루를 살았다. 내가 계획 세우는 거에 미쳐있기는 한데, 여유를 잘 다루지는 못해서 꽉 차 있는 일정을 보면 만족스럽기도 하지만 한편으로는 부담스러웠기 때문이다.
더군다나 이때는 처음으로 언리얼 C++ 개발을 시작할 때라 뭘 어떻게 계획을 세워야 할지도 몰랐기에 단순히 '언리얼 개발'이라고 적어놓고 유야무야 넘어갔던 게 싫었다.
그래서, 그냥 스스로에게 여유를 주겠다는 걸 이유로 계획을 세우지 않았는데 늘 그렇듯 잘 되다가도 한 번 늘어지기 시작하면 주체 없이 늘어졌다.
그때 계획은 나한테 필수라는 생각을 했다. 더 잘하기 위해서가 아니라, 스스로 무너지려고 할 때 다시 일어설 지지대를 만들기 위해서 말이다. 그래서, 5월 중순에 들어서는 노션을 통해 타임박싱이라는 방법으로 간단하게만 할 일을 정리하고 계획을 세우고 있다.
이 과정에서 '나 사용 설명서'라는 그동안 어림 짐작했던 나의 생활 습관에 대한 규칙을 하나씩 정의하고 따르고 있는데 이 덕분에 불면증이 사라지고, 조금은 더 긴 하루를 살 수 있게 됐다.
솔직히 이전과는 달리 종이가 아니라 디지털로 작성하다 보니까 뭔가 계획을 세우는 맛이 없는데.. 이 부분은 조금 더 고민을 해봐야 될 것 같다.
일단은 의미 있는 활동이기도 하고, 성과도 톡톡히 느끼고 있어서 적어봤다.
학교 생활 : 내가 바라는 건 졸업, 졸업, 그리고 다시 한번 졸업!
아.. 아는 사람은 알겠지만 나는 통학에 왕복 4시간이 걸린다. 거기에 맞지도 않는 전자공학부에 재학 중이다. 이런 내 마음.. 중요하니 크게 강조하겠다.
아.. 졸업하고 싶다.
ㅋㅋㅋ 장난이다(진심임). 그냥 스트레스를 받는 이유는 다른 게 없다. 학교 때문에 내가 하고 싶은 걸 못한다. 나는 전투 기획 쪽에서 포폴도 만들어보고 싶고, 블로그 글도 이것저것 연구해 보면서 매주 하나씩 작성하고 싶은데 그냥 심적인 여유가 없다.
누군가 근성이 부족하다고 하면 뭐.. 맞을 수는 있는데 사람이 완벽할 수는 없지 않나.. 그냥 갔다 오는 것 자체가 피곤하다. 이 때문에 결석을 10번 넘게 하기는 했는데.. 후회하지는 않는다.. 보람찬 결석이었다.. 😏😏
다음 학기인 막학기에는 '창업 대체 학점 인정제'라고 해서 창업 활동을 하면 학교 수업을 듣지 않아도 되는 활동을 신청하려고 했는데, 이것도 알고 보니 다중 전공 학점은 인정이 안 돼서 못 할 것 같다. 다중 학점 1학점 남았는데.. 슬프다.
슬프니까.. 더 보면 슬퍼지니까.. 여기는 대충 이번 학기에 한 것들을 정리하고 넘어가도록 하겠다.
<Breath in Winter> 개발 : C++와 Blueprint 사이의 균형
혹시 이전 수확제에서 졸업 작품으로 VR FPS 게임을 개발하고 있다고 한 것을 기억하는가? 나는 그 이후에도 계속 작업을 이어갔다.
가장 먼저 기존 기능을 정리하고, 추가해야 할 기능을 정의한 뒤, 이를 UML로 작성하여 C++로 변환하는 작업을 했는데 작업은 3월 중에 시작해 놓고, 늘 그렇듯 잘 모르니까 손이 안 가서 한 달가량을 구조만 끄적이고 아무것도 하지 않았다.
그러다, 4월 초쯤에 미뤄놓고 있는 게 마음에 걸려서 한번 해봤는데 생각보다 간단하게 돼서 그때 자신감을 회복하고, 4월 말에 여유가 생긴 뒤 본격적으로 변환 작업을 진행했다.
변환 과정에서는 여러 기능을 추가하기도 하고, 다양한 이슈들도 많았는데 기억에 남는 것만 아래에 적도록 하겠다.
- 순환 참조 오류
C++로 변환하는 과정에서 구조를 잘못 설계해서 서로가 서로를 include 하게 설정했더니, 컴파일 단계에서 에러가 발생했다. 한번 확인해 보니 언리얼 엔진에서는 count reference를 통해 객체의 생명 주기를 관리하는데 순환 참조가 발생하면 이러한 시스템이 정상적으로 작동하지 않을 수 있기에 막아놓는다고 한다. 아마 GC 관련된 내용인 것 같다. (서로가 서로를 참조하면 절대 count reference가 0이 되지 않기 때문에 문제가 된다.) - 나이아가라 시스템과 충돌 처리
하나의 이펙트로 여러 효과를 구현하고 싶어서 parameter에 반응하는 나이아가라 시스템을 만들었다. 그 과정에서 나이아가라 파티클이 충돌하면 대상 actor에게 데미지를 주도록 구현했는데, 직접적으로 데미지를 주는 방법을 찾을 수 없어 문제가 됐다. 그래서, 그냥 export particle data to blueprint 노드로 충돌이 발생하면 지정한 블루프린트로 충돌 좌표와 관련 데이터를 넘겨주도록 했다.
다만, 이때 충돌한 actor, 그 자체를 넘길 수는 없어서 충돌 좌표에 collision sphere를 생성하고, 그걸로 actor를 검출하도록 구현했다. 지금 당장 동작하기는 하는데 생각보다 깔끔하지는 않아서 추후 기회가 되면 더 좋은 방법을 알아봐야겠다. - 오브젝트 풀링
게임 내에서 하나의 나이아가라 시스템에서 하나의 총탄 이펙트를 재생하도록 했는데, 매번 나이아가라 시스템을 스폰하고, 관련 parameter를 넘겨주고, 활성화를 하게 되면 자원 소모가 심할 것 같았다.
그래서, 나이아가라 풀을 구현을 한 뒤 필요할 때마다 풀을 확인하고, 풀에 활성화 가능한 나이아가라 시스템이 없다면 새로 스폰하는 방식으로 오브젝트 풀링을 구현했다.
아래는 오브젝트 풀링 관련 코드인데 지금은 동작하는 것에만 초점을 맞춰서 코드가 더럽다.. - AI가 움직이지 않는 문제
AI도 controller부터 pawn, behavior tree task까지 C++로 구현했는데 뭐가 문제인지 동작하지 않았다. 거의 이 문제에만 일주일을 매달려서 가능한 모든 부분을 테스트해 봤는데 기존 블루프린트 방식에서 controller, pawn, btt 등 수정한 부분을 하나씩 넣어보면서 테스트해 본 결과, 블루프린트 방식에서 각자 잘 동작하던 게 C++로 구현한 것들끼리 묶어놓으니까 안 됐다.
너무 오래 붙들고 있으니까 의욕이 저하되기도 하고, 최종 발표까지 얼마 남지 않은 시기라 그냥 깔끔하게 포기하고 기존 방식을 사용하기로 했다. 심지어 똑같이 설정했는데 동작하던 게 갑자기 안 되는 경우도 발생해서 지금 당장 내가 손 볼만한 역량이 안 된다고 생각했다.
무언가 내가 잘못 설정했거나, 중요한 것을 놓친 것 같은데.. 아직도 잘 모르겠다. - 특정 무기가 발사되지 않는 문제
Sniper Rifle이 입력은 잘 받는데 탄이 발사되지 않았다. 이것도 거의 일주일 동안 붙들고 있었는데, 같은 코드더라도 서로 다른 동작을 했다. 갖은 고생을 해가며 찾은 단서는 헤더 파일인데 'weapon의 child class'에서 'weapon을 참조하는 pawn'을 참조하게 되면 컴파일 단계에서 검출되지는 않아도 순환 참조 오류가 발생하면서 내부적으로 무언가 꼬이는 것 같았다.
동일한 코드더라도 한 번 해당 문제가 발생한 코드는 헤더 파일 참조를 지워도 다시 정상적으로 동작하지 않았다. 내부적으로 꼬인 것 말고는 따로 설명할 말이 없는 것 같다. 이 부분도 그냥 급해서 해결하기보다는 다른 무기의 class를 임시로 parent class로 참조하도록 하여 동작하게 만들었다. - AI가 플레이어를 찾지 못하는 문제
전차 에셋을 적용한 이후, AI가 플레이어를 찾지 못하는 문제, 정확히는 찾더라도 추격하지 않는 문제가 발생했다. 로그를 찍어보면서 확인했는데도 특별한 게 없었다.
그래서, 포럼을 뒤져보니 navigation system에서 기본 query 범위를 벗어나면 정상적으로 동작하지 않는다는 글을 발견할 수 있었다. 실제로 확인해 보니 대상이 지면의 z 값보다 250 이상 더 크다면 제대로 query 되지 않는 문제가 발생한다는 것을 확인할 수 있었다.
이를 통해 전차 에셋을 적용하면서 player pawn이 위치할 socket의 높이가 높아져서 발생한 문제라고 추정할 수 있었다. 이는 단순하게 player pawn이 아니라 전차를 추격하도록 변경해서 해결했다. (아니, 근데 이건 엔진 동작 방식을 모르면 어떻게 찾음 ㅠㅠ)
이 외에도 괴상망측한 이슈들이 많았는데.. 다 말하면 쓰기도 귀찮고, 너무 많아서 그냥 여기서 적당히 끊겠다. 아무튼 이렇게 개발하고 변환한 결과는 아래와 같다.
이번에 변환을 하면서 느낀 점은 언리얼 엔진에서 모든 부분을 C++로 구현하는 건 비효율적이라는 것이다. 처음에는 별 다른 검증 없이 단순하게 C++로만 구현을 하면 성능과 유지 보수 측면에서 모두 좋아질 것이라고 기대했는데, 이는 구조 설계가 잘 이뤄졌을 때나 부분적으로 효과가 있는 것이지 만능은 아니라는 걸 깨달았다.
무엇보다 내가 언리얼 C++ 개발에 완전히 익숙해진 상황이라면 모를까, 추가 기능을 개발해야 할 시간에 변환만 하고 있으니 생각보다 많은 시간이 소모되어 당초 계획했던 목표의 60%가량만 구현할 수 있었다.
지금 생각해 보면 C++로 전부 구현할 게 아니라 코드 상으로 상속이나 합성 관계 등의 구조를 정의하고 필요한 기능들을 구현해 둔 뒤, 인터페이스로 활용할 것들만 블루프린트에서 callable 하도록 빼놓는 게 가장 좋은 방식이 아닐까 싶다. (그리고, 차후 기능들을 헷갈려서 잘못 개발하는 일이 없도록 웬만하면 각 요소들의 규칙을 정의한 문서도 정리하는 게 좋을 것 같다는 생각을 했다)
뭐.. 이것도 갓 3개월 남짓 개발해 본 뉴비 입장이라 또 달라질 수는 있지만.. 적어도 모든 걸 C++로 구현할 필요는 없다는 건 확실하게 느꼈다.
최적화 이슈를 고려한다면 코드를 정리할 시간에 필요 없는 에셋을 정리하거나 렌더링 옵션 하나를 조절하는 게 훨씬 빠르고 효과적이라는 생각을 했다.
아무튼 결론은 고통스러운 시간이었음에도 불구하고, 꼭 한번은 시도해봤어야 할 유익한 경험이었다는 것이다. 이번 5월 30일을 기점으로 졸업 작품이 마무리되어 당분간은 휴식을 취할 것 같은데, 휴식 기간 동안 구조를 다시 한번 정리해 보면서 이후에 진행할 리팩토링을 준비해보려고 한다.
<Breath in Winter> 발표 : 도비는 자유예요!
지난 5월 29일, 캡스톤 결과 발표회가 있었다. 당시 발표를 위해 급하게 버그가 난 기능들을 수정하고 간단하게 라이트와 UI를 조정해 본 뒤, 바로 시연할 수 있도록 환경을 마련해 놨다.
발표의 경우는 시연을 포함해서 8분, 질의응답 7분으로 구성이 됐는데 앞 팀의 발표를 보니 발표 중간중간에 '몇 분 남았습니다.'라고 말하는 게 상당한 압박감으로 느껴졌다. 실제로 이 말은 들을 발표자가 당황한 기색을 보이기도 했고 말이다.
그래서, 나는 스크립트를 작성한 걸 그냥 그대로 읽기로 했다. 약 반 년동안 비단 캡스톤 디자인만을 위해서가 아니라 개인 성장을 위해서 많은 것을 했기에 축약하고, 또 축약해 봐도 전해야 될 내용이 많았고, 이 과정에서 제한 시간 내에 핵심적인 내용을 전달하려면 빠르게 발표를 할 필요가 있다고 생각했다.
뭐.. 흐름만 기억해 놓고 그때그때 조금씩 로딩해 가면서 발표를 해도 되지만 나는 기억력이 그다지 좋기 않기에 스크립트를 읽는 것이 최선이라고 생각했다.
그렇게 아래와 같이 발표를 진행했다.
사실.. 자료는 PPT를 만들기가 귀찮아서 예전 자료로 돌려 막기 했다. 자세히 보면 PPT 하단에도 연도 수정을 안 해서 2023년으로 되어있다😅😅.
아무튼 발표는 문제없이 진행할 수 있었다. 다만, 발표회에 대해 두 가지 아쉬웠던 점이 있었다.
첫 번째는 게임이라는 교수님들께 친숙하지 않은 주제다 보니 제대로 전달하지 못했다는 것이다.
C++ 변환으로 인해 시간이 기대 이상으로 소모됐고 이 때문에 모든 콘텐츠를 구현하지 못했다는 것과 하지만 그럼에도 나머지 콘텐츠를 추가할 기반을 마련했다는 것을 말씀드렸는데 '그래서, 결국 너가 말한 VR FPS RPG의 결합이 안 된 것 아니냐.'라고 질문이 들어오고 결론이 나서 조금 아쉬웠다.
두 번째는 시연을 하지 못했다는 것이다.
시연을 위해서 오큘러스 퀘스트를 짊어지고 왕복 4시간을 오가며 환경을 구축하고 열심히 준비했는데.. 교수님들께서 시연을 하지 않으셨다.. 아니.. 시연은 필수라면서요!!! 마지막에 보면 시연을 안 해도 된다는 말을 듣고 굉장히 씁쓸해하는 내 모습을 볼 수 있다 ㅋㅋㅋ
어떻게 됐든 결과 발표회는 잘 마무리 지었다. 뭔가 회사 입장에서 선호하지 않을 것 같은 속성이긴 한데, 나는 내가 확신하는 것들에 대해 호전적인 성향을 갖는다. 그래서, 이번 결과 발표회 또한 교수님들의 태도와 질문이 공격적이면 공격적일수록 내 안의 호승심이 솟았고 주눅 들면 끝나는 일종의 디펜스라고 생각하여 침착하게 대응할 수 있었다.
(교수님들이 잘못 됐다는 게 아님! 전자공학부 결과 발표회에서 게임이 나온 게 생소하기도 하고, 교수님들 입장에서는 학생이 졸업할 자격이 있는지 심사를 해야 하기에 공격적인 질문을 하는 건 당연함! 나는 열심히 준비한 것을 시연하지 못했다는 부분에 아쉬웠던 거지 공격적인 질문 자체는 환영임! 이런 질문은 3시간도 즐겁게 할 수 있음!)
추가로, 어디서 들은 말인데 프레젠테이션은 내용 전달도 전달이지만, '내가 얼마나 확신하는가?'를 보여주는 자리이기도 하다는 말을 들은 적이 있다. 나 또한 당시 이 말을 듣고 굉장히 공감을 해서 조금 더 자신 있게 말하려고 하기도 했다.
다음으로 발표 질의응답 부분에서 '회사는 VR 게임을 개발을 하기에 효율이 나지 않고, 개인은 어렵다. 그렇지만 개인은 효율이 있다.', '스토리를 위한 기반 시스템은 구현이 돼 있는데 스토리는 구현이 안 됐다.'라는 다소 모순적으로 보이는 답변을 했는데 이 부분에 대해 조금 더 해설을 하고 이번 항목을 마무리 짓겠다.
먼저, '회사는 VR 개발을 하기에 효율이 나지 않고, 개인은 어렵다. 그렇지만 개인은 효율이 있다.'는 부분이다.
회사 입장에서 새로운 플랫폼의 게임을 개발하려면 관련된 인력, 기존과는 다른 경험 설계 방식 등 이미 검증된 부분을 벗어나 새로 투자해야 될 부분이 많다.
나는 회사란 기본적으로 이윤 추구를 목적으로 하는 조직이라고 생각하기에, 특별한 이유가 없다면 이미 익숙하고 검증된 자사의 PC/모바일 시장을 두고 리스크를 짊어지면서까지 VR이라는 새로운 플랫폼 시장을 개척할 이유가 없다고 생각했다. 개인이 만든 프로젝트에서 가능성을 검증하고 자사로 편입시키는 것이면 모를까 말이다.
이런 관점에서 '회사에서는 효율이 나지 않아 진입을 하지 못하고 있다.'라고 말했다.
이에 반해 개인이 시도하기에는 어렵다는 말은 기본적으로 VR 게임을 개발하기 위해서 PC/모바일에 비해 많은 어려움이 있기 때문이다. 가장 먼저 장비를 구해야 하고 로직을 완성도 있는 3D 리소스를 구하고, VR의 특성을 활용한 경험을 설계하며, 여기에 더해 최적화까지 진행을 하는 게 많이 어렵다고 생각했다.
하지만, 그럼에도 효율이 있다는 말은 최근 발전하는 기술과 잘만 사용한다면 혼자서도 극한의 생산성을 뽑을 수 있는 언리얼 엔진을 활용하면 어느 정도 극복이 가능하기에 효율이 있다고 했다. 더군다나 체계적인 시스템이 구축된 회사보다는 유연하게 도전할 수 있어서 공격적인 개발이 가능하기도 하고 말이다.
그리고, 스토리 같은 부분은 단순하게 스토리가 도입됐을 때 선택지에 따른 반응형 시스템(무기 변화, 몬스터 난이도 및 스폰 속도 등)은 구현됐지만, 스토리 자체는 게임 내에 도입되지 않았다는 걸 말하려고 했는데, 둘 다 구현이라는 단어를 써버려서 혼동을 줬다. 뒤늦게 구현이 아닌 결합이라고 정정하기는 했는데 앞으로는 조금 더 세심하게 어휘를 선택할 수 있도록 단어 간 뉘앙스를 잘 고려해야겠다.
아무튼 이러한 의미에서 위와 같이 말했던 것인데 발표 당시에는 다소 모순적으로 들리게 답변을 한 것 같아 많이 아쉽다.
추가로, 지금 영상으로 보니까 이해되지 않는 내용이 있으면 고개를 까딱거리는 걸 볼 수 있는데, 사람에 따라서 기분 나쁠 수도 있을 것 같아서 고쳐봐야겠다는 생각을 했다😅😅.
띠용.. 글을 쓰고 있는 도중에 공학 대학 캡스톤 디자인 페어에 전자공학부 TO 중 한 자리로 선정됐다는 연락을 받았다. 아뉘~ 내 프로젝트에 관심이 없으신 줄 알았는데 사실은 관심이 있으셨던 거냐구~
작품을 개발하면서 언리얼 에셋은 지원이 안 된다고 해서 지원금을 못 받고 자비로 구매했는데, 이번에 지원금이나 낭낭하게 받으면 좋겠다.
우화 : 증명하는 디자인을 향해서
나는 21년 9월에 게임 기획을 시작해서 약 3년가량 혼자 게임 기획을 공부하고 있다. 그러다, 작년 9월 즈음부터 블로그를 보고 연락 주신 기획자 분을 포함하여, 학교 내 졸업 선배 멘토링으로 만난 분, 기업 탐방을 하며 만나게 된 분들로부터 종종 조언을 받곤 한다.
(제게 조언해 주신 학교 선배님 계신가요.. 답변을 받고 질문 기회로 감사 인사를 드려도 되는 건지 고민하다가 대화가 막혔습니다.. 연락할 길이 없습니다.. 여기서라도 대신 전합니다. 정성 어린 조언 감사했습니다..!)
내 블로그를 보는 사람이라면 알겠지만 나는 게임 디자이너(기획자)로 성장한다고 하기에는 많이 독특한 길을 걷고 있다. 굳이 할 필요 없는 개발부터 시작해서 철학, 연출, 아트까지.. 온갖 특이한 것들은 다 하고 있다. 내가 이런 길을 걷는 것은 좋은 게임 디자이너가 되기 위함이기도 하지만, 궁극적으로 좋은 창작자가 되고 싶기 때문이다.
내가 이 블로그에 기록하는 것들은 취업을 위한 것이 아니다. 물론 '취업과 전혀 상관없냐.'라고 묻는다면 절대 아니겠지만, 기본적으로 취업을 위해 시작한 블로그가 아니라는 것이다. 그냥 언젠가부터 생각이 복잡하면 글을 썼고, 글을 쓰면 보다 나은 내가 될 수 있는 길을 찾을 수 있었기에 지금까지 이렇게 꾸준히 글을 쓴 것 같다.
왜 이런 이야기를 하느냐? 여러 기획자 분들께 멘토링받은 결과가 블로그에 대한 내용이기 때문이다. 멘토링의 공통되는 부분은 아래와 같다.
잘하고 있다. 이렇게까지 하는 사람은 드물다. 그런데, 이런 글을 통해서 기획적인 역량을 보여줄 수 있는지는 잘 모르겠다.
제대로 보셨다. 나도 항상 느끼는 문제다. 취업을 위한 블로그가 아니다 보니 어느 순간부터 블로그의 목적성이 애매해졌다. 내 블로그는 '취업을 위한 블로그'일까? 아니면, '성장을 위한 블로그'일까?
답은 이미 나와 있다.
나는 틀을 벗어나 성장하기 위해 글을 쓴다.
조금은 재수 없는 소리겠지만, 나는 탁월함을 원한다. Outlier가 되기를 원하고 extraordinary, 역천괴가 되기를 바란다. 많은 사람들이 나의 작품을 보고 살아있음을 느끼기를 바라고, 그 이전에 나와 함께 하는 작업자들이 나의 디자인에 꿈을 꾸기를 바며, 다시 한번 그 이전에 내 스스로 나의 디자인에 확신을 갖기를 원한다.
내가 그리는 궁극적인 나의 모습은 살아있는 게임을 만드는 마에스트로. 나는 수많은 작업자들의 연결점이 되어 그들이 가진 바 최고의 역량을 발할 수 있게 만들며, 그들의 벡터를 모아 세계에 하나의 선을 긋기를 바란다.
그리고, 이를 위해서는 나는 나의 디자인을 증명할 수 있어야 한다. 스스로 증명하고, 검증하며, 성장할 수 있는, 그렇게 나아갈 수 있는 체계를 내 안에 구축해놔야 한다.
나는 이런 체계의 첫 번째로 '아카이브'를 준비하고 있다. 이전 수확제에서 언급한 게임 디자인 연구 프로젝트의 발전된 버전인데, 이름만 멋있지 사실상 선천적인 감각에 의존하지 않고, 실질적인 결과물을 확인해 가며 인사이트를 쌓고, 벼리겠다는 것이다.
지난 3개월 동안 꾸준히 개발을 하면서 이제는 어떠한 전투 시스템을 구현하기 위한 역량이 준비됐다고 생각한다. 앞서 말한 것처럼 당분간은 <Breath in Winter> 프로젝트를 쉬고, 이런 '아카이브'에 데이터를 쌓고 블로그에 기록하려고 한다.
이것이 앞서 멘토 분들이 걱정하셨던 기획적인 역량에 대한 답이 될 것이다. 혹자는 이것도 구현하는 과정에서 기술에 치중되지는 않을지 걱정하실 수 있을 것 같다.
이 부분에 대해서는 나도 지금까지 해온 것이 있기에 한 순간에 달라질 것이라고 바로 단언할 수는 없을 것 같다. 그러나, 단 한 가지, 나는 개발자이기 이전에 한 명의 디자이너임을 명심하며 기술보다는 의도와 경험에 치중된 분석을 할 수 있도록 노력하겠다고 약속한다.
지금까지는 블로그를 통해 기술적인 역량을 주로 보였다면, 앞으로는 기획적인 역량도 함께 확인할 수 있을 것이다.
마치며
오랜만에 글을 쓰니까 너무 막 내뱉는 부분도 많고, 글도 길어진 것 같다.. 혹시라도 보기 불편했다면 미안하다😅😅. 계속 글을 쓰면서 다시금 감각을 다져 좋은 글을 써보도록 하겠다.
아무튼 이게 나의 24년 상반기 근황인데 어떻게.. 재미있었는지 잘 모르겠다. 뭐.. 지금 당장은 보여줄 게 이것뿐이지만 늘 그렇듯 항상 나아가며 더 재미있고 새로운 것들을 보여줄 수 있게 노력해 보겠다.
이 글을 보는 여러분이, 그리고 이 글을 쓰는 내가, 언젠가 어려움을 마주하더라도 한계를 넘어 딱 한 걸음 더 나아갈 수 있기를 바라며 글을 닫겠다.
'일상' 카테고리의 다른 글
| [2024 넥슨 대학생 게임잼 후기] Lib's Rarry (2) | 2024.07.29 |
|---|---|
| 2024 공학 대학 캡스톤 디자인 페어 후기 (0) | 2024.06.06 |
| 수확제(收穫祭) : 개(開) (1) | 2024.02.17 |
| 2023년 연말 회고 : 정제 (精製) (0) | 2024.01.01 |
| 근황, 그리고 앞으로의 계획 (0) | 2023.09.15 |
