▷ 기술사양
수정일; 2008.07.06
케쥬얼 FPS라는 특징을 살리면서, 일명 'Dog fighting'에 촛점을 두고 구현
 
•   라이트 유저를 겨냥한 생각하는 게임이 아니라 손으로 즐기는 게임이 되도록 노력
•   개발 일정이 MMO 게임에 비해서 짧고
    내가 오기 전, 과거 팀이 소모한 시간 때문에 구현은 최대한 샘플하게 처리 (캐릭터 간의 충돌 무시 등)
•   하드웨어적인 제한을 고려, 최소 리소스로 최대 화면을 구성할 수 있도록 지속적인 퍼포먼스 테스트
•   Gamebryo 2.3을 사용에 따른 지속적인 R&D와 Feedback
    (그래픽팀이 대부분 Gamebryo Document을 참고하지 않고, Document의 Artist 부분이 프로그램 일반에 관한 내용이 섞여 있기 때문에 3ds Max의 익스포트 옵션이나 셋팅 등에 관한 지속적인 feedback이 필요)
 
      # 게임진행
      # UI설계시 주안점
      # 세부 사항
          >> 캐릭터
          >> 배경
          >> 카메라
          >> 충돌처러
          >> 네트워크
          >> 사운드
          >> 이펙트
          >> UI
       

▶ 게임진행                   ▲...
-.다양한 무기를 쉽게 조작할 수 있도록 시스템을 설계
      --> 총(장총, 스나이퍼), 양손무기, 격투무기, 투척무기(수류탄, 연막탄)
-.다른 FPS와 차별된 skill을 도입
      --> 명예시스템으로 계급이 존재하며
      --> 일정한 단계가 되었을 때, 클래스로 분화하고 클래스에 따른 skill을 사용
-.처음시작
      --> 저격이나 투척무기를 사용할 수 없음
-.1차 전직
      --> 3가지로 분화된 클래스를 가짐
      --> 클래스에 따른 스킬 한가지와 투척무기를 사용할 수 있음
-.2차 전직
      --> 1차전직에서 다시 2가지 클래스로 특화
      --> 저격무기는 스나이퍼만이 사용할 수 있음
-.다양한 모드구현
      --> 팀타임어택/ 팀데스메치/ 개인타임어택/ 미션(탈출, 폭파, 깃발 뺏기등)
 

▶ UI설계시 주안점           ▲...
-.일반적인 FPS에서 사용하는 정의된 키를 상용함으로 익숙함을 제공
-.최대한 간결화 함으로 게임에 몰입성을 높임
-.문자보다는 이모티콘을 표시를 사용함으로서 언어적 제약을 탈피
 

▶ 세부 사항             ▲...
-.하드웨어 제한; 목표 사양(Shader 1 버전을 지원하는 사양)
   • CPU ; AMD Athlon(tm) XP 2500+ 1.83GHz/ RAM ; 1GB
   • VGA ; RADEON 9000 SERIES의 Philips 107T(107T2, 128MB)
-.Gamebryo에서는 충돌설정이나 노드 이름식별에 특정 문자열을 사용하고 대소문자를 구별하며
    특히, 노드 이름 지정시 정해진 규칙 준수와 문자열 마지막에 공백이 들어가지 않도록 주의
-.그래픽 리소스 작업은 DirectX를 직접적으로 사용해서 구현하는 경우와 다를 바가 없으며
    단지, 최종 데이타 가공에서 특정 엔진 사용에 따른 익스포트나 재질설정 등이 다를 뿐
-.Gamebryo의 특징 중 하나로써 3ds Max에서 Gamebryo material을 사용하고
    프로그램적으로 특별한 가공을 하지 않았을 때,
      --> 최종결과물이 Asset Viewer에서 보는 것과 크게 차이 나지 않으며, 최종 데이타의 크기와 어플리케이션의 퍼포먼스가 익스포트 옵션이나 데이타 hierarchy 구조에 크게 영향을 받기 때문에 그래픽팀의 작업 방식이나 설정이 데이타 최적화에 일차적으로 영향을 미침 (팀 간의 feedback에 중요)
 
