Game Development ProcessC3%D6%C0...Effective Development Methodology and its Process Choi, IL Kon...

Effective Development Methodology and its Process

Choi, IL Kon Ph.D [email protected]

Game Development Process

TEL +82-2-3413-1000FAX +82-2-3413-1111

www.joyon.com

Game Development Process

PDF created with FinePrint pdfFactory Pro trial version http://www.pdffactory.com

mailto:[email protected]

http://www.joyon.com

http://www.pdffactory.com

Contents

I. Overviewa. 목표

II. 기존 개발의 문제점진단a. 초기 게임 회사의 생성b. 일반적 게임회사의 문제점들

III. 게임개발 프로세스의 실제a. SCM의 필요성b. 게임소프트웨어 개발 프로세스

IV. 프로젝트의 운용과 관리a. 프로그래밍 디자인과 공정 관리b. 외주 개발의 공정 관리c. 서비스 공정 관리

V. Support Toolsa. ClearCase / ClearQuest (SCM Tool) b. Doxygen (Documentation Tool)c. MS-Project (PM Tool)

VI. Q&A



A. Purpose

OVERVIEWI.



A. Purpose

I. OVERVIEW

A. Purpose

기존 개발방법론의 문제점은 없는가 ?

있다면, 가장 현실적 대안은 ?

새로운 개발 프로세스의 정립과

효과적 개발방법론을제시한다면 ?



기존 개발의 문제점 진단

II. A. 초기 게임 회사의 생성

B. 일반적 게임 회사의문제점



A. 초기 게임회사의 생성

II. 재 낳 송 단

A. 초기 게임회사의 생성B. 일반 게임회사의 문제점

1. 유저에서 개발자로…

- 게임을 열심히 플레이하던 유저가 개발자로 전향하는 경우가 많았음- 팀원의 조직 : 개인적 유대, 같은 취미/공감대의 소유자- 전공이나 공학적 접근 보다는 만드는데 우선함- 산업화에 대한 염두에서의 출발이기 보다는 개인적 만족감에서의 출발

2. 소규모 개발 / 시장의 영세성

- 점차적으로 산업화로 진행됨- 시장 자체가 그리 큰 편은 아니었음, 개발사 역시 많지 않았음- 소규모 개발 인력, 소규모 스케일의 게임 개발- Human Resource에 의존한 개발이 진행됨

3. 패키지 개발 / 오프라인 유통

- 패키지 위주의 단품 개발이 주를 이루었음- 유통사에 의존한 오프라인 유통이 주를 이루었음- 개발사가 얻는 이윤이 적었음




II. 재 낳 송 단

B. 일반 게임회사의 문제점 (1)B. 일반 게임회사의 문제점

1. 체계화/합리적이지 못한 개발 프로세스

- 태생의 문제점 : 비전공, 비공학적 개발 접근- 게임의 질보다는 순간의 편이를 위해 확장성을 고려하지 않은 개발- 잦은 기획의 수정 / 수정을 수용하기 힘든 프로그래밍- 설계에 대한 낮은 가치 부여 / 비문서화- 낮은 품질 : 부족한 테스트 : 무수한 버그들- 같은 실수의 반복

2. 반복되는 비능률적 개발의 사례

보여주기위주개발계획 개발단계

설계나 공정은 눈에 보이지 않는다.

불 필요한 것, 시간낭비

기획과 프로그래밍 동시 진행

기획을 제대로 고려하지 못한 코딩

기획적 추가 수정이 어려움

출시서비스단계

기본 엔진의 버그 + 콘텐츠 추가

버그 시너지 – 출시는 가능할까?

회사의자금난

개발경험부족

무리한스케줄

구현위주, 하드코딩

엔진과 콘텐츠가 덩어리화

잦은 장애, 유저의 항의

지속적 디버깅 + 콘텐츠 추가

끝이 보이지 않는 디버깅…

개발기간의 지속 증가

자금압박… 계속해야 하는가?




II. 재 낳 송 단

B. 망 냔 사 송 (2)B. 일반 게임회사의 문제점

3. 인력/조직 관리의 문제

- 극소수 개발자에 의존하는 개발 체계- 합리적이지 못한 일정 수립과 개발의 지연 / 기술력에 대한 낙관적 판단- 계획된 공정에 따른 인력수급계획 부재- 각 개발팀간의 커뮤니케이션의 문제- Project Management에 대한 이론적 접근의 실패- 역할 분담의 문제 (영세성, 필요성의 문제)- 개발 업체의 영세성 vs 게임 스케일

4. 재활용의 부재

