Game QA 진행요령

Game QA ?

QA : 품질 보증을 뜻하는 Quality Assurance의 약어

게임 QA : 게임(클라이언트)의 품질보증을 뜻하는 언어

통상 만들어진 게임의 기능이 잘 돌아가는지, 예외처리에 대한 버그발생은 없는지 등에 관한 레포팅을 작성하는 작업

 

게임에서는 탐구적QA와 기술적 QA로 나뉨

 

탐구적 QA?

  1.  예상되는 유저의 행동을 미리 실행해 보는 QA
  2.  예상해보지 못하도록 돌발행동을 실행해 보는 QA

★  이런 저런 행동을 하거나 클라이언트를 탐험하며 만들어진 클라이언트를 고찰하는 QA

 

기술적 QA TC(test case) List

  1. 만들어진 클라이언트가 계획대로 개발되었는지 확인하는 QA

★ 정상적인 실행에 맞춰 해당 기능이 정상적으로 개발되었는지 확인하는 QA

해당 클라이언트의 TC(test case)를 만들어 작성하는 편이 빠짐없이 체크해 볼 수 있는 좋은 예

 

 

※ QA는 품질보증인 만큼 사용자의 환경도 고려하며 진행하면 더욱 버그나 예외처리에 관한 부분을 확실히 집어낼 수 있습니다.

웹용으로 개발한다면 웹을 구동시킬 수 있는 브라우저의 종류를 고려한다거나 모바일용으로 개발한다면 스마트폰제조사or 스마트폰 종류 or 패드지원 등을 고려한다거나 하는 사용환경을 고려한다면 보다 확실한 QA가 될것입니다.

Unity3D Create And Download AssetBundle

에셋번들의 생성부터 적용과정, 간단한 관리에 대한 설명과

프로젝트에 에셋 번들을 적용하는 과정에서 생긴 이슈에 대한 글입니다.

에셋 번들의 사용 목적

대부분의 개발자들은 다음과 같은 목적으로 AssetBundle을 적용하려 할 것입니다.

  • 클라이언트 APK를 Resource와 분리시킨다. (APK 용량 감소를 통한 마켓 업로드)
  • Resources폴더의 파일을 최대한으로 줄여 메모리(RAM) 사용량을 감소시킨다.
  • 에셋 번들 버전 업데이트를 통해 APK 교체없이 Prefab, Model 데이터를 변경한다.

제작시 고려 사항

  • 에셋 번들의 데이터 및 버전은 어떻게 관리될 것인가 ?
  • Network와의 연결이 불안정할 경우 예외는 어떻게 처리할것인가 ?
  • Android, IOS 에서 파일 관리는 어떻게 이루어질 것인가 ?
  • Prefab간 상호 의존 (Dependence)에 따른 로딩 순서 및 로딩은 어떻게 이루어 질 것인가?

제작 과정

  1. 에셋 번들 생성 스크립트
  2. 에셋 번들 Export
  3. NAS 또는 HTTP 업로드 후 다운로드
  4. 더 개선할 방향 및 Dependence 관리

에셋 번들 생성 스크립트

구글에 검색시 대표적으로 나오는 코드중 한개입니다.

캡처

주의 : Project/Editor 폴더에 해당 스크립트를 생성해야 합니다. 그렇지 않을경우 에러가 발생합니다.

해당 코드를 생성, 저장 한뒤 유니티 에디터를 확인하면 다음과 같은 메뉴가 생성됩니다.Button.png

앞으로 이 버튼을 이용해서 에셋 번들을 생성하게 됩니다.

에셋 번들 Export

에셋 번들을 생성하고자 하는 프리팹을 선택한뒤 Inspector 창을 보면 다음과 같은 부분이 보입니다.

Inspector

Prefab으로 만들어져 있는 대상에서만 다음과 같이 보이게 됩니다.