-.기본 렌더링 플레임부터 확인해 될 사항
   • Shader를 사용할 경우, 목표 사양에서(특히 저사양) 우선적으로 테스트
   • 기본 Node에서 파티클을 포함한 Effect가 제대로 화면에 나타나나지 확인
   • 캐릭터, 충돌이나 UI, 이펙트 등 중요 모듈이 추가되기 전, 후의 퍼포먼스 변화를 기록
 

1.캐릭터          ▲...
#.Design
    -.캐릭터와 관련된 무기, 방어구, 갑옷 등의 아이템과 힘, 속도 등의 속성치 아이템 등은 기술적이고 시각적인 요소인 동시에 수익모델과 직접적인 연관이 있기 때문에 최종아웃풋에 대한 명확한 기획이 중요
    -.avatar system; 헤어, 신발 등 9개 파트의 아이템 조합
        --> skined parts와 특정부위에 링크되는 parts로 구분
        --> 파트별로 별도의 draw call이 발생하기 때문에 과대할 경우 퍼포먼스 저하의 원인이 됨
    -.LOD에는 Mesh LOD와 Bone LOD가 있지만, 최대 8:8이라는 점을 고려하고, LOD를 사용할 경우 리소스 제작시 단계만큼의 추가작업이 필요하기 때문에 LOD는 적용하지 않음
    -.최소사양 고려
        • Bone의 갯수와 캐릭터 구성 Mesh face, texture 사이즈 테스트
        • legacy pipeline을 기본 렌더링 파이프라인으로 설정
        • 사운드와 이펙트 등의 리소스 최소화
        • Shader는 1.x버전을 사용; caroon과 silhouette edge 강조하는 shader 사용
            --> caroon은 밝은쪽 2단계를 사용(만화적인 표현 강조, 전체적으로 밝은 톤 유도)
            --> edge 표현을 위해 확대시켜서 2번 뒤집어서 그리는 방식(color로 적과 아군을 구분)
    -.애니메이션 상하 분리로 세분화
    -.무기에 따른 3단 콤보 구현(앞단계가 발동 후, 다음 단계 발동)
 
#.Shader 1.x으로 컨버트시 주의점
    -.조건
        • Gamebryo documentation을 보더라도 시멘틱 등에 관한 자세한 정보가 부족
        • NVIDA와 ATI 그래픽 카드마다 디폴트 셋팅 값이 다르고, 경우에 따라 화면에 표시되지 않음
        • Radeon x1000 이상 시리즈의 그래픽 카드와 그 하위 그래픽 카드 간에 경우에 따라 차이점이 있음
    -.참고
        • Gamebryo Sample에 포함된 shader관련 예제
        • 3ds Max에 포함된 shder관련 예제
        • 인터넷 등에서 수집한 shader관련 예제
    -.경험
      1) 기존 것을 RenderMonkey를 사용해서 shader 1.x 버전으로 컨버트 했으나 제대로 렌더링 되지 않음
      2) Gamebryo Asset Viewer에서 렌더링이 되지만 실제 어플리케이션에서는 렌더딩 되지 않음
      3) Gamebyro Sample 코드를 참고로 shader 코드 수정
      4) 어플리케이션에서는 정상적으로 렌더딩이 되지만 Asset Viewer에서는 edge가 보일듯 말듯함
      5) NVIDA에서 검게 렌더링(ATI와 기본 설정값이 다른 것이 원인, 기본값 세팅)
      6) Radeon x1000이하 ATI 그래픽카드에서만 렌더링되지 않음(설정값 추가)
      cf. 4), 5) 단계는 일일히 값을 넣어서 확인
 
