Project Denial 개발 기록.

국내 게임메이커 커뮤니티 네이버 카페 Crazy Game Maker에서 시작된 제 9회 게임잼을 알게되어 개발 시작.

제작 기간이 5월 7일 ~ 14일 이였기에 남은 시간이 별로 없는 와중에

주제가 '어른과 아이'였기에 생각보다 무거운 느낌이 들어서 가벼운 플레이방식의 무거운 주제의 레퍼런스가 될만한 게임을 찾아 보았다.

--------------

국내 유명 인디게임'Replica'를 레퍼런스로 선택.

주제 그 자체는 레퍼런스로서는 거리가 멀어보였지만

해당 게임의 시스템은

무거운 주제에 대한 연출방식의 하나로서 상당히 유효하다고 생각했다.

이를 모티브로 하여 

스마트폰의 컨텐츠를 텍스트형식을 주로 보여주며

간접적으로 스토리텔링을 이어나가는 방식을 채택.

---------------------------------------------//

했으나 이건 다 끝난 지금에서 보면 잘못된 선택이였다.

스토리텔링 게임으로서 스토리가 재미있는지 없는지 판단하기는 커녕 

개발자의 연출의도가 제대로 게이머에게 전해지는 지 조차도 판단하기 힘들었다.  //장려상 후기를 읽어보니 절반 정도는 성공한 듯 하다.

구체적인 이유는 게임잼의 기간이 짧아서 테스트를 하면서 피드백을 적용할 여건이 안되었던 것도 있었지만

근본적으로 이런 장르의 희소성(참고할만한 레퍼런스의 희소성)과 개발자 본인의 작가로서의 능력부족이 있겠다. // 최초 작성

인물사이에 오가는 문자 텍스트나 휴대폰의 정보가 어떤 정보가 남아있느냐. 그 정보의 내용은 무엇이냐.에 따라서 

유저에게 보여줘야 할 정보는 무엇이며 보여줘서는 안될. 보여줄 필요가 없는 정보는 무엇이냐.

그 컨텐츠를 보여줄 때의 연출은 무엇이 효과적이냐. 등등 해당 장르에 대한 이해가 부족했다. //1번째 추가 

그리고 구현하기 귀찮은. 힘들었던 부분에 대한 욕심을 부렸던 것. 구체적으로는 페이스북 어플 로직. 레플리카 오마주 등 기획 단계에서는 ~~식으로 연출할 수 있겠다 싶었으나 막상 구현하려고 하니 개연성도 조금 떨어지는 것 같고 억지로 컨텐츠를 욱여넣는 느낌인데다가 추가로 시간도 별로 없었다. // 2번째 추가 

또한 해당 장르는 스토리에 충분히 몰입하기 위한 최소의 컨텐츠량이 필요한 장르로 판단되는데. 그 컨텐츠가 양적으로도 부족했고. 퀄리티적인 면에서도 단편적인 스토리를 베이스로 유저가 깊게 빠져들도록 만드는 것은 너무나도 허들이 높았다. // 3번째 추가

사전 배경설명. 등장인물의 성격을 유추할 수 있는 에피소드나 컨텐츠가 필요했다. 게임을 만드는 사람의 뇌속에는 박혀있지만 게임을 처음접하는 플레이어는 이를 자연스럽게 유추할수 있느냐 없느냐에 따라 몰입할 수 있느냐 없느냐가 갈리는 경우도 있을 것 같다. // 4번째 추가

--------------------------

게임 리소스는 친구인 Jibly(본인요청에 의해 닉네임사용)가 그려주었다. 컨셉은 레퍼런스인 레플리카를 참고.

또한 Jibly의 스마트폰인 아이폰 실물을 레퍼런스로 리소스를 만듬.

디자인에 큰 어려움이 있지는 않았던 모양이다.

어두운화면에 대한 인식차이로 다소 트러블이 있기도 했음.

