1. 서론
Express.js 기반으로 item simulator를 개인 프로젝트로 제작해보았는데 이어서 금일부터는 팀 프로젝트로 온라인! 풋살 매니저를 구현해보는 것을 시작하였다.
기본적으로 필수기능과 도전기능이 몇개 있는데 대부분은 item simulator에서 이미 구현해보았던 API 기능이라서 크게 어려움은 없을 것이라고 생각했다.
하지만.. 항상 예상대로 되는법은 없는법....
오늘은 S.A 피드백을 위해 API 명세서, ERD와 기획내용을 팀원과 어떤 회의와 문제를 겪고 해결했는지 정리하고자 한다.
2. 본론
2-1. API 명세서
이 부분은 기능 명세서를 같이 확인해보면서 빠르게 작성했다.
작성하는 과정 중 어려웠던 점은 담당구역 분담과 추가 기능에 관련에 있었다.
우리는 계정 / 상점 / 매치 / 팀 / 선수 단위로 API를 나누어 명세서를 작성하였는데
상대적으로 쉬운 기능이 있어서 이런 부분을 나누기가 힘들었다.
그래서 담당자와 부담당자를 나누어 함께 구현을하며 배울 수 있도록 방향을 정했다.
=> 이 과정 중에서 깃헙 충돌에 대한 이슈도 겪을 수 있어 좋은 기회라고 생각한다.
2-2. ERD
가장 오래 고민하고 상의했던 파트이다.
ERD 즉, 관계형 데이터베이스 다이어그램인데 API 명세서를 토대로 DB 설계를 하였다.
2-2-1. Trouble Shooting
처음에는 각자 맡은 API구역을 만들어 놓고 리뷰 후에 수정하는 방향으로 했는데 꽤 많은 부분에서 문제가 있었다.
전체 선수 - 계정의 보유 선수
: 강화 시스템이 존재하고 각 계정마다 각 선수의 강화가 다른 상태 + 강화를 랜덤 수치로 올려주는 로직을 구상해서 적용하려고 했다.
이 과정에서 전체 선수의 정보가 담긴 Players 의 데이터를 계정의 보유 선수 Roster 테이블에 사본으로 가져와 따로 관리를 하려고 했다.
=> 이렇게 관리를 하게 되면 원본의 스탯이 변경되었을 경우에 사후 처리와 DB의 크기가 커지는 문제가 발생한다. 결국, 유지보수와 서버 성능 측면에서 안좋은 상황이다.
피드백을 통해 강화 수치를 고정시키고, 강화 테이블을 만들어 증가값과 성공률을 담아서 강화 시, 해당 테이블의 값을 가져와 원본 데이터에서 계산하여 입력해주는 방향으로 바꾸었다.
=> 이렇게 하면 테이블의 크기가 줄고 원본의 데이터값으로 유지보수가 가능하다. 캐릭터의 스탯은 접속 했을 때 인-메모리 형식으로 저장된 선수들의 정보를 불러오기만 하면 된다!!
상세 정보들에 대한 DB
예를 들어, 계정 테이블이 있다면 계정 테이블과 계정의 상세 정보에 대한 테이블을 굳이 나눌 필요가 없었다.
=> 이전 item-simulator에서 Infos 라는 접미사로 상세정보 테이블을 나누었었는데 실제 API 구현할 떄 한번 더 조회를 해야하는 불상사가 있었다. 조회 한번에 DB에 한번 더 요청을 하는 것이고 유저와 요청이 많아질수록 서버에 부담이 심할 것이다.
상점과 상품
상점 안에 상품들이 있는거처럼 Shop 과 Product 라는 테이블을 나누고 싶었다.
하지만 우리가 만드는 것은 Shop, 즉 전시되는 공간이 여러개로 나뉜것이 아니라 카테고리에 모두 한번에 노출되는 방향이기 때문에 Product 만 있어도 된다고 생각했다.
=> DB 요청을 최대한 줄여서 성능을 잡아주었다.
그리고 상품에 대한 테이블은 마음대로 구현해도 상관이 없다고 하셨다.
정석은 없는 듯한 느낌? 이었다.
2-3 기획
풋살 매니저에서는 게임을 돌려볼 수 있는 API가 있다.
근데 결과를 단순하게 선수들의 총합 능력치를 전투력처럼 구단 가치로 판단하여 승/패를 가리는 형식이라서 지루한 느낌이 많았다..
2-3-1. 게임 진행 피드백
지루한 게임으로 튜터님의 아이디어 피드백으로 회의를 한 결과, 좋은 아이디어가 나와서 추가 회의를 거쳐서 기획안을 천천히 작성하고 있다.
대충, 공을 움직여서 슈팅/패스/.. 행동을 통해 골을 넣는 시뮬레이터이다.
A와 B 플레이어가 서로 대결을 하고, 턴을 가지고 있다.
턴은 선수가치가 높은 팀이 먼저 공을 잡아서 시작하게 되고 A팀 골대 [ | O | ] B팀 골대 이렇게 빈 3공간에서 공을 왔다갔다 움직이며 슈팅을 성공하면 점수를 얻는 형식이다.
여기서 선수들의 포지션 보너스와 공의 위치에 따라서 할 수 있는 행동가짓수를 제한하여 골을 넣으면 된다.
각 행동에는 해당 선수의 스탯에 따른 스탯보너스+위치보너스 등으로 확률 로직을 통해 성공 / 실패를 구분짓게 된다.
그리고 턴에 대한 모든 행동들이 턴 수행에 따라 로그를 통해 상황을 알려주는 형식으로 만들어 보려고 한다.
=> 단순한 게임 진행 및 결과 방식에서 조금 더 생동감있고 몰입감이 높아져서 개발 흥미가 높아졌다 ㅋㅋㅋㅋ
2-3-2. 매칭 및 서버 피드백
이제 게임 진행을 하면 누구와 게임을 진행하게 되는지가 떠오른다.
매칭을 통해 다른 계정과 게임이 진행되고, 저장되어 있는 다른 계정의 팀과 전투를 하는 것으로 생각하고 있었지만 뜻밖의 피드백을 제공해주셨다ㅣ...
바로 접속한 계정과의 전투!!!
접속한 사람들 중 한명에게 게임 요청을 하여 수락을하면 세션이 연결되어 게임이 진행되도록 만드는 것이었다...
상상도 못한 것이지만 서버 트랙인만큼 도전해봤으면 좋겠다는 생각이 들었다.
시간이 남아서 꼭 다같이 만들어 볼 수 있었으면 좋겠다.
3. 마무리
- Futsal Manager 라는 새로운 팀 프로젝트를 시작했다.
- API, ERD 만드는 중 문제를 겪었지만 잘 해결된 것 같다.
- 피드백 덕분에 흥미와 의욕이 더 생기지만 구현할 수 있을지 모르겠다.
- 일단 열심히 해보자... 어쩌겠어 해내야지