#.Resource
    -.skined parts
        • 오브젝트와 참조하는 본만을 선택해서 익스포트
        • 버텍스가 참조하는 본의 갯수 최소화
        • 네이밍 규칙준수(특히, 대소문자와 끝에 공백이 들어가지 않도록 주의)
        • pivot의 위치와 방향에 주의
    -.Gamebryo Script Editor Dialog에서 필요한 Plugin을 등록
    -.보급형 19"LCD를 기준으로 작업
        • texture 색감이 CRT와 차이를 보임(특히, 밝고 어두움에 차이가 큼)
        • 큰 사이즈의 디스플레이에서 texture 작업할 경우, 필요이상의 세밀한 표현을 시도
    -.toon 풍이기 때문에 Normal map은 사용하지 않는다.  

2.배경             ▲...
2-1.세부 사항
#.Scene 크기
    -.4:4를 기준으로 원거리공격이 가능하고 전략적 게임진행이 가능한 크기
      필드가 너무 넓을 경우, 접속 인원이 적을 때 몰입도를 저하시켜 재미를 반감하는 요인이 될 수 있고
      상대적으로 테이타가 커지면 로딩시간과 메모리 사용량이 증가될 수 있다.
    -.Scene Graph를 위한 다른 로직을 사용하지 않고
      3ds Max에서 Group으로 구분되고 Gamebryo로 익스포트된 Data를 그대로 사용
      --> 기본적인 렌더링을 위한 Data 최적화는 결과적으로 그래픽쪽 작업을 통해서 선행
    -.Scene 크기를 고려, LOD를 적용하지 않고 최소 face를 가지도록 작업
 
#.Scene 구성
    -.모든 Node가 구분없이 scene root에 위치할 경우 퍼포먼스 저하를 가져옴
      (퍼포먼스 저하를 최소화하면서 화면 연출을 최대화시킬 수 있도록 지속적인 연구 필요)
    -.구분
      1) 렌더링 Node; 일정 크기로 분할
          • alpha testing/ blending이 필요한 오브젝트는 가능하면 따로 구성
          • 원거리 무기 ray 체크는 오브젝트 face별 체크를 병행(-->개선 가능 사항)
            ray 체크를 생략 가능한 오브젝트(예, 꽃, 나무잎 등)는 따로 구성
      2) 충돌설정 Node
          • 캐릭터 이동시 충돌은 충돌체 체크
          • 캐릭터 점프를 고려, 시각적으로 올라갈 수 있는지 명확히 구분 가능하도록 오브젝트 조정
      3) 필요에 따라 하늘과 바닥은 따로 익스포트
          • 지면 높이는 high field, picking을 통해서 실시간으로 산출
          • 하늘의 경우 다른 씬에서 사용할 수 있도록 따로 익스포트
 
#.Resource
    -.특정 color 제한
        • 이펙트에 사용되는 color는 가능하면 사용하지 않도록 제한
        • 캐릭터(아이템 포함)가 부각되도록 배경의 채도 등을 상대적으로 낮게 사용
    -.shader 사용하지 않음
        cartoon과 외곽선을 따로 그려주는 shader를 사용했으나 저급사양에서는 렌더링 부하에 비해,
        특히 큰 오브젝트에서 효과가 적었기 때문에 textuer를 수정을 통해 비슷한 느낌을 가지도록 수정
    -.texture 크기; 1024ⅹ1024 --> 512ⅹ512를 기본 크기로 사용
        로딩된 Data량이 하드웨어 제한 용량을 넘을 경우, 퍼포먼스 저하가 현저히 나타남
    -.꽃이나 나무와 같이 몇 가지 패턴이 반복적으로 사용될 경우, 3ds max에 Instance copy 방식을 사용
    -.Gamebryo Script Editor Dialog에서 필요한 Plugin을 등록
    -.toon 풍이기 때문에 Normal map과 Render to Texture를 사용하지 않는다.
      Alpha-Bendering Alpha-Testing
 