시간에 따라서 모니터의 화면밝기를 조절해주는 F.lux 유틸리티 프로그램이 원인으로 명도에따라 회색으로 보여야 하는 스마트폰의 프레임부분이

아예 검은색으로 보여서 백그라운드 리소스부분에 다소 결함이 생김. //최초 작성

배경음악은 작곡가인 매형의 도움을 받았다. //이부분은 정말 축복받은 환경이다.

------------------------------------------------------------------------

구현 부분 - 메시지

메시지 리스트 레이아웃과 메시지의 내용. 메시지 수신인 또는 발신인만 표시하면 되었기에 한가지 글로벌 변수만 할당.

글로벌 변수를 등장인물 이름으로 지정하는 방식으로 보여줄 컨텐츠를 선택.

실제로 사용한 변수 global.message_who = "대화상대" ex) 페니, 카일, 맥스 등

if global.message_who = "페니"  

content.text ="페니's text"

생각보다 귀찮았다.

언더테일의 토비 폭스가 말한 Hell부분이 이 부분이다. 게임메이커 스튜디오에서 제공하는

레이아웃이든 프리셋이든 정해진 것이 아무것도 없다보니 위치조절이든 텍스트정렬이든 간단하지만 막상 구현하려면 귀찮은 로직을 제로베이스에서 처음부터 다 해야했다. //토비 폭스는 아마 상점 시스템이든 아이템 인벤토리 시스템이든. 그런거였겠지만.

이런부분은 GML코딩보다는 드래그-드랍 방식이 더 쉬웠을 법 하다.

// 이제와서 로직을 다시 짠다면? 

Sprite Mask를 적극적으로 활용. -리소스를 받아서 위치지정하고 그런 부분에서의 

잡음을 줄이고. 조금 더 그래픽 디자인의 의도를 살릴 수 있는. 그래픽 쪽에서 조금 더 많이 일을 할 수 있게끔.

system 오브젝트의 Create 로직에 instance_create_depth(0,0,depth,spirte_with_mask_setted) < x,y를 0,0으로 고정하고

스프라이트 디자인 그대로 레이아웃 로직을 구현.

---------------------------------------------

구현 부분 - 전화어플

전화번호를 000-0000-0000 총 11자리 다 구현하기보다는 6자리로만 구현하기로 결정.

메세지에 찍혀있는 숫자도 6자리까지 통일한 것은 다 좋았으나 되려 너무 짧은 덕에 전화번호 로직이 허졉해졌다.

방법은 스택. string관련 함수들. 등등이 떠올랐지만 if문 만으로 해결.

num[] 배열을 0~5까지할당하고 정수 10을 NULL처럼 사용.

11과 12를 #과 *로 사용하려했으나 도트 크기가 안맞아서 배제.

굳이 길게 적을 것도 없다. 

if문만 덕지덕지 붙인 괴상한 코드라서 길게 적고싶지도 않다.

----------------------------------------------

구현 부분 - 사내 메신저 톡

메신저와 다를 것 없다. 색만 조금 다르다.

다른 점은 귀찮아서 레이아웃을 1개만 했다.

메신저는 4개. 

다만 여기서 화면 상단의 시계부분 스프라이트를 수정함. // 그래픽에 관여하는 로직을 쓰는 오브젝트는 좀 생각해보고 만들자. 기획서가 이래서 필요하구나 싶었다. 현재 내 수준에서 직감으로 하는 코딩은 삽질로 이어질 가능성이 높다.

-----------------------------------------------

구현 부분 - 메모장

메시지의 레이아웃 오브젝트를 재활용.

global.message_who 도 재활용.

화면상에서 하나의 화면만 보여주면 되니까 글로벌 변수를 휙휙 바꿔도 문제가 없을거라는 판단.

실제로 별 다른 문제가 없었음.

다만 텍스트 드로잉 오브젝트를 바꿔서 쓰는데에는 쓸데없이 시간이 잡아먹힘.

결국draw_text_ext()를 사용. //가까운길을 참 멀리도 돌아왔다.

