Reaching For You (24.03.02~2024.11.21)
GitHub
졸업 작품 팀 결성
아트팀과의 협업
경북 게임잼에서의 인연으로 구미대의 게임비주얼컨텐츠학과 학생들과 팀을 결성하였다.
서로 간의 원하는 기획의 방향성이 달랐다.
프로그래밍 팀 내에서 기획을 맡는 것은 부담이 크다는 의견에 따라 아트팀이 기획을 담당하게 되었다.
기획 및 파트 분배
결정된 기획은 2가지 파트로 나뉘어졌다.
RPG와 미니게임을 이루어진 오전 파트와 턴제 전략게임으로 이루어진 오후 파트로 이루어졌다.
작성자는 오후 파트의 턴제 전투 시스템과 아이템, 스킬, 서버를 담당하였다.
작업의 시작
서버의 슬픔
첫 2달, 5월까지는 결투장 시스템 및 공략 공유 등의 기획으로 멀티 기능이 존재하였다.
그렇게 1달 동안 C#으로 서버를 구축하고 클라이언트 연결을 해보았다.
해당 서버는 C# 서버 강의를 들으면서 Clone Coding을 진행하였다.
처음에는 직접 처음부터 구현하려 하였으나, 담당하고 있는 파트가 많아서 빠른 진행을 위해 선택하였다.
그렇게 프로토콜 및 패킷 설계만 남았지만, 5월 전체 회의에서 말이 나왔다.
멀티 기능은 없애는 방향성으로 진행하겠다고... 서버하게 해준다며!!
슬픔을 뒤로하고
6월부터 빠른 속도로 전투 시스템 개발에 착수하였다.
작업의 우선 순위를 정하였다.
- 턴제 진행 구현
- 캐릭터 피격 판정
- 스킬 & 아이템 부모 클래스 구현
- 스킬 & 아이템 상세 구현
- 버프 & 디버프 구현
해당 리스트를 토대로 5월 말부터 개발을 진행하였다.
주요 개발 이슈
애니메이션 도중 턴 진행
애니메이션 연출 시에 bool 함수로 연출이 끝났는 지 확인하였다.
턴을 진행하는 스크립트에서 coroutine을 통해 bool 함수를 확인하며 다음 함수를 진행하였다.
지금 생각하면 coroutine 보다는 callback 함수나 event를 이용하여 해결하였으면 효율적이었을 것 같다.
계속 coroutine 내에서 확인을 하다보니 수정 및 확장이 힘들고 디버깅이 힘들어졌다.
원뿔형 스킬 판정
원뿔형 스킬 판정을 위해서는 피격 오브젝트와 스킬 발동 위치의 각도와 거리를 알아야했다.
이를 위해 벡터를 내적하고 코탄젠트를 이용하여 각도를 구하였다. (주석 상의 내용)
이후 유니티 내의 삼각함수의 동작 시간이 느린 것을 알았다.
다른 방법을 찾는 도중에 벡터 간의 각도를 구하는 함수가 있다는 걸 알게되었다.
이를 통해 함수가 간결해지고 동작속도가 빨라졌다.
버프 & 디버프 소멸 및 추가
public void ClearBuff_Debuff()
{
foreach (Debuff debuff in deleteDebuffList)
{
debuffs.Remove(debuff);
}
foreach (Buff buff in deleteBuffList)
{
buffs.Remove(buff);
}
deleteBuffList.Clear();
deleteDebuffList.Clear();
foreach (Debuff debuff in addDebuffList)
{
debuffs.Add(debuff);
}
foreach (Buff buff in addBuffList)
{
buffs.Add(buff);
}
addBuffList.Clear();
addDebuffList.Clear();
}
public void CalcTurn()
{
Vector3 pos = Managers.Battle.currentCharacter.transform.position;
if (debuffs.Count > 0)
{
foreach (Debuff debuff in debuffs)
{
debuff.TimeCheck();
Managers.Manager.StartCoroutine(Managers.Skill.StartBuffEffect(debuff.effect));
}
}
if (buffs.Count > 0)
{
foreach (Buff buff in buffs)
{
buff.TimeCheck();
Managers.Manager.StartCoroutine(Managers.Skill.StartBuffEffect(buff.effect));
}
}
ClearBuff_Debuff();
}처음 구현했을 당시에는 for문 안에서 참조하고 있는 버프(디버프)를 삭제, 추가하였다.
이렇게 했을 때, 오류가 발생한다.
해당 문제는 리스트의 다음 요소를 참조할 수 없게 되어서 발생한다.
이를 해결하기 위해 추가 및 삭제할 버프(디버프)를 저장하고 있을 리스트를 만들었다.
기존 리스트의 순회가 끝난 이후, 해당 리스트를 순회하며 삭제 및 추가한다.
여전히 문제점이 산재하고 있다.
시간복잡도가 O(n)에서 O(3n)으로 증가하였다.
해당 문제점을 해결하기 위해서 노력할 필요가 있어보인다.
주요 협업 이슈
아트 리소스 지연
본격적으로 작업을 시작하고 아트를 적용할 시점이 되었는 데도 리소스를 전달받지 못 하였다.
주로 주 1회에 하는 리더 회의를 통해 팀원들의 리소스 요청 종합본을 아트팀 리더에 전달받는 형식을 협업이 이루어지고 있었다.
하지만, 요청 이후 1달 이상의 시간이 걸리는 것이 예사였고, 받은 리소스조차도 ppt로 만든 것 같은 퀄리티가 오는 경우도 있었다.
첫 프로토 타입 제작 마감 전에는 거의 아트 적용 작업만 했었던 것 같다.
해당 문제가 제일 두드러지기 시작한 건, 아트팀이 본 작품을 포트폴리오로 쓰지 않겠다고 결정한 이후였다.
기획 상에 필요한 리소스들이 최종 마감 2일 전에 인계되어 비상이 걸리거나, 적용 이후 부자연스러운 움직임으로 인해 폐기된 시스템이 생겼다.
일정 변경 이슈
프로그래밍 팀인 우리와 아트팀의 일정이 서로 달랐다.
그러다보니 프로토타입이 1달에 1번씩 제작되었다.
주로 프로토타입 마감 1주전부터 시스템 연동 이후 특정 상황에서 발생하는 오류들을 찾아내고 고치는 작업에 들어갔다.
이로 인해, 아트팀의 일정이 변경될 때마다 작업 일정 문제가 발생하였다.
주로 꼭 넣어달라는 기능들로 인해 발생했다..
일관성 없는 기획
기획의 방향성이 명확하지 않아 같은 작업을 반복하거나 했던 작업을 다시 되돌리는 일이 잦았다.
작성자의 경우, 버프(디버프)의 중첩 관련한 문제가 있었다.
초기 기획 당시에는 중첩이 가능했었기에, 이후 구현하면서 버프 중첩과 관련해서 문제가 발생할 수 있는 상황을 질문했었다.
이에 버프 중첩은 없다고 답변이 왔었기에 중첩 관련 부분을 삭제를 했었다.
이후 최종 마감 1달 전 즈음에 버프(디버프) 중첩이 있다는 변경으로 인해 급하게 작업했었던 기억이 있다.
후기
처음으로 10명이 넘는 사람이 같이 협업을 한 팀 프로젝트였다.
중간중간 갈등도 많았고 이로 인해 팀 리더 분께서 중재를 많이 하셨다.
아트팀에 대놓고 불만 표시 하지마라 정 안되면 나에게 말해라
팀이 나뉘어져서 작업을 하다보니, 보고 체계 및 다른 직군에 대한 이해도에 대한 중요성을 느꼈다.
해당 프로젝트는 졸업 작품으로 제출되었고, 당당히 통과하였다.
나도 이제 졸업한다!!!! 탈출이다!!!!