2-2.배경 필드 테스트 예; Bungee (개방형 씬)
    cf. 가장 렌더링 플레임이 떨어지는 곳에서 일정 방향을 향해 정지한 상태에서 측정
 
#.테스트
   • CPU ; AMD Athlon(tm) 64*2 Dual core Processor 4800+ 2.21GH/ RAM ; 3GB
   • VGA ; NVIDIA GeForce 6800 GS
  / 구 분 (파일크기) / 씬_메모리KB / 씬_FPS / 비 고
  / Bungee (149,574KB)
    -.Total Object: 2960
    -.Total Triangles: 130239
    -.Total Vertices: 83259
    -.NiGeometry Drawn: 574
    -.cartoon 버전/ Hf(64KB)
/ 325,323
 
 
 
 
/ 37.75
 
 
 
 
  / Bungee_Change Group (149,461KB)
    -.Total Object: 2385
    -.Total Triangles: 131096
    -.Total Vertices: 83169
    -.NiGeometry Drawn: 353
    -.No Cartoon/ Hf(64KB)
/ 321,193
 
 
 
 
/ 48.8
 
 
 
 
  / Bungee_Change Texture (40,277KB)
    -.Total Object: 2385
    -.Total Triangles: 131096
    -.Total Vertices: 83169
    -.NiGeometry Drawn: 353
    -.No Cartoon/ Hf(64KB)
/ 102,228
 
 
 
 
/ 48.53
 
 
 
 
 
#.목표사양 테스트 ; No Cartoon 버전에서 사용
   • CPU ; AMD Athlon(tm) XP 2500+ 1.83GHz/ RAM ; 1GB
   • VGA ; RADEON 9000 SERIES의 Philips 107T(107T2, 128MB)
  / 구 분 (파일크기) / 씬_메모리KB / 씬_FPS / 비 고
  / Bungee_No Cartoon (149,546KB)
    -.Total Object: 2955
    -.Total Triangles: 130289
    -.Total Vertices: 83279
    -.NiGeometry Drawn: 574
    -.Hf(64KB)
/ 317,359
 
 
 
 
/ 0.8
 
 
 
 
  / Bungee_Change Texture (40,277KB)
    -.Total Object: 2385
    -.Total Triangles: 131096
    -.Total Vertices: 83169
    -.NiGeometry Drawn: 353
    -.오브젝트 Group 재조정/ Hf(34KB)
/ 97,581
 
 
 
 
/ 30.68
 
 
 
 
  / Bungee (38,656KB)
    -.Total Object: 2421
    -.Total Triangles: 115832
    -.Total Vertices: 72096
    -.NiGeometry Drawn: 430
    -.copy 방식 교환/ Hf(94KB)
/ 94,781
 
 
 
 
/ 32.93
 
 
 
 
  / Bungee (38,656KB)
    -.Total Object: 2421
    -.Total Triangles: 115832
    -.Total Vertices: 72096
    -.NiGeometry Drawn: 430
    -.Hf(50KB)
/ 94,756
 
 
 
 
/ 36.53
 
 
 
 
  / Bungee (6,865KB)
    -.Total Object: 2429
    -.Total Triangles: 120744
    -.Total Vertices: 74633
    -.NiGeometry Drawn: 438
    -.Hf(50KB)
/ 26,130
 
 
 
 
/ 34.43
 
 
 
 
 
3.카메라             ▲...
#.TPS 시점-Third person shooter 3인칭 슈팅게임 cf.FPS-first person shooter 1인칭 슈팅게임
    -.3인칭 카메라가 캐릭터 뒤로, 우측 상단으로 일정거리 떨어진 시점으로 벽에 부딪칠 경우, 캐릭터에 링크된 방향으로 카메라가 밀리도록 구현
      --> 특히 직각으로 꺾이는 공간에서 부딪친 상태로 빠른 속도로 회전할 경우 벽에 묻히는 경우가 발생
         벽면이 갈라진 형태로 렌더링 (90% 정도 해결)
 