-----------------------------------------------------

구현 부분 - 주소록

메시지 레이아웃 부분을 하나 떼어내서 활용.

global.message_who 또 재활용.

게임에서 보여줘야할 부분의 텍스트만 채워넣는 부분에서 고민이 조금 있었다.

이건 보여줘야 하나? 유저가 쓸모있는 컨텐츠인지 아니면 보고 그냥 무시해도 되는 컨텐츠인지 판별하기 애매했다.

굳이 써넣을 정도면 어느정도 연결되는 컨텐츠를 넣어야하나? 라는 쓸데없는 욕심은 결국 버리게 되었고.

더미컨텐츠를 채워넣음.

----------------------------------------

구현 부분 - 캘린더

욕심부리다가 실패한 부분.

이부분은 아무리 좋게 봐줘도 실패다.

굳이 이 정보를 보여주는 의미가 뭐지? 뭘 눌러봐도 별다른 이벤트가 없는데? 라는 의문을 플레이어가 했을 법한데.

그에 대한 적당한 답변이 없다.

더미어플 리소스를 넣어놓고 클릭하면 아무런 이벤트도 없게 만든 주제에 

캘린더 어플 하나만 어플의 내부화면 딱하나 구현해놓고 더미어플들과 똑같은 취급이 되어버렸다.

여기에 노티스마크를 달아서 가이드라인으로 억지로 2번정도 보여줬으나

아무런 의미가 없었다. 굳이 비판적인 시각으로 바라보지 않더라도

이런 것도 구현했어요! 라고 어필하고 싶어하는 개발자의 구차함마저도 느껴지는...... 차라리 안 넣는게 나았다.

왠지 리소스를 받았는데 안쓰면 안될 것 같다는 심리가 있었을까?

진짜 쓸데없는 거에 시간 많이 쓴 듯 하다.

------------------------------------------------------------------------------------------------------------------

구현 부분 - 메인 화면

가장 간단했다.

기다란 텍스팅도 필요없고 그냥 클릭하면 어떤 화면(맵)을 보여주면 되는가. 

클릭했을때 맵이동만 하면 되었다.

맵을 이동하면서 글로벌 변수를 조작할 일마저도 없었다. 

조금 귀찮은게 있었다면 어플그림 아래에다 어플이름 텍스트를 드로우하는데 위치조정이 귀찮았던 것 정도?

지금와서 생각해보면 욕심을 부릴 부분은 여기였다. 간단하게 클릭해보고 어떤 화면이 나오는 것만으로

그것이 그냥 더미로서 게임본문 내용에서 아무런 의미를 가지지 않는다고 하더라도.

게임성을 더 많이 느낄 수 있었을거라고 생각한다.

모든 어플이 눌렀을때 어떠한 화면을 출력했다면

이 게임에 더 몰입할 수 있었을 것이고. 플레이타임도 조금 더 늘어났을지도 모른다.

-----------------------------------------------------------------------------------------------------------------

이 개발 기록을 쓰면서 느낀건데.

언젠가 한번 SNS에서 가볍게 읽어본 컨텐츠의 메시지였던 

"개발중에 주말정도는 프로젝트에서 떨어진 후에 그 다음주 월요일이 왔을때 새로운 시각으로 프로젝트를 바라본다면

그것만으로도 좋은 자체피드백이 될 수 있다." 가 생각났다.

이걸 실천할 수 있을까? 라는 점에서 의문을 가졌었지만

결국엔 맞는 말 같다. 

뭔가를 구현해야겠다. 라고 생각하고 코딩을 하기 시작하면 다 완성하기까지 계속 몰두하게 되는데

이것이 곧 본질적으로 여러가지 관점을 잃게되는 듯 하다. 그리고 삽질로 시간낭비로 이어지지.

이번 프로젝트는 기간이 짧아서 도저히 그럴 여유가 없었으나.

이번 프로젝트가 아닌 프로젝트에서 가져야할 마인드를 확인해본 셈이 아닐까.