https://github.com/choisooyoung-dev/d-ingco.git
https://docs.google.com/presentation/d/17T5n9gLx_kFfs9TG2ld2GO56I8ejq7hv5TbUSfFnR1E/edit?usp=sharing
소개
ZH7V3VMLO2REFA4VNBIBFKXSD4.avif
player(혹은 character) - 선수 (아이템 테이블과 동일)
선수 스탯 뽑기 확률 포지션? (도전) 강화도: 기본 값 0, 강화도에 따라 스탯 가중치 (도전 - 생각해본 것) 선수 등급?
grade (도전 - 생각해본 것) - 선수 등급에 따른 강화도 스탯 가중치 테이블??
user - 유저 계정
캐시 = character.money (유저 돈) (도전) 유저 점수, 매칭용 (랭킹 조회 가능해짐)
team - 팀 구성 (장착 아이템과 동일), 최대 3명, 중복 불가, 팀 없으면 게임 불가
inventory - 가진 선수 테이블 (보유 아이템 목록과 동일)
store - 상점
캐시구매 기능 = 돈 벌기 뽑기 = 아이템 구매랑 동일, 핵심 BM (도전) 강화: 여기서 하거나 별개 라우터 upgrade 만들기 강화 대상 캐릭터 현재 강화 레벨에 따라 강화 확률 감소
game - 게임 플레이 = 없던 기능
게임 로직 함수 = 스탯 가중치 (총합 1), 정규화, 총합 비교 후 승률 정하고 룰렛 (랜덤) (????) post: 게임 로직 실행 후 결과 db에 create (도전) 매치 메이킹: 유저 점수 기반으로 상대 매칭
rank - 유저 점수 기반
grade (도전 - 생각해본 것) - 선수 등급에 따른 강화도 스탯 가중치 테이블??
team - 팀 구성 (장착 아이템과 동일), 최대 3명, 중복 불가, 팀 없으면 게임 불가
user - 유저 계정 캐시 = character.money (유저 돈) (도전) 유저 점수, 매칭용 (랭킹 조회 가능해짐)
inventory - 가진 선수 테이블 (보유 아이템 목록과 동일)
store - 상점 캐시구매 기능 = 돈 벌기 뽑기 = 아이템 구매랑 동일, 핵심 BM (도전) 강화: 여기서 하거나 별개 라우터 upgrade 만들기 강화 대상 캐릭터 현재 강화 레벨에 따라 강화 확률 감소
game - 게임 플레이 = 없던 기능 게임 로직 함수 = 스탯 가중치 (총합 1), 정규화, 총합 비교 후 승률 정하고 룰렛 (랜덤) (????) post: 게임 로직 실행 후 결과 db에 create (도전) 매치 메이킹: 유저 점수 기반으로 상대 매칭
rank - 랭킹 get: 유저 테이블 유저 점수 select 후 정렬
userChecker(userId, select)
// @returns user // 유저 존재 유무 확인
playerChecker(playerId, select)
// @returns player // 선수 존재 유무 확인
inventoryChecker(userId, playerId, select)
// @returns inventory // 선수 보유 중인지 확인 // 내부에서 userChecker, playerChecker 사용
moneyChecker (userId, chargeMoney, select)
// @returns user // 요청에 대해 돈이 충분한지 확인 // 내부에서 userChecker 사용
✏️09:00~10:00 : 알고리즘 & 코드카타 풀이
📖10:00~13:00 : 오전공부
🍙13:00~14:00 : 점심식사
📖14:00~18:00 : 오후공부
🍙18:00~19:00 : 저녁식사
📖19:00~21:00 : 저녁공부
📝20:30~21:00 : TIL 작성
*9시 전에 출석 완료하기!
*20분 이상 자리 비울 시 슬랙에 알리기 (사정이 있다면 슬랙에 알리고 매니저님들께 꼭 이야기 하기)
TIL 작성하기 힘들어도 어떻게든 완성하기.
개인 과제, 팀 과제를 성공적으로 제출하기
ERD:
- 테이블 관계를 보다 명확하게 정의하기
API 명세서:
- userId를 URI parameter로 받는 API가 많은데, auth를 확인하는 항목의 경우 token에 userId 정보가 이미 들어있으므로 parameter의 userId는 불필요함
- teams 나 stores API의 경우 뒤에 이어서 오는 항목이 team 번호나 store의 항목 번호라고 생각하는 것이 일반적이므로 userId 처럼 다른 값을 받게되면 사용자가 혼란을 겪을 수 있음
***Front-End Version