- 매번 같은 류의 게임에서도 같은 작업을 처음부터 진행- 제작 단가, 개발 기간의 상승- Code Base / Resource Base의 부재

5. 범하기 쉬운 실수…

- 눈에 보이는 것이 다가 아니다. -> 무수히 많은 경우의 수와 잠재된 버그들- 기간을 당기려고 감행한 구현위주의 운영은 결국 더 많은 유지보수, 디버깅 시간을 만든다.- 모든 작업은 철저하게 계획에 의해서 진행되어야 한다. – 단기적 성과에 환상을 가져선 안된다.- 또한 모든 공정은 철저하게 체크되어야 한다. 단계별 검수는 개발자와 회사를 위해 필요하다.- 이것이 사람을 믿지 못하는 것과는 구별되어야 한다.



게임 개발 프로세스의 실제

III. A. SCM의 구축과 필요성

B. 게임 소프트웨어 개발 프로세스



A. SCM의 구축과 필요성

III. 냔 낳 쟁 벼스 실

A. SCM(Software Configuration Management)의 구축과 필요성 (1)B. 게임 S/W개발 프로세스

1. SCM의 개념

- 소프트웨어형상관리(SCM)은 소프트웨어개발도중에산출되는모든개발자산을체계적으로관리하는솔루션으로대규모개발프로젝트에꼭필요한솔루션이다.

- SCM은구축중인소프트웨어나시스템에대한식별, 검색, 제어의기술이다.- 소프트웨어개발과정을통제하는프로세스- 대부분의프로젝트에서나타나는혼란을제어하는메커니즘이다.- 인력소모를줄이는방법이다.

2. SCM 도입의 장점

- 프로젝트와제품에있는복잡성과요구를제어하는방법이다.- 시스템의버그수를감소시킴으로써좋은품질의소프트웨어제품을배포하는향상된방법이다.- 더빠른문제식별과문제해결을가능케한다.- 구축되고있는시스템이요구사항과시스템구조다이어그램에서정의되었던시스템이라는안정성을제공한다.

- 모든 프로젝트산출물과변경사항들의추적가능성을제공한다.

3. 실제 구축

- 자체구축 (조직에맞는커스터마이징)- SCM Tool의활용 (Tool Part에서소개)



A. SCM의 구축과 필요성 A. SCM(Software Configuration Management)의 구축과 필요성 (2)B. 게임 S/W개발 프로세스

4. 실제구축을 위한 방법론

- 소프트웨어공학의한부분 – 수행할작업에대한분석을기반으로프로젝트에적용해야할규칙의집합이다.

- 단순한프로젝트결과물의버전관리이상의기능을수행 – 변화관리자필요-> 프로젝트는지속적으로변화될수있기때문에… 이를관리, 통제할필요가있다.

- SCM은형상항목을식별한후물리적이고기능적인특성들을문서화한다. (소스코드, 모듈, 서드파티소프트웨어, 데이터, 문서등과같은것)

- 크기, 기능, 라이브러리같은물리적특징뿐만아니라, 각결과물의목적및 특징과같은기능적특성을문서화한다.

- 산출물에대한변경은 CCP(Change Control Process)를 따른다. - SCM은행해지고있는작업을못하게하는것이아니다. -> 프로젝트산출물로만들어지는변경이나작업을제어하는것이다.

- 프로젝트의변경을위해변경요청 CR(Change Request)을 CCP 담당자에게요청하며검토후타당하다고판단될때변경승인을한다.

- 대기중인사안은대기중인큐에보관하며, 차후다시검토할수 있다.- 모든 CR은 문서화되어개발주기동안 검색될수있어야한다.

- 프로젝트의각구성원들은제안된변경, 각요청에따른설명, 요청과관련하여구축해야할내용을알고있어야한다.

- 언제든지프로젝트구성원들이이정보를쉽게이용할수있어야한다. - SCM은설정했던기획설계에따라애플리케이션이만들어지고있는지주요시점(마일스톤)에서감사를수행한다.




A. SCM의 구축과 필요성 A. SCM(Software Configuration Management)의 구축과 필요성 (3)B. 게임 S/W개발 프로세스

5. SCM 기반의 소프트웨어 개발 단계

프로젝트시작단계

- 개발팀 셋업- 프로젝트 표준의 형식화와 문서 템플릿 작성- 프로젝트 방향과 관련된 결정들- 강화될 표준들, 버전관리와 관련된 템플릿- 변경제어 프로세스(CCP)의 구성

요구사항단계

- 개발과 관련한 요구사항 수집- 기능적 명세서 추출- 비기능적 명세서 추출- RDD(요구사항 정의문서)로 문서화