밑의 AssetBundle을 보면 hawaii_couse라고 되어있습니다. 현재 이 프리팹은 추출하게 되면 hawaii_couse라는 에셋 번들로 추출됩니다. 사진과 같이 설정하기 위해서 먼저 AssetBundle 오른쪽의 hawaii_couse가 적혀있는 칸을 클릭하세요

AssetBUndle2

아직 설정이 되어있지 않다면 None으로 되어있을 것입니다. New버튼을 누른다음 자신이 원하는 이름으로 설정해 주세요 원하는 이름을 작성한뒤 엔터를 누르면 해당 이름으로 설정됩니다.

  1. 사용하지 않는 이름은 지우고 싶다면 Remove Unused Names를 클릭하면 자동으로 사용하지 않는 이름을 모두 지워줍니다.
  2. 한개의 에셋 번들에 여러 프리팹의 데이터를 담고싶다면 프리팹들의 에셋 번들 이름을 같은 이름으로 설정하면 됩니다.

설정이 끝났다면 방금 만든 메뉴버튼을 클릭, 파일로 Export 합니다. 추출된 파일은 Project 탭에서 AssetBundles 폴더에 담기게 됩니다. 추출이 끝났다면 탐색기에서 다음과 같은 파일들을 확인할 수 있습니다.

탐색기.PNG번들은 1개 생성되었지만 파일은 8개 있습니다. 여러분이 실질적으로 사용할 파일은 hawaii_couse 입니다. 다른 이름으로 지정했다면 해당 이름으로 생성된 파일입니다. manifest, manifest.meta, meta 파일은 실질적으로 사용할 일이 없으며 버전 관리가 필요할 경우 AssetBundles 파일을 이용하면 좀더 간편하게 할 수 있습니다. (에셋 번들을 생성할때 번들들에 대한 정보가 들어있습니다.)

NAS 또는 HTTP 업로드 후 다운로드

서버가 구축되어 있지 않거나 간단한 테스트를 원하는 상태라면 NAS를 연결, 이용하거나 CAFE24와 같은 호스팅센터를 이용해서 파일을 업로드 하세요. 유니티에서 에셋번들 데이터를 다운로드 하기 위해서는 URL 주소가 필요합니다. 단순히 실험만 할것이라면 file://C:\Users 와같은 경로로 설정해도 테스트는 할 수 있습니다. 이번 문단에서는 NAS 또는 HTTP에 있을때 받는 과정을 살펴보겠습니다.

현재 에셋 번들을 받을 수 있는 다양한 다운로드 방법이 있습니다. UnityWebRequest를 이용할 수도 있지만 LoadFromCacheOrDownload를 통해서도 쉽게 적용이 가능합니다. 후자의 방법을 이용해서 구현하면 다음과 같은 코드가 나오게 됩니다.

AssetBundle.PNG