#.용도가 다른 2개의 카메라 사용
    -.Scene Rendering ; 캐릭터를 따라 다니는 3인칭 카메라
        • 대부분 렌더링마다 행렬변환 수정이 동반
        • 렌더링 호출 위치에 주의
        • 카메라 far-z 값을 최대한으로 설정해서 시계가 넓게 보이도록 설정
    -.정보 표시 ; 레이다 등 화면 구성을 위한 카메라 (고정카메라)
        • 피격 이펙트처럼 카메라 바로 앞에서 표시될 경우, 전체영역 픽셀처리를 수반하므로 큰 부하가 됨
        • 대부분 맨마지막에 렌더링/ z-buffer 속성 조정이 필요할 경우도 있음
 

4.충돌처리             ▲...
-. 게임브리오 Collision system은 detection만을 지원하기 때문에 충돌처리는 프로그래머가 직접 처리, 세밀한 처리를 위해서는 지속적인 R&D와 물리엔진 사용을 고려(Gamebryo 2.3은 PhysX 2.6.2 버전 지원)
      --> 상대 속도가 빠를 경우나 동적 체크가 필요한 경우 detection만으로 구현이 어려움
-. 충돌처리를 위한 셋팅은 3ds Max의 User Defined에서 ABV(Alternate Bounding Volume) 셋팅
    (예, "NDLCD SN My Sphere Bound")
-. 필요한 경우 충돌시 다른 이벤트를 발생, 사운드와 시각적인 이펙트로 표시
 
    / 캐릭터와 캐릭터 충돌 - 체크하지 않음
      --> 캐릭터간 충돌을 넣어서 테스트 했지만, 길막기와 같은 하드코어적인 진행이 게임성에 도움이 되지 않는다고 판단 충돌체크를 하지 않음
      --> 다른 캐릭터를 충돌체로 셋팅할 경우, 위치 보정을 위해 사용한 Dead Reckoning이 정확하지 않을 경우 캐릭터가 지속적으로 벽에 부딪쳐서 계속해서 callback을 발생
 
    / 캐릭터와 배경 충돌 - 체크
      --> 충돌에 소비되는 시간을 줄이고 단순화 시키기 위해, 자기 캐릭터만을 충돌체(Collider)로 설정하고, 다른 캐릭터는 피충돌체(Collidee)로 설정하기 때문에 캐릭터 간에 끼는 경우가 발생
      --> 다른 게임의 경우(S4리그) 캐릭터가 움직이지 않는 경우에만 충돌체크 (캐릭터 = 벽)
 
    / 근거리 무기에서의 캐릭터 충돌 - 체크
    / 원거리 무기에서의 캐릭터 부위별 충돌 - 체크
    / 원거리 무기에서의 배경 충돌 - 체크
 
    / 위험지역 셋팅 - 체크
      --> 처음에는 상하 충돌체크가 제대로 발생하지 않음(충돌로직 순서를 바꿈으로써 해결했지만 기존로직에서 이상이 없던 점프처리 부분에서 이상 발생으로 코드 수정)
      --> 셋팅은 3dsMax에서 충돌설정 오브젝트에 Extra Attributes를 추가 후 특정값 셋팅
            (하드웨어에 따라서 3dsMax가 셋팅 중 다운되는 경우가 많기 때문에 back up이 필수적)
 
    / 투척무기 - 게임브리오 샘플을 참고한 처리
      --> 물체에 충돌 했을 때 이벤트가 발생하도록 설정한 경우, 드물게 벽이나 바닥을 뚫고 지나가는 현상이 발생하기 때문에 안전장치로 타이머도 같이 설정
 

5.네트워크             ▲...
-.TPS 캐쥬얼게임이기 때문에 빠른 동기화와 Feedback이 필요
    • 경험상 3:3까지는 중앙집중 방식을 사용해도 play에 큰 문제가 없음
       (물론, 망 상태나 패킷량에 따라서 다름)
    • 유저가 많을 경우 P2P 방식이 필요
      --> P2P 도입에 따른 punching 등의 기술적 문제가 발생
      --> 망 구성과 유저 접속에 따라 비약적으로 증가하는 peer 처리 등의 처리로직 문제 발생
      --> 중요한 정보처리를 위해 client/server 방식도 병행