기능적 기준선의 생성

고수준설계단계

- 제안된 시스템을 모델링- 시스템 구조 다이어그램 산출- 데이터베이스의 구축과 정규화- 고수준 설계 문서 작성

저수준설계단계

- 각 시스템 별 모듈에 대한 명세서 작성- 유닛 테스트 방법론 설정- 저수준 설계 문서 작성

초기 기준선의 변화가 있음

설계가 구체화 되면서

개발/구축 단계

- 설계된 시스템과 컴포넌트의 개발- 개발된 컴포넌트의 테스트 : 안정화- 테스트 완료된 컴포넌트와 매뉴얼- 버전 컨트롤, CCP 활용

테스트단계

- 조합된 컴포넌트의 시스템 테스트- 시스템의 요구사항대로 잘 작동하는가?- 알파테스트 / 베타테스트- 테스트 보고서

유지보수




A. SCM의 구축과 필요성 B. 게임 소프트웨어 개발 프로세스 (개괄적 도식) (1)B. 게임 S/W개발 프로세스

시장구조의파악 게임초기디자인

초벌게임디자인

초벌테크니컬디자인

기획과예산의조정

개발승인단계

게임디자인

게임디자인

테크니컬디자인

게임개발 (파트별)

그래픽

프로그래밍

사운드및기타리소스

프로듀싱 그룹

통합화 품질테스트

밸런싱 / 내부테스트

외부테스트

스트레스테스트

완성도검수

Alpha/Beta Test

밸런싱조율

정식서비스




A. SCM의 구축과 필요성 B. 게임 소프트웨어 개발 프로세스 (2)B. 게임 S/W개발 프로세스

1. 시장 구조의 파악

- 시장을제대로이해하고있는가?

- 어떤시장에진입할것인가?

- 누구를대상으로할것인가?

2-1. 게임 초기 디자인 (디자인 기획서)

- 라이센스또는순수창작품- 게임플레이- 신규플레이어를위한기능- 경쟁제품- 인적자원- 핵심인력- 스케줄- 예산

- 장르- 그래픽사양- 인터페이스스타일- 엔진- 데이터베이스- 대상 소비자- 클라이언트플랫폼- 호스트플랫폼





2-2. 게임 초기 디자인 (초벌 게임 디자인)

- NPC 종류와목록- 몬스터의유형과게임에등장하는전체몬스터의목록

- 각퀘스트의구체적인내용- 작업목록- 필요인원- 기본적인일정표- 개발과론칭에필요한기본 예산안

- 백그라운드스토리- 플레이어인터페이스디자인- 캐릭터정보- 캐릭터생성과성장절차- 지리정보와현경- 게임메커니즘- 그래픽스타일가이드- 아이템과플레이어가만들수 있는물건의전체목록

2-3. 게임 초기 디자인 (테크니컬 디자인)

- 소프트웨어- 툴- 게임 서버호스팅에필요한것들- 회선대역폭- 작업 목록- 기능 목록

- 필요인원- 일정초안- 프로토타입목록- 테크니컬리스트분석- CCP (Change Control Process)





3. 기획과 예산의 조정 (프로젝트 승인 단계)

- 초기비용- 예산조정과투자대비비율- 인력관리와고용- 제품과서비스의차이- 개발과론칭에필요한예산짜기- 이시점에서정확한일정을예측하기는힘들다. (가늠/목표)

4. 게임 디자인 및 설계

- 초벌디자인에서설정한내용에대한구체화- 프로그래밍설계 : 최대한구체적으로예상가능한모든것을설계한다.

5. 게임 개발 및 통합화

- 각파트간의지속적, 시스템적커뮤니케이션을통한개발 – SCM의활용- 개발에따른문서화- 모든개발은최소화시킬수있는작업 단위(Task Unit)로나누며, 각단위별 진행상황을점검- 마일스톤을정하며, 이것만은반드시지킬수있도록진행시킨다. - 파트별세부지침은 IV.에서다룬다.

6. 품질 테스트

- 전문화된테스트프로세스에따라진행- 외부공개이전에안정성을확보한다.

프로젝트의지속적진행여부를결정(경제성/흥행성가능성검토)




프로젝트의운용과 관리

IV. A. 프로그래밍 디자인과 공정 관리

B. 외주 개발의 공정 관리

C. 서비스 공정 관리



A. 프로그래밍 디자인/공정

IV. 쟁 운용과 리

A. 프로그래밍 디자인과 공정관리 (1)B. 외주 개발의 공정관리

C. 서비스의 공정관리

