AT2 클라이언트 사양.
짧은 시간만에 테스트해서 나온 결과라 얼마나 정확할지는 잘 모르겠지만 어쨌건 나름대로 분석해 봤슴당.

일단 그래서 나온 잠정결정. 결론부터 얘기하기.

• 권장사양.

CPU …………  Pentium4 Dual(=하이퍼쓰레딩: 가상으로 CPU를 2개인 것 처럼 돌림) 3.2GHz (프레스캇) 이상
RAM ………..  2Gbyte  
HDD …………  글쎄요 이건 나중에
VGA ………..   GeForce 7600 GS (256M) 이상
네트웍 사양……..  왠지 있어야 할 것 같다는

CPU 벤치마크 . 524점. 사실 이젠 추억속의 CPU

아이온의 권장사양이 Pentium Dual Core 이상으로 535점입니다. 대략 비슷한 정도로 보입니다. 
WOW 의 권장사양 역시 Pentium Dual Core, 2G , 8600으로 CPU는 비슷하지만 그래픽 카드는 와우의 사양이 더 높습니다. 
리니지2 의 권장사양은 코어2 DOU 6300 이상을 요구하고 있습니다. (대규모 공성전 때문인가) 압도적으로 높은 사양입니다. 
대신 메모리는1G로 낮고, 그래픽 카드는 7600으로 우리와 동일합니다. 
그라나도 에스파다는 역시 권장사양으로 Core2 Duo 를 요구하고 있고 메모리는 2G, 그래픽 카드는 8600 GT로 전체적으로 우리보다 높은 사양을 요구하고 있습니다.

이렇듯 일반적인 MMORPG와 비교하였을때 비슷하거나 살짝 가벼운 수준을 요구하고 있는 것을 알 수 있습니다. 
 

• 최소사양

CPU ………..  펜4 2.4GHz (노스우드)
RAM ………..  1Gbyte  
HDD …………  글쎄요 이건 나중에
VGA ………..   GeForce 6600 이상
네트웍 사양……..  왠지 있어야 할 것 같다는

최저 옵션에서 약 15프레임 이상을 유지하면서 게임을 진행할 수 있습니다. 옵션 조정이나 일부 데이터를 포기함으로써 최저사양을 좀 더 내릴 수 있는 여지도 있습니다. CPU 벤치마크 위치는 다음과 같습니다.

참고로
아이온의 최소사양이 Pentium4 2.8G 이며, 그래픽 카드를 Geforce 6600 이상을 요구하고 있습니다. 거의 사양이 비슷하거나 우리가 살짝 낮은 정도입니다. 하지만 아이온은 실제 이 사양에서 게임을 진행하기 거의 불가능합니다.
WOW의 최저사양은 Pentium4 1.3G 이며 메모리 1G , 그래픽 카드는 지포스 FX 이상을 요구하고 있습니다. 거의 AT1과 맞먹는 사양요구입니다. 사실상 이 사양에서도 현재의 AT2는 돌아는 갑니다만, 약 3-4 프레임을 보입니다.
리니지2의 최저사양은 ‘기본 사양’ 이라고 불리며, Pentium4 3.0 이상을 요구합니다 (아이온보다 높습니다) 메모리는 1G , 그래픽 카드는 6600 이상을 요구합니다. 게임을 업그레이드 하면서 사양도 대폭 증가해서, 이제는 최저사양이 아이온보다 높을 정도입니다.
그라나도 에스파다는 Pentium4 2G 이상을 요구하며 메모리 512M , 지포스 FX 이상을 요구하고 있습니다. 역시 AT2 보다 조금 낮은 정도입니다.

최저사양은 다른 게임과 비슷하거나 살짝 높은 정도이긴 합니다만, 최저사양으로 하더라도 현재 AT2는 ‘해상도를 떨어뜨리지 않고도 원활하게 게임 플레이가 가능한’ 수준을 기준으로 잡았으므로, 단순비교만으로는 쉽게 말할 수 없습니다. 
사실 같은사양에 지포스 FX5700 정도로도 원활히 플레이가 가능하였습니다만, 조금 여유를 두고 잡았습니다.

• 옵션

게임에서 사용할 옵션에 대한 제한 사양입니다.
가능한한 값싸고 효과좋은 옵션은 최후까지 남기고, 부하를 유발하면서 효과가 상대적으로 적은 옵션은 고급 사양으로 남겨둡니다. 또한 각 옵션은 커스텀으로 조절할 수 있도록 만듭니다.

• LOD

