https://github.com/lostwaltz/PossibleDefense

 

GitHub - lostwaltz/PossibleDefense

Contribute to lostwaltz/PossibleDefense development by creating an account on GitHub.

github.com

 

일주일간 4명의 팀원과 진행한 모바일 3D 타워 디펜스 게임에 프로토타입을 개발하였다.

결과물은 만족 스럽게 나왔으나 코드 작성시에 하드코딩이 좀 많았던것 같아 회고를 해보려고 한다. 

 

해당 파트에서 나는 Stage에 관련된 파트를 담당했다.

 

Stage에서 필요한 기능들은

-Stage에 사용될 Tile 관리

-Tile에 설치될 타워 관리 (설치 및 판매)

-해당 Stage에서 사용될 타워 업그레이드

-Stage에서 사용되는 골드 재화

-로비 -> 게임 -> 로비 로 이동시의 Data 유지와 Scene 연결

요약하면 이정도가 될것같다. 

 

해당 기능들을 크게 키워드로 해서 Class로 기능을 분리해서 작업해야 가독성이 오르는데

이번에는 하드코딩도 많고 팀원끼리 소통을 그렇게 많이 했는데도 변수명을 정하지 않았던점이 문제였던것 같다.

GameScene에서 사용된 오브젝트들과 컴포넌트들인데, 전혀 가독성이 없고 코드가 일관성이 없어 보기 힘들다.

1번 문제점 :

UI매니저가 없기에 우선 UI를 만들어두자 하고 작업을 진행하였고 Refactoring 하는 과정에서

UI매니저를 작성하여 UI매니저에 집어넣고 꺼내쓰는 식으로 사용 했어야 됬는데 결국에는 UI매니저를 사용하기 위해 UIBase 인터페이스 자체도 작성하지 않아 결국에는 동적생성을 하지 못해 이런식으로 사용하게 되었다.

 

1번 문제의 대처점 : 첫 작업시에 프레임워크 작업을 진행하고 , 해당 매니저들을 미리 작성해놓아야한다.

그러기에 팀원과 회의를 정말 많이 해야된다. 

 

2번 문제점 :

3번과 연관되는 문제점이긴한데 SpawnManager가 있지만 이 Manager는 EnemySpanwManager이다.

이름이 직관적이지 않아 직접 열어봐야만 알수있고 BulletObjectPool은 하이어라키에있고

Tile ObjectPool은 왜 Stageamanager의 안에 있는지 의문이다. ( ObjectPoolLegacy가 Tile ObjectPool)

즉, Class 및 오브젝트의 이름이 직관성 없기때문에 발생했던 문제다.

 

2번 문제의 대처점 : 해당 오브젝트 명 컴포넌트 명을 정확하게 구체적으로 작성해서 사용 할것 

 

3번 문제점

위에서 말한 큼직큼직한 기능들을 키워드 삼아서 Class별로 분리해서 컴포넌트처럼 붙여 사용하거나 따로 오브젝트화 시켰어야했는데 StageManager에 관련없는 기능을 다 넣어서 사용 한것이 문제가 되었다.

 

정말 하드코딩하고 Inspector에 다 때려 밖은 상태 절대 이렇게 작업하면 안된다.

 

StageManager의 Inspector에서 보면 밑에 컴포넌트로 부착한것들을 전부 등록하여 사용하고있다.

물론 내부에서도 해당 컴포넌트들이 비면 null체크를 해서 컴포넌트를 호출해서 사용하고 있지만

이런 Inspector 구조는 가독성이 떨어지기에이런식으로 Inspctor에 정리없이 사용하면 안될것 같다. 

또한 Scene 전환시에도 Missing이 일어날 확률이 높다.

 

3번 문제의 대처점 : Inspector에서는 최소한으로 등록하여 사용하고 내부적으로 동적생성하게 코드를 구현해야 되며 UI매니저를 사용하여 UI를 원하는 시점에서 꺼내 쓸수 있게 구현 해야된다.

 

 

p.s 코드 구조를 잡지 않고 자료구조를 막 사용한 나쁜 예시

이 코드는 제출하기 직전에 급하게 만든 코드라 최적화를 생각하지 못했다.

타일을 선택할떄마다 타일 선택 정보를 초기화 해주는 코드인데 맨처음 작성시 자료구조를 List를 쓴것부터가 문제의 시작이였고 해당 문제를 해결하려면 TowerTiled을 딕셔너리로 변경해서 사용할수있게 구조를 바꿧어야 했다. 

 

 

그래도 해당 프로젝트에서는 오전 / 오후 / 저녁으로 자기의 코드리뷰와 프로젝트 진척도를 회의하는 시간을 계속 가져왔고

작업량이 없어도 무조건 코드리뷰를 하게 하였다. 그러면서 서로 문제점이 있는부분을 서로 보완해주고 서로에 대한 정보공유를하면서 정말 실력이 많이 늘었다. 

 

다음 프로젝트에서도 팀원과의 소통 및 회의/회고를 적극 권장해야겠다.

+ Recent posts