1. 프로그래밍에 있어 UML을 활용한 디자인/설계

- 전체프로그램에대한이해를높인다.

- 작업분담을명확히할수있으며, 모듈간흐름을명확히한다.

- 객체지향적설계가가능해진다.

2. UML의 기본

- Basic UML Diagrams : 케이스 다이어그램과 정적 클래스 다이어그램을 포함

- Dynamic Behavior Diagrams : 인터렉션 다이어그램과 액티비티 다이어그램, 협동 다이어그램,

스테이트차트 다이어그램을 포함

- Implementation Diagrams : 컴포넌트 다이어그램과 배치 다이어그램을 포함

3. 많이 활용하는 Diagrams & 규칙

- Use Case

- Class Diagram

- Interaction Diagram

- Activity Diagram

- State Chart Diagram

- Package Diagram



A. 프로그래밍 디자인과 공정관리 (2)

1. RTM(Requirements Traceability Matrix) 구축하기

Game LogicUC3_Player_Moves_Up

UC4_Player_Moves_Down

1패들의 움직임은 위로 혹은 아래로, 수직으로만 가능하다. 수평으로는 움직일 수 없다.

1.66

Game LogicUC1_Player_Wins_Game

UC2_Player_Loses_Game

UC6_Ball_Passes_Player

2만일 볼이 패들이 위치하고 있는 수직선을 지나치게 되면, 그 패들로 대표되는 플레이어는 패자가 되고 상대편플레이어는 승자가 된다.

1.55

Game LogicUC7_Ball_Hits_Ball

UC5_Player_Touches_Ball

1퐁 볼은 게임 영역 안에서 등속도로 이동한다. 볼이 패들이나 벽의 상단부, 하단부(화면의 위와 아래)에 부딪치면 투사각과 동일한 각도로 튕겨 나온다.

1.44

1첫 번째 플레이어는 화면의 왼쪽에 위치하고, 두 번째 플레이어는 화면의 오른쪽에 위치한다.

1.33

1각 플레이어들은 패들로 대표된다.1.22

1퐁 게임은 2인용 게임이 되어야 한다.1.11

ClassPackageUse Case NameBuildProblem StatementReq.No.


B. 외주 개발의 공정관리


<Pong Game>

Player_OnePaddle

Player_TwoPaddle

Ball

Wall

요구되는 작업사항에 대해서 자세한 기술과 해당 사항에 대해서 관계되는 Use Case, Package, Class에 대한 관계를 한 눈에 볼 수 있는 표이다.

본 표와 각 다이어그램이 연계되어 설계 시 사용된다.





2. 유스케이스 식별하기




<Pong Game>

Player_OnePaddle

Player_TwoPaddle

Ball

Wall

액터와 소프트웨어 시스템 간의 액션과 상호 작용들의 명세화를 통한 시스템 행위를규정한다.

<Use Case Diagram>

Out Zone

Actor Use Case





2. 유스케이스 식별하기 – 유스케이스 시나리오 (Use Case Scenario)

Use Case Name : Player Wins Game

Overview:

퐁 게임에서 어느 한 플레이어가 승자가 되는 경우

Primary Scenario:

Alternative Scenarios: None

Exceptions : None

2. 첫 번째 플레이어가 승자가 되는 하나의 윈 이벤트가발생한다.

2. 볼이 두 번째 플레이어의 패들을 빗나가 지나쳤다.

3. 게임 진행은 중단되고 화면에는 “Player 1 is the winner!”라고 보여준다.

1. 볼은 볼이 패들에 맞아 튕겨 나온 다음 해당 방향으로나아간다.

1. 첫 번째 플레이어가 패들로 볼을 쳤다

System ReactionAction




앞서 기술한 유스케이스 다이어그램의 각 유스케이스별 구체적 시나리오를 기술한다.




Package Diagram

A. 프로그래밍 디자인과 공정관리 (5)A. 프로그래밍 디자인/공정



3. 패키지 설정





4. 시작 클래스 다이어그램 만들기








5. STD 개발하기 (1)

Ball 상태 전이 다이어그램








5. STD 개발하기 (2)

CPongGame 클래스의 gameState 상태 전이 다이어그램








6. PID 제작하기 (1)

UC1_Player_Wins_Game 패키지 상호 작용 프로그램




Activation Box





6. PID 제작하기 (2)

UC4_Player_Moves_Down 패키지 상호 작용 다이어그램








6. 클래스 다이어그램 업데이트




업데이트





7. 상호작용 다이어그램 업데이트

UC4_Player_Moves_Down 클래스 상호작용 다이어그램








8. 정제와 반복