지형의 LOD 
터레인의 LOD은 자동으로 이루어 지고 있습니다. 그렇지만 통맵던전은 LOD가 이루어 지지 않습니다. 뭐 그래도 통맵은 어클루젼만 잘 처리해 준다면 터레인보다 가볍다는 것이 일반적 통설입니다. 통맵을 제작할 때는 이 점을 고려해 주시기 바라겠습니다.

건물의 LOD
 
기본적으로 건물은 굳이 LOD를 제작할 필요는 없습니다. 그렇지만 멀리 보이는 성 등은 LOD를 제작하는 것이 좋을 경우도 있습니다. 이런 경우에는 case by case로 처리해 주십시오. 저사양 옵션이 될 때 프러스컴 컬링의 Far 를 당겨서 처리합니다.

캐릭터의 LOD

캐릭터는 스키닝 부하가 퍼포먼스에 큰 영향을 끼치므로, 본 LOD와 매쉬 LOD 를 모두 사용해야만 합니다. 문제는 그래도 무겁다는 것인데… 필드에서 일부 거리이상 혹은 일부 개수 이상의 주인공급 캐릭터 (NPC는 제외) 가 보인다면, “렌더링을 포기하고 머리 위 이름만 나타나게 합니다.” 가장 직설적이고 무식한 방법이지만 효과는 최고로 좋은 방법입니다. 가까이 전진할때 로딩랙이 생길 것을 예상할 수 있지만, 분할로딩 방법이 가능한지 알아본다던가 등으로 해결하도록 합시다.  

• 기타 옵션

기타 옵션들은 다음과 같습니다. 일반적으로는 Bootcamp를 많이 참고했습니다만, 우리 게임의 특성에 맞도록 개조한 부분도 있습니다.
* 기본은 ‘일반’ 옵션입니다.

• 데이터 제작 가이드라인

다음은 그래픽 데이터를 제작하기 위한 가이드라인입니다. 다행히 엔진이 좋아서 수시로 현재의 데이터 상황을 체크할 수 있습니다.

배경

• 건물은 1개의 UV만 사용하십시오 2개의 UV는 라이트맵 연산에 문제를 일으킬 수 있습니다. 반드시 1개만 사용해 주십시오. 혹시 라이트맵이 특별한 UV를 사용하길 원한다면, 라이트맵을 위한 UV2를 만들 수는 있겠습니다. 담당팀장의 허가를 득하세요.

-  텍스쳐는 가급적 1개의 슬롯, 또는 2개의 슬롯을 사용해 주십시오 (멀티 - 서브 텍스쳐 사용을 최대한 자제해 주심시오)
만에 하나 커다란 건물이나 특별히 유니크한 건물에는 3개 이상의 멀티 서브 텍스쳐를 사용할 수도 있겠지만, 이 경우는 말그대로 매우 유니크한 경우로 제한합니다. 담당팀장의 허락을 반드시 득하시기 바랍니다.

• 엔진에서 [DrawCall] 수치를 민감하게 확인하십시오! 가벼운 오브젝트로 만들었다 하더라도 그 오브젝트가 너무 많이 보인다면 드로우 콜은 급격히 올라갈 것입니다. 반대로 무거운 오브젝트를 만들었다 하더라도, 화면에 그 오브젝트만 보일 정도로 크거나 시야를 가린다면 드로우 콜은 떨어질 것입니다. 이렇게 드로우 콜이 떨어지는 뷰라면, 텍스쳐 슬롯을 더 사용하거나 오브젝트를 축가로 더 설치해서 퀄리티를 높일 수 있습니다.

• 권장사양에서 원활하게 돌아갈 수 있는 적정한 드로우콜은 , 1000 정도입니다.(캐릭터까지 포함해서 권장하는 드로우콜은 1500 정도입니다)  가능한한 이 이하로 맞춰주시길 부탁드립니다. 재미있는 아이디어로는, 캐릭터가 많이 나오지 않을 것 같은 지역에서는 1000 또는 1100등과 같이 슬금슬금 더 높여 주셔도 됩니다. 반대로 사람이 많이 모일 것 같은 광장지역이나, 초반 마을 같은 경우에는 500 등과 같이 평소보다 적은 수치로 만들어 주시기 바랍니다.

• 표준건물의 폴리곤은 2500개 정도로 결정하였습니다. 이건 배경팀에서 표준 건물을 가지고 있을 것입니다. 물론 가능한한 적으면 좋습니다. 그렇지만 가급적 1000 이하의 오브젝트는 피해주시기 바랍니다. 너무 적은 폴리곤을 가지고 있는 오브젝트나 건물도 퍼포먼스에 좋지 않은 영향을 줍니다. 200 폴리곤짜리 오크통을 5개 늘어 놓는 것 보다는, 5개의 오크통을 하나의 오브젝트로 만드십시오.

