역시 중간발표입니다. 일주일 좀 안되게 매달린것 같은데 진도가 참 안나가네요.
역시 다른 플렛폼 개발은 여러모로 힘든점이…
그럼 모바일 삼품에 대해 지금까지 조사된 점에 대한 중간보고를 공유차원에서 정리하자면…
우선, 모바일 버전도 PC 버전과 데이터를 최대한 같게 가고 싶긴 하지만,
사실상 근본적으로 다르기 때문에 “미리 정하고 진행해야 하는 것"은 미리 해야만 합니다. ‘삽질할거면 빨리 해라’ 라는 거지요.
폴리곤을 줄인다던가, 텍스쳐 사이즈를 줄인다던가 하는 일은 사실 나중에 해도 큰 문제가 없는 것이지만, ‘캐릭터 옷을 갈아 입힐 것인가’ ’ 파츠 베리에이션을 할 것인가’ 등등은 미리 정해놓고 가지 않으면 안되는 일입니다.
그렇지만 사실 여러 가지 경험부족으로, 모든 상황과 모든 규칙에 대해 일일히 실험해 보며 돌다리를 두드려 보다 보면 아예 일이 진행되지 않는지라… 다소 미심적인 데이터가 있다 하더라도 다른 프로젝트에서 제작한 선례를 최대한 따라 가는 방식으로 만들기로 하였습니다.
그럼 정리 시작. ===========================================================================
- 캐릭터
-캐릭터는 갑옷을 갈아입지 않습니다. .(파츠가 없습니다. 캐릭터는 무조건 1 DPcall을 요구합니다.
캐릭터의 갑옷을 갈아입는 것은 인벤토리에서의 아이콘으로만이며, 진짜 캐릭터 외형은 변하지 않습니다.
기본적으로 플레이시에 캐릭터가 작게 보이는 데다가
텍스쳐 교체는 가능합니다. 텍스쳐 교체비용을 추산해 봐야 하겠지만, 이론적으로는 가능할 듯 합니다.
이를 이용해서 형태는 변하지 않더라도 텍스쳐만 변하게 해서 캐릭터의 외형을 변하게 할 수 있긴 합니다 .(갑옷을 갈아입은 것처럼 보일 수 있습니다. 물론 형태는 변하지 않지만)캐릭터는 갑옷을 갈아입지 않는 형태를 취한다고 봤을 때, 4가지 형태의 체형과 5가지 무기, 2가지의 탑승형태를 가지고 있습니다. 이 형태를 유지한 채 조합한다면, 캐릭터는 최대 3개의 파츠로 나눠진 캐릭터가 되게 됩니다.
염색은 지원 가능합니다. 사용할지 여부는 기획팀 답변을 기다리겠습니다. (준경부팀장…)
외각 선택 지원 가능합니다. (쉐이더로 처리하는 것이 아닌 아이폰 기능으로 처리합니다. 쉐이더로도 처리 가능하긴 합니다만, 가능한한 안썼으면 합니다 )
라이트는 사용하지 않겠습니다.
캐릭터에 한해서 라이트를 사용할 수 있습니다만, 캐릭터가 워낙 작게 표현되고 라이트 효과의 의미가 상당히 작기 때문에 - PC 버전에서도 self illumination을 100% 사용합니다- 라이트를 사용하는 것이 큰 의미가 있다고 보여지진 않습니다.
캐릭터 쉐이더는 Unlit 쉐이더로 만들도록 하겠습니다.당연하게도 그림자 따위는 없습니다. 동그란 그림자는 가능합니다만, 이것까지 줄여버릴까라는 생각을 호시탐탐 하고 있습니다. (1 call 이 준다… 뭐 캐릭터 텍스쳐에 포함시켜 놓으면 또 모르겠지만.)
===========================================================================
- 배경
- 모바일에서는 내장된 터레인이 돌아가지 않습니다.
때문에 메쉬로 컨버팅 해서 대치하는 방식의 작업을 하고 있습니다.
그 후 각 오브젝트들은 각각 모바일 버전에 상응되도록 수정되어, 원본 오브젝트와 교체되는 제작방식을 취하고 있습니다.
이 문제의 단점은 크게 3가지를 예상할 수 있습니다 .
1. 최적화에 불리함.
단일 오브젝트를 줄이는 것만으로는 부족한 경우가 꽤 있습니다. 필요에 의해서는 건물 3-4채, 오브젝트 몇 개를 하나의 오브젝트로 합쳐야 되는 경우가 있습니다만, 오브젝트를 별개로 불러와 모바일 형태로 전환한 후 교체하는 지금 방식에서는 과감한 Attach가 힘든 면이 있습니다.
2. 나무는 방법이 없다.
대표적인 자연물인 나무는 배경을 풍성하게 해주는데 큰 도움이 됩니다. 그렇지만 이 나무는 터레인에 소속된 나무로, 독립적인 오브젝트로 취급받지 못하는 것입니다. 이것은 풀도 마찬가지이지만, 풀은 보통 충돌체크가 되어 있지 않기 때문에 문제가 덜합니다. 그렇지만 나무는 심각합니다. 현재 방식에서는 나무의 위치를 PC버전과 모바일 버전 모두에 완벽히 매치되도록 만들 수 없습니다.
3. 조명 문제
많은 스마트폰 게임의 제작과정에서 줄기차게 얘기하는 것은 ‘배경에서는 절대로 조명을 사용하지 말라’ 라는 것이었습니다. 조명의 사용은 게임을 느려지게 만든다고 합니다. - 테스트를 해보고 싶지만, 그럴 여유가.. - 때문에 보통 라이트맵을 사용합니다만, 애석하게도 PC 버전에서 사용하는 비스트를 이용하면, 모바일에서는 원활하게 사용하기 쉽지 않습니다. - 모바일 쉐이더로 바꾸면, 프리팹 등의 경우에 라이트맵이 마구 깨집니다 -
물론, 위의 단점이 모두 치명적이냐라고 물으신다면 그렇다고도, 아니라고도 말할 수 있습니다. 자세한 것은 좀 더 테스트 해봐야 알겠지만, 1. 최적화 문제는 데이터만 줄이는 지금의 방식으로도 충분히 빠르다면야 굳이 손대지 않아도 되며, 3. 조명 문제 도 무시하고 그냥 가신다면야 그냥 갈 수 있습니다. (그림자가 없으셔도 되신다면야)
2. 나무 문제는 조금 문제지만, 현재 황 TA가 나무의 xml 데이터를 불러와서 맥스에 표시하는 방법을 연구중이니, 터레인을 맥스에서 메쉬로 만드는 작업을 할 때 나무도 같이 박아서 넘기면 가능할 듯 합니다.
그러므로 위 문제는 AD와 상의하여 결정할 문제이며, 위 3가지를 모두 개선한다면 그래픽 프로세스에 큰 변화를 주어야만 합니다.
위 문제를 개선하기 위한 배경 프로세스는 다음과 같습니다.
터레인을 비롯하여, 맵의 모든 메쉬 데이터를 맥스로 불러온다
간단히 얘기해서 맥스에서 모든 배경 작업을 한다는 말입니다. AT2같은 경우는 힘들겠지만, 삼품 데이터라면 좀 넓더라도 맥스로 불러오면 커버할 수 있으리라고 보여집니다.맥스에서 오브젝트의 Attach, 또는 과감한 교체를 한다.
맥스에 모든 데이터가 있으므로, 점유하고 있는 충돌 OX 값 (이 값도 맥스로 넘길 수 있다면…) 을 유지하도록 신경쓰면서 과감하게 Attach 시켜서 한 오브젝트로 만들거나 데이터를 교체할 수 있습니다.나무의 데이터는 Xml 데이터를 읽어 박스로 표시
맥스에서 박스로 표시된 부분에 제작된 나무로 교체하면 나무의 충돌영역 인식도 끝.맥스에서 라이트맵 제작
맥스에서 라이트맵을 RTT로 제작하여 소스를 만듭니다. 폴리곤이 적으니 Baking 시간도 적게 걸립니다. 라이트맵에 리터칭을 할 수도 있습니다 .게임으로 넘김
이렇게 모두 제작하여 게임으로 넘깁니다.
이 방식으로 제작하면 퀄리티가 올라가는 장점이 있지만, 제작 품이 더 든다는 단점이 있습니다. 어느 것을 선택할지는 AD와 상의해야 할 듯…
현재 여기까지 연구되어 있으며, 실제 테스트를 더 거친 후 최종 결정을 내리도록 하겠습니다.