- 실제적 구현단계에 들어갔을 때 수정횟수가 최소화 되도록 지속적인 정제와 반복의 사이클을반복한다.

- 이미 개발된 재료를 다시 추적하고 수정하는 것은 매우 많은 시간이 든다. (이를 방지)

9. 구현으로 이동

- 완벽한 디자인은 할 수 없다.- 코딩 중에 어떤 것을 변경해야 한다면 반드시 문서화된 디자인을 참고하고 해당 수정 사항에대해서 논의 되어야 한다. (CCP)

10. 코딩 컨벤션의설정과 소스의 버전관리

- 소스의가독성을높이며, 유지 보수/팀플레이를원활히하기 위해코딩컨벤션의설정은필수

- SourceSafe/CVS 등을이용한소스의버전관리와최신버전유지는필수

- 문서화되지않은변경이발생되어서는안된다. 특히 서비스기간중이라면

(Cowboy Programming) – CCP의역할이굉장히중요함








1. 전적인 신뢰는 위험하다.

- 모든 작업에 대해서 완전하게 외주 업체에게 맡겨놓는 것은 위험하다. - 일정/품질에 대한 지속적인 관리가 필요하다.- 컨택 포인트를 명확히 한다. 가능하면 1명의 전담 관리 인원을 두는 것이 안전하다.

2. 기획서는 분명하게 제공되어야 한다.

- 내부개발에서도 마찬가지이지만 외주 개발의 경우 더 중요하다.- 커뮤니케이션 부재에서 오는 문제가 일어날 확률이 더 높다.- 초기 기획서 제공 시 요구 사항에 대한 명확한 제시가 필요하다.







C. 서비스의 공정관리A. 프로그래밍 디자인/공정



1. 온라인 게임은 서비스가 개발만큼의 비중을 차지한다.

- 지속적 업그레이드와 유지보수를 위한 팀이 필수적으로 필요하다. - 플레이어를 지원하기 위한 GM의 역할, GM의 관리 체계가 필요하다.- 불안정한 론칭과 패치- 패치의 제작과 배포 시 주의할 점- 유료 사용자의 확보와 유지

2. 커뮤니티 지원

- 게임의 Life Cycle을 증대시킬 수 있다.- 커뮤니티를 지원하기 위한 절차와 방법론




SUPPORT TOOLS

V. A. ClearCase / ClearQuest (SCM Tool)

B. Doxygen (Documentation Tool)

C. MS-Project (PM Tool)



V. Support Tools

A. ClearCase / ClearQuest (SCM Tools)A. ClearCase/ClearQuest

B. Doxygen

C. MS-Project

1. Rational 사의 SCM Tool

ClearCase- 통합변경관리 (Unified Change Management: UCM)- 관리자 : 프로젝트 진행 상황 추적과 조직화- 개발자 : 개발 가속화- 품질 관리자 : 품질 관리 작업 간소화- 릴리즈 엔지니어 : 품질관리

ClearQuest- 변경요구관리- 간소하고 자동화된 워크플로우 지원- 신속한 리소스 조정- 변경되는 소프트웨어의 이해- 생산성 향상- ClearCase와 통합- 간편한 최적화, 유지 및 배치



B. Doxygen (Document Generation Tool)A. ClearCase/ClearQuest

B. Doxygen

C. MS-Project

1. GNU License – http://www.doxygen.org

- 소스에 정해진 컨벤션에 의해 주석 표기 -> 손쉽게 자동으로 문서화- 온라인 Document, 윈도우 Chm 파일로 문서화가 자동으로 진행됨

- 각 함수, 클래스의 유기관계를 Visual 하게 보여줄 수 있음

Compound List

Inheritance Diagram for ControlPointCurve

CLICK~

V. Support Tools


http://www.doxygen.org


C. MS-Project (PM Tool)A. ClearCase/ClearQuest

B. Doxygen

C. MS-Project

1. 자원/자금/시간을 관리할 수 있는 툴

- 프로젝트의 범위의 관리- 마일스톤의 관리- 일정 관리- 자원의 관리- 작업의 배정과 괸리- 프로젝트 원가관리- 프로젝트의 보고와 전달 (Reporting)

V. Support Tools



질문과 답변VI.



Thank You !Choi, IL Kon Ph.D.E-mail : [email protected]

Homepage : http://www.joyon.com

T: (02)3413-1000 , F: (02)3413-1111


mailto:[email protected]

http://www.joyon.com


Date post:	15-Jan-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Game Development ProcessC3%D6%C0...Effective Development Methodology and its Process Choi, IL Kon...

Documents