-.통신 쓰레더 구성 방식과 패킷 전송 횟수 테스트
    • 패킷을 너무 적게 보낼 경우, Dead Reckoning 등의 보간방법을 사용하더라도 동기화를 맞추기 어려움
    • 퍼포먼스를 테스트할 경우, 각 단계별로 시각을 남겨서 소요 시간을 확인
-.패킷량을 최소화 하기 위한 Data 최적화
-.P2P에서의 peer간의 통신상 정보 보완
-.네크워크 지연에 따른 보간 주체(통신단/ 클라이언트)에 따라 처리 구조가 달라짐
 

6.사운드             ▲...
-.Miles Sound 사용
    --> 버전에 따라서 옵션 설정에 주의(Gamebryo Sameple 참고)
    --> 개인적으로 2D, 3D를 지원하고 다양한 사운드 포맷을 지원하는 공개 라이브러리도 괜찮다고 여김
-.이펙트 사운드 사용시 다양한 사운드와 함께 리소스 크기도 염두에 두고 기획
    --> 배경음과 조화되도록 이펙트 사운드 크기를 조정(지속적인 feedback)
    --> background와 environment, effect, impact sound로 세분화
-.하드웨어 영향 등으로 사운드 재생시 초기에 지연현상이 있기 때문에 이펙트나 캐릭터 동작과 연관된 사운드는 어플리케이션에서 실제 테스트가 필요(특히 외주작업으로 진행될 때, 충분한 feedback 시간 고려)
 

7.이펙트             ▲...
-.우선 고려중인 최소사양을 기준으로 (visual/ sound)effect 계획
    --> billboard, 2D sprite, particle 등이 사용되는데 화면에 최대 몇 개가 렌더링 되는지가 중요
        (하드웨어 처리 용량을 넘을 경우 퍼포먼스 저하의 원인이 됨)
    --> 발생 이벤트에 대해서 대응되는 이펙트 검색이 쉽고 간편한 논리 구조로 구현
-.loop되는 굴뚝에 연기나 풍차 날개의 회전 같은 배경이펙트의 경우 백경씬에 같이 포함시켜서 익스포트
    --> scene root가 업데이트 될 때, 같이 업데이트
    --> 많은 요소보다는 특징되는 몇 개의 요소에 중점적으로 사용
-.화면에 렌더링 되는 경우에만 업데이트
    --> 피격 이펙트와 같이 카메라 바로 앞에서 전체 화면에 렌더링 되는, 알파처리된 이펙트는 하드웨어에 많은 부하를 발생하기 때문에 동시에 표시되는 경우를 최소로 줄임
    --> 어플리케이션에서 알파값이 제대로 처리 되지 않을 경우, AlphaProperty가 제대로 적용되는지 확인
 

8.UI             ▲...
-.Gamebryo 2.3의 ScreenTexture를 이용해서 관련 클래스를 생성
    --> texture 1장에 하나의 이미지를 처리하는 방식이라서 리소스 관리 상에 문제가 있을 수 있음
    --> 개인적으로 CEGUI와 같은 공개라이브러리 사용 여부도 초기에 테스트 해 볼만한 사항
-.채팅 등의 처리는 Gamebryo 2.3의 UnicodeCharacterSets 데모를 참고해서, ime 직접처리
    --> 경우에 따라 에러발생(여건상 완벽히 디버깅을 하지 못함)
-.UI가 퍼포먼스에 영향을 많이 주기 때문에 게임 내 정보표시는 최소화하고 알파처리는 되도록 피하고 전체적인 통일감을 잃지 안도록 주의
 

▶ 처음으로                      ▲...