[소개]
랜덤 뽑기를 통해 나만의 캐릭터를 보관하고 캐릭터들로 덱을 구성해 친구들과 내기를 할 수 있는 서비스입니다.
[기능]
1. 이미지 감지(detection)의 결과를 바탕으로 임의 캐릭터 생성
2. 생성된 캐릭터를 성장시켜 덱을 만들 수 있다.
3. 다른 유저와의 상호작용(실시간 대화, 친구 추가, 메시지 전달)
[세부내용]
1. 이미지를 업로드하여 이미지에서 감지된 인물에 대한 감정값을 바탕으로 캐릭터를 제공합니다.
2. 캐릭터에 설정된 스탯은 최초 1 ~ 5 사이 랜덤으로 설정됩니다.
3. 사용자는 캐릭터를 보관할 수 있고 캐릭터를 업그레이드 할 수 있습니다.
4. 레벨업을 할때마다 5 ~ 20 사이 활률에 따라 스탯이 결정됩니다. 예를 들어 제일 높은 수치인 20은 1%, 10은 15%의 확률로 설정됩니다.
5. 부드러운 사용자경험을 제공하기 위해 마이크로 애니메이션을 많이 사용하였습니다.
6. 친구를 추가할 수 있고 채팅을 할 수 있습니다. 내기결과를 데이터베이스에 저장하고 자신의 전적을 확인할 수 있습니다.
7. 알림을 통해 사용자에게 필요한 정보를 제공합니다. (친구초대 발송/친구초대 수신/내기요청 발송/내기요청 수신 등...)
step1. 캐릭터 뽑기
- face-api.js 라이브러리를 통해 인물사진에서 설병과 감정값을 추출합니다.
- 추출된 감정은 총 6개로 surprised, disgusted, fearful, sad, angry, happy가 있고 이는 다시 1 ~ 100% 사이 수치로 표현됩니다.
- 프로젝트에서 사용된 캐릭터 생성 로직을 위와 같이 설계 후 작업하였습니다.
- 로그인 부터 핵심기능인 캐릭터 및 카드 생성에 대한 전반적인 흐름은 아래 그림과 같습니다.
step2. 회원가입
- 캐릭터를 보관하기 위해서는 로그인을 해야합니다.
- 회원가입 방법은 3가지입니다. (구글, 카카오, 아이디/비밀번호)
- 회원가입 시 정규식을 바탕으로 아이디/비밀번호/이메일에 대한 유효성검사를 거친 뒤 가입을 완료합니다.
- 아이디와 이메일에 대한 중복확인을 통해 기존 가입되어 있는 회원인지 확인합니다.
- 회원정보는 파이어베이스 데이터베이스에 저장됩니다.
step3. 친구찾기
- 보관한 카드로 친구에게 내기를 요청할 수 있습니다.
- 친구아이디를 USERS 테이블에서 조회하여 친구에게 친구요청할 수 있습니다.
step4. 친구목록
- 친구요청을 받은 친구가 친구요청을 수락하게되면 친구목록에 친구가 표시됩니다.
- 친구의 접속상태를 리프레쉬 버튼으로 최신화할 수 있습니다.
- 친구가 접송중인 상태에서 내기를 요청할 수 있습니다. 내기내용은 셀렉트 박스에서 선택할 수 있고 친구에게 내기요청 시 메시지를 같이 발송할 수 있습니다.
- 친구와 채팅을 할 수 있습니다. 친구가 채팅을하면 신규메시지가 왔다는 아이콘이 노출되어 사용자에게 알려줍니다.
- 내기요청 시 사용자 자신의 알림목록에 내기를 요청한 내용을 아래와 같이 알려줍니다.
step5. 내기준비
- 내기를 하기 위해서는 카드가 있어야 합니다. 보관된 카드는 페이지 제일 하단에서 보실 수 있습니다.
- 보관중인 카드를 덱 구성원으로 설정한 뒤 대결준비 버튼을 누릅니다.
- 알림메시지에서 친구가 발송한 내기요청메시지를 클릭하여 내기를 수락 또는 거절할 수 있습니다.
- 결과는 전적집계에서 확인할 수 있습니다. 친구가 보낸 메시지도 확인가능합니다.
step6. 카드 업그레이드
- 하루 업로드가능한 횟수 고정.
- 레벨이 높아질수록 경험치량 증가.
- 레벨업을 할 경우 능령치 포인트가 제공됩니다. 포인트는 5 부터 20까지 랜덤확률로 생성됩니다. 높은 수치의 포인트를 획득할 확률은 수치에 따라 낮아지도록 설정했습니다. (예: 포인트 20은 1%의 확률로 제공되지만 수치가 제일 낮은 5는 75%의 확률을 가지고 있습니다.)
- 포인트를 모두 소진하지 않았을 경우 남은 포인트를 기억해 다음에 소진할 수 있습니다.
깨달은점:
1. 상태관리 라이브러리 없이 작업하다보니 상위 컴포넌트에서 하위 컴포넌트에게 데이터를 전달하는 과정, 네스팅 관계에서 props, state 사용 및 관리가 매우 어려웠다.
2. 컴포넌트 최적화 훅들에 대한 이해가 부족해 컴포넌트 최적화가 정상적으로 이루어지지 않았다.
추가설명
해당 프로젝트는 순수 리액트로써 상태관리 라이브러리를 사용하지 않았고, context API, useReducer 또한 사용하지 않았다. 리액트의 originality를 지킨 순수 리액트 프로젝트를 우선 경험해 보고 싶었다. 그 이유는 상태관리에 대한 개념이 나타나기 전 리액트의 불편한 점들을 직접경험하고 내 주관(개인적인 생각)을 기르고 싶었기 때문이다.
결론
1. 역시 상태관리 라이브러리 없이 컴포넌트의 nesting속에서 state와 props를 tracking하는 것이 매우 힘들었다. 더욱이 컴포넌트를 atomic 구조로 만들었기 때문에 더욱 어려웠다.
styled-compoent는 "컴포넌트를 만든다". A 컴포넌트를 만들면 css를 적용하기 위해서 A-a 컴포넌트(styled-component)를 만들어야 한다. css를 JS로 제어하는 것은 큰 장점이다. 디렉토리 구성, 구조에 대한 룰(convention)을 조금 더 살펴봐야 할 것 같다.
2. 컴포넌트는 MVC 모델 중 View를 담당하는데 내가 작업한 컴포넌트들은 View 뿐만 아니라 Controller 의 영역까지 포함하고 있다. (모든 컴포넌트들이 그렇지 않지만 여전히 리액트에서 자랑하는 장점을 활용하지 못해 아쉽다.) 즉, 모듈화를 적절하게 이루지 못한 것이다. 그리고 컴포넌트의 재활용성을 항상 염두해두고 작업해야할 것 같다.
'React.js > [완성] 프로젝트' 카테고리의 다른 글
| [CRA, TypeScript, Redux, REST API, GSAP, styled-component] 포켓몬 검색 (0) | 2022.09.21 |
|---|
댓글