아르카스톤 포스트 모뎀NHN NEXT 개발 경험 프로젝트팀 DecemberBy 남세현 서동유 김영하 김승현

목차

출사표 ㄴ 성취도 + 만족도

잘한 점 , 잘못한 점

출사표

1 등은 우리꺼지 !성취도 : 만족도 :

다양한 말 (Pirece) 들을 자신만의 전략으로 조합하여 배치하고 ,

적군의 말을 밀어 떨어뜨리거나 체력을 깎아 모두 제거하자 .

알까기의 한방과 체스의 두뇌싸움을 합친 전략성 보드게임 !

아르카스톤의 재미는 따라올 수 없다 !

??

출사표

출시를 목표로 !

출사표

컨디션 관리하기

연일 밤샘 + 막판 스퍼트 = 대실패

성취도 :만족도 :

망함

출사표

컨디션 관리하기

연일 밤샘 + 막판 스퍼트 = 대실패

성취도 :만족도 :

망함

잘한 점

핵심 재미에 집중한 마일스톤 설계아르카스톤의 핵심 재미를 한 문장으로 줄이자면

‘ 다양한 말을 이용한 전략적 수싸움’ 이라 할 수 있다 .

우리는 이를 파악하여 , 마일스톤을 설계할 때 모든 이슈 중에서도

관련된 최소한의 이슈를 1 주일로 압축하고 , 실제로 구현해냈다 .

그 결과 가장 기초적인 플레이 양상을 시연하여 ,

핵심 재미를 1 주차 만에 검증할 수 있었다 .

잘했지만 아쉬운 점

역할을 개인의 경험을 위해 다시 정한 것기본적인 토대가 마련된 후 2 주차에 들어서며 ,

팀 내에서 각각의 역할을 다시 정하게 되었다 .

개경프를 수강한 적이 있는 팀원의 비중을 줄였는데 ,

개인적으로는 놓칠뻔한 좋은 경험을 했다고 생각한다 .

아쉬운 점은 그에 따라 개발 속도가 늦춰져 계획을 다시 설계해야 했는데 ,

깃 컨플릭트 , 유닛 충돌 버그 , 기획 충돌과 함께 이중 삼중고를 겪느라

결국 어느것도 제대로 처리하지 못하고 부채로 이어간 것이다 .

망한 점

클래스 설계 미흡초기 클래스 설계에 구멍이 하나 있었다 .

게임에 접속한 사용자 ( User ) 클래스와

상대와 1vs1 을 벌이고 있는 플레이어 ( Player ) 클래스를 나누지 않은 것이다 .

User 클래스는 서버에만 있으며 ,‘ 유닛의 종류’ 여럿이 포합된 그룹 ( Group ) 클래스들을 가지고 있고 ,

Player 클래스는 클라와 서버 양쪽에 있으며 ,체력이나 위치같은 상태를 가진 유닛 ( Unit ) 클래스 자체들을 가지고 있다는 차이이다 .

이를 고치기 위해 코드 전반에 걸쳐 뜯어고친 것을 생각하면 분통 .

망했지만 나아진 점

컨플릭트와 Git Bash, 머지툴“ 개발초기에 영문도 모른체 push 가 안되어 화난적이 있다 .Pull push 했더니 된다 . 다른 사람이 push 한 것을 merge 한 거란다 .

그런데 얼마못가 문제가 터졌다 . pull 도 안된다 .코드에 섞인 이상한 문자들을 지우니 push 는 되지만 실행해보니 안돌아간다 .

Git Hub 로 잘못된 push 를 강제로 revert 소생하거나 ,과거로 회귀하는 몇번의 시행착오 끝에

Git Bash 를 써야한다는 것을 깨달았다 .

팀원들을 통해 머지툴 교습도 받았지만 , 그 뒤로 컨플릭트가 나는 일은 없었다고 한다 ..

시간을 절약하기 위해선 컨플릭트를 줄이는 것이 최선이라는 것도 깨닫게 됐다 .”

아쉬운 점

떨어진 작업공간시간을 정해놓고 같이 코딩했으면 , 집중도 더 되고

컨플릭트를 예방하거나 각자 필요한 자원을 주고 받는 등

생산성을 많이 높일 수 있었으리라 .

아예 생각치 못한 방법은 아니지만 제대로 실천하지 못한 것이 아쉽다 .

잘된 점

자발적인 스터디우리 December 는 다른 팀과 함께 받은 스터디 외에 ,

개발 도중 난관에 부딪힐 때마다 새로운 스터디를 진행했다 .

이는 떨어진 작업공간 패널티는 메우는 역할을 할 수 있었으며 ,

가르치는 것이야말로 최대의 배움이라는 말이 있듯이

더 값진 공부가 되었다 .

정리

- 마일스톤 설계 시 게임의 핵심 재미를 검증하는 것을 최우선하자 .

핵심 재미의 범위를 최소한으로 잡고 , 최대한 개발하자

- 클래스 구조에 구멍이 없나 잘 살피자

- 팀원과 자주 소통할 것 . 같이 개발하면 생산성이 오른다 .

- 배운 내용을 공유할 것 . 스터디는 복습 효과도 있다 .