캐릭터

• 캐릭터에서의 퍼포먼스는 거의 스키닝이 관건을 보이고 있습니다. 파츠별 구분도 상당히 중요한 관건을 보이고 있구요.
  때문에 폴리곤이 줄어든다면 퍼포먼스의 향상을 보일 수 있습니다. 그렇지만 너무 줄이기만 한다면 데이터 외형에 심각한 문제를 일으킬 수 있습니다.

• 주인공 캐릭터는 5000개 미만으로 사용할 것을 권고합니다. 할 수 있다면 3000대로 줄여도 좋습니다. Look 이 손상되지 않는 범위 내에서 최대한 줄여 주십시오. 주인공의 스키닝은 줄이면 줄일수록 프레임 향상이 큽니다.

• NPC나 몬스터 류 들은 상대적으로 캐릭터 보다는 부하에 대한 영향이 적습니다, 그렇지만 가능한한 줄여 주시는 것이 좋습니다. 유니티 엔진은 스키닝의 프레임 저하가 특히 큰 것으로 보고되었습니다.

• 몬스터의 Bone 개수는 특히 주의해 주십시오. 팔이나 다리가 많이 달린 몬스터는 퍼포먼스에 악영향을 줄 수도 있습니다.

• 물리에 대해서는 재 협상해야 합니다. 사용한다면 옵션에 따라 ‘사용할지 않을때’ 는 어떻게 처리해야 할지에 대한 얘기도 진행해야 합니다. 물리 에니메이션이 Bone 에니메이션으로 교체되는 것은 사실상 힘들기 때문에, 물리 에니메이션이 꺼질 때에는 ‘안 움직이는 ’ Attachment가 된다는 점을 고려해야 합니다. 추천은 ‘사용하지 않음’ 입니다.

• 당연하게도, 최대한 Texture 를 합쳐 주십시오. 배경과 마찬가지로, 가능한한 1장으로 처리해 주시길 권고하며 특이한 경우에는 2장을 사용하도록 조정해 주시기 바랍니다.

 기타 (이펙트 / UI)

이펙트나 UI 에서 고려할 내용들은 다음과 같습니다.

• 실시간 조명
  디퍼드 렌더링 방식에서는 실시간 라이트에 대한 부하가 매우 적은 것으로 알려져 있습니다. 기존의 포워드 방식의 랜더링에서는, 조명이 한 개가 추가된다면 게임에 있는 모든 Asset들에게 조명 연산을 추가로 해 줘야 합니다. (실제로 사용하지 않더라도 말입니다) 그렇지만 디퍼드 렌더링 방식의 엔진은,  화면에 보이는 것의 노말데이터를 따로 버퍼로 출력해 낸 다음 그 데이터만을 가지고 조명연산을 하므로 실시간 조명 연산이 필요하다 하더라고 포워드 렌더링 방식과는 비교도 할 수 없을만큼 빠르며 유동적입니다. 그렇다고 마구 사용하는 것은 물론 적절하지 않은 선택입니다. 가급적 꼭 필요한 곳에만 실시간 조명을 사용하시기 바랍니다.
  허용되는 실시간 조명은 포인트 라이트입니다.

• 파티클
  파티클은 예나 지금에나 부하를 유발하는 심각한 물건이었습니다. 가급적 파티클 사용을 자제해 주시기 바랍니다. 말은 이렇게 해도 사실 제작할 때 힘들다는 것은 알고 있습니다만…
  아래 옵션으로 내려가면 파티클을 제거할 수 있으므로, 이를 감안하셔서 되도록이면 파티클 사용을 자제해 주십시오.
  빨리 쉐이더로 지원해야 하는데….

• UI의 드로우 콜
  UI의 드로우 콜 점유는 언제나 심각한 문제였으며, 지금도 또한 그렇습니다. 가능한한 텍스쳐를 합쳐 주십시오. UI는 일반적으로 한 번에 로딩되며 바뀌는 일이 적기 때문에, 가능한한 모든 UI를 한 장의 텍스쳐로 넣는 것이 가장 이상적이긴 합니다. 다소 크기가 크더라도 그렇게 진행해 주시기 바랍니다.

• 변수  
  네트워크 환경과 엔진의 한계가 제일 큰 변수입니다. 웹게임을 한 번도 만들어 본 적이 없기 때문에, 데이터 스트리밍이 어떤 느낌으로 진행될지 알 수가 없으니까요. 그래서 웹으로도 제작되었던 Bootcamp를 일단 Base로 하고 만들었던 것입니다.
  잦은 로딩이 일어나야 하는 (전투맵) 우리 게임에서 이 엔진이 어떻게 반응할지 알 수 없습니다.