Caching 준비가 되길 기다린뒤 준비가 된다면 WWW를 이용해 다운로드 하게 됩니다. url은 에셋번들을 업로드한 주소를 넣으면 됩니다. (파일에서 업로드 할 경우 file:// + 파일 경로를 입력해주면 됩니다) version을 따로 관리하지 않는다면 1을 넣어서 테스트하면 됩니다.

LoadFromCacheOrDownload는 여러분이 빌드할 기기의 스토리지에 에셋번들 파일을 저장하게 됩니다. version이 같은 파일이 이미 존재할 경우 다운로드 하지 않고 캐쉬에 있는 데이터를 사용하게 됩니다. version이 더 높을경우 해당 에셋 번들을 다운로드 합니다. (주의 : 구버전의 캐쉬 데이터를 자동으로 지워주지 않습니다.)

이제 번들을 다운로드 받았으니 인스턴스로 생성해보겠습니다.

인스턴스화bundle.LoadAsset함수를 실행한뒤 Instance로 만들 Prefab의 이름을 넣어주세요. 이때 Prefab의 이름은 Project뷰 또는 Hierarchy뷰에서 보이는 이름 그대로 작성하면 됩니다. Instantiate(bundle.LoadAsset(prefabName)) 과 같이 생성해도 되며 사진과 같이 다른 GameObject에 담아둔뒤 복제해서 사용 해도 됩니다. 주의할점은 밑의 bundle.Unload() 함수입니다.

bundle.Unload(false)를 실행하게 되면 에셋 번들 데이터는 메모리에서 해제됩니다. 하지만 현재 씬에 오브젝트가 사용되고 있다면 해당 오브젝트는 씬내에서 그대로 유지됩니다 (주의 : Unload 한뒤 bundle.LoadAsset을 다시 실행하게 되면 로드되지 않습니다. 그 이유는 이미 Unload했기 때문입니다. 만약 다시 생성을 원한다면 AssetBundle을 이전과 같이 로딩하거나 어느곳에서 참조를 가지고 있어야합니다.)

bundle.Unload(true)를 실행하게 되면 에셋 번들 데이터 뿐만이 아니라 현재 생성된 Instance 들도 모두 null로 전환됩니다. 일반적인 상황에서는 bundle.Unload(false)를 많이 사용합니다.

이러한 방법을 통해서 에셋 번들을 통해 인스턴스를 간단하게 생성해 봤습니다.

더 개선할 방향 및 의존성(Dependence) 관리

에셋 번들은 만드는 것보다는 관리되어지는게 더 중요합니다. AssetBundle Using Pattern 이라고 검색하면 다양한 문서들을 참고할 수 있습니다. 이 문단에서는 간단하게 소개하겠습니다.

에셋 번들을 어떠한 기준으로 쪼갤것인가 ?

에셋 번들 안에 들어있는 프리팹 한개가 변경된다면 여러분은 해당 파일을 업데이트 해줘야 할것입니다. 대체적으로 에셋번들은 두가지 방법으로 나뉩니다. 1. 적은 용량으로 여러개의 에셋 번들을 구성 2. 큰 용량으로 적은 개수의 에셋 번들을 구성

주의할점은 에셋번들을 관리하는 것 뿐만이 아니라 에셋 번들을 Unity에서 로드할때 파일 입출력으로 인한 오버헤드가 발생된다는 점입니다. 실질적으로 로드할 데이터는 적지만 파일이 여러개 나뉘어져 있다면 파일 입출력에 더 많은 시간을 사용 -> 로딩시간 증가로 이어질 것입니다. 반대로 큰 파일로 구성되어 있다면 업데이트마다 다운로드에 많은 시간이 소요될것입니다.

“나무”라는 프리팹을 A가 사용하고 B도 사용하는 상황에서 에셋번들로 각각 추출하면 어떻게 될까요 ? A에도 나무의 데이터가 담기고 B도 나무의 데이터가 담기게 됩니다. 이렇게 상호 의존하는 상황이 생겼을때는 어떻게 해야할까요 ? 에셋번들이 다른 에셋번들을 참조해야 하는 상황일 수도 있습니다. 하지만 유니티에서는 자체적으로 이러한 의존성(Dependence)에 맞춰 순서를 변경, 로드 해주지는 않습니다. 이는 전적으로 개발자가 Custom Loader를 만들어서 해결해야 합니다.

에셋 번들 브라우저.PNG현재 유니티 스토어에 있는 번들 브라우저를 이용하는 것도 좋은 방법일 수 있습니다. 트리구조로 상호 의존 관계를 명확하게 한뒤 중복되는 요소를 최대한 줄여 에셋번들 용량 증가를 방지할 수도 있습니다. 해당 에셋은 5.6이상에서 사용되며 다양한 툴들이 많이 나와있고 Unity에서도 해당 부분을 인지하고 좀더 편하게 개선되는 과정이니 기다리면 더 좋아질 수 있습니다.

지금까지 단순한 방법으로 에셋 번들을 생성, 인스턴스화 해봤습니다. 더 발전한다면 적은 에셋번들의 개수로 용량 증가 없이 효율적으로 관리가 가능해질 것입니다.

애자일 개발방법론

게임개발에 반드시 도입되어야 하는 개발방법론이라고 생각합니다.

게임은 정말 다양한 아이디어와 기술의 집합체라고 생각합니다. 하지만 그만큼 직접 눈으로 보고 플레이하기 전에는 확인해보기 어려운 내용이 많습니다.

 

프롬더레드에서는 애자일 프로세스를 점진적으로 도입하여 추후 모든 프로젝트의 기본 개발 프로세스로 정착해 나갈 예정입니다.

추가로 애자일 프로세스에 대해 잘 정리한 글이 있어 공유 드립니다.

(하지만 애자일이 천하무적은 아닙니다. 제대로 파악하지 않고 덤비면 open the hell gate. 다음 번에는 애자일의 단점과 불편한 진실에 대해서도 공유 드리겠습니다.)

 

애자일 개발방법론 (Agile Development Methodology)

이 글은 한글 번역본입니다.

(출처: http://agilemethodology.org/)

애자일이란?

애자일은 방법론이 아닙니다!

애자일은 기민한, 좋은 것을 빠르고 낭비없게 만든다는 뜻인데요,

애자일 방법론은 전통적 프로젝트 관리 방법인 폭포수 모델,

혹은 순차적인 개발방법을 대체하는 또 다른 방법입니다.

애자일 처리 방법은 반복적인 일과 경험에 의거한 피드백을 통해서

예측 불가능한 일에 대응할 수 있도록 도와줍니다.

(출처: www.livnara.com)

스크럼이란?

스크럼은 애자일 개발 과정의 하나로, 단순함과 융통성 때문에 가장 인기있는 방법론입니다.

이러한 인기 덕분에, 많은 조직들이 “스크럼”을 한다고 하는데요,

사실 “정확한 스크럼”방법론을 이용하는 것은 아닙니다.

스크럼의 정확한 정의는 경험에 의거한 피드백, 팀의 자가적인 관리,

그리고 짧은 반복을 통해서 적합한 제품 테스트에 중점을 두는 개발방법론입니다.

스크럼은 애자일 방법론을 이용하지 않는 조직에게는 맞지 않을 때가 많습니다.

(출처: en.wikipedia.org)

스크럼은 세 가지 역할이 있는데요, 제품 책임자, 팀, 그리고 스크럼 마스터 입니다.

이는 Michale James의 The Scrum Training Series에 설명되어 있습니다.

전통적인 프로젝트 관리자의 역할은 이 세가지로 나누어져 있습니다.

또한, 스크럼은 다섯개의 진행 방법이 있습니다:

제품 백로그(Backlog Grooming), 스프린트 계획(Sprint Planning), 일일 스크럼(Daily Scrum),

스프린트 검토 회의(Sprint Review Meeting), 그리고 스프린트 후행 회의(Sprint Retrospective Meeting)입니다.

스크럼 개발방법론을 시작하는 방법 중 하나는 Scrum Training Series인데요,

(Scrum Training Series: http://scrumtrainingseries.com/)

애자일 방법론을 진행할 수 있는 인기있는 방법들을 다루고 있습니다.

또한, 6페이지의 Scrum Reference Card를 다운 받을 수 있습니다.

(출처: svsg.co)

애자일의 역사

1970년 Winston Royce 박사가 논문(“Managing the Development of Large Software Systems”)에서

애자일에 대해 발표하며, 전통적인 순차적 개발 방법을 비판했습니다.

그는 소프트웨어는 자동차를 조립라인에서 생산하는 것과 다르게 개발되어야한다고 주장했습니다.

자동차는 일련의 차례를 기반으로 생산이 되어서, 각각의 단계가 마무리 되어야만 다음 단계로 넘어갈 수 있습니다.

Royce 박사는 이러한 단계적인 방법을 반대하면서,

개발자들이 먼저 프로젝트의 필요사항들을 수집하고,

모든 아키텍쳐와 디자인을 완료한 후에, 코딩을 작성하는 방법 반복적으로 해야한다고 주장했습니다.

Royce 박사가 특히 전통적 방식에 반대하는 이유는 순차적으로 일을 하게되면,

각각의 단계의 일을 수행하는 사람들 사이에서 소통이 없어지기 때문입니다.

 

(출처: vesti-kareliya.ru)

애자일 개발방법론과 비교해보았을 때, “폭포수 모델” 혹은 순차적 개발 방법이

최적화된 방법과는 거리가 멀다는 것을 알 수 있습니다.

첫 번째로, 전통적 방식은 디자인이나 코딩 전에 프로젝트에 필요한 모든 요인들을 다 파악할 수 있다고 가정합니다.

다시 말하자면, 과연 소프트웨어가 실행되기도 전에 필요한 모든 부분을 개발자 팀에게 알려줄 수 있을까요?

소프트웨어 기능을 실행해보고 나서 더 쉽게 알려줄 수 있지 않을까요?

많은 소프트웨어 개발자들은 지금까지 더 어려운 방식으로 일을 해왔습니다.

프로젝트 과정 끝에 그 개발자 팀은 요구된 소프트웨어를 다 만들었을지도 모르지만,

그 동안 비즈니스 사회는 크게 달라져서 완성 되고 난 시점에서 그 프로젝트는 가치가 떨어졌을 것입니다.

이 경우에서 회사는 많은 돈과 시간을 투자했지만 누구도 원하지 않는 소프트웨어를 만든 것입니다.

이를 해결할 수 있는 방법이 바로 애자일 개발방법론을 사용하는 것입니다.

(출처: designshack.net)

왜 애자일 개발방법론을 써야 할까요?

애자일 개발방법론은 개발 주기를 통해 프로젝트의 방향과 목표를 가늠하도록 도와줍니다.

이는 반복적인 주기(스프린트)를 거쳐서 이루어지는데요,

과정 후에 마지막에 실행 가능한 제품을 발표합니다.

단축된 일의 반복과 제품 기능에 중점을 두기 때문에

애자일 개발방법론은 “반복적”이고 “증가적”이라고 표현됩니다.

폭포수 모델에서 개발자들은 한 번의 기회만으로 프로젝트의 모든 측면을 검토해야합니다.

반면에 애자일 패러다임에서는 일정한 주기를 통해 계속적으로 모든 측면을 재검토 할 수 있습니다.

예를 들어서 2주마다 프로젝트의 목표를 재검토 했을 때 고쳐야 할 점이 있다면,

처음과는 또 다른 방향으로 전환할 기회가 있는 것이죠.

(출처: agilefellow.com)

이러한 “inspect-and-adapt” 개발방법은 개발 비용과 시간을 크게 줄여줍니다.

개발자들은 소프트웨어를 개발하는 동시에 필요한 부분을 수집하기 때문에.

초반에 정보 과다로 인해 분석을 하지 못하는 일은 생기지 않습니다.

애자일 개발방법론은 회사가 적합한 제품을 만드는 것을 도와줍니다.

아직 다 완성되지 않은 소프트웨어가 시장에 출시되는 것을 막고,

제품의 출시를 계속해서 재검토하고 다시 계획을 세우게 만들어

다시 개발을 통해서 그 가치를 최적화할  수 있도록 도와줍니다.

또한 시장 경쟁령을 갖추도록 만들어줍니다.

애자일 방법론을 이용하는 개발은 제품의 시장 적합성을 보존하며,

팀의 일이 헛수고가 되지 않도록 보장합니다.

출처: http://flearning-blog.tistory.com/230 [플러닝 Flearning]