Minimanimo

 

미니마니모 ( Minimanimo )

 

프로젝트

프로젝트 개요

프로젝트 기간 : 72일

프로젝트 인원 : 기획자(4), 프로그래머(5), QA(1)

프로젝트 엔진 : Unity3D

활용 프로그램 : Unity, Photon PUN2, AWS EC2 (MariaDB)

플레이 환경 : VR (Oculus Quest2)

 

KGA 교육 커리큘럼의 마지막 프로젝트로 기업과 협약하여 진행한 프로젝트.

기획팀(5인) + 프로그램팀(5인) + 기업 멘토(아이지)로 구성되어 진행된 프로젝트.

 

 

담당 업무

팀 업무 관리

Data 관리

    - AWS EC2 MariaDB
    - Game Data Sheet

로그인

    - 로그인, 회원가입, ID/PW 찾기
    - 닉네임 설정 및 기본 캐릭터 선택
    - VR 가상 키보드

로비

   - 미니게임

       - 오브젝트 스폰 및 리스폰
       - 플레이 쿨타임
       - 일일 참여 횟수 제한

  - 친구 신청 및 리스트
  - 확률 보상
  - NPC 대화
  - 사운드 설정

피카부

  - 캐릭터 커스터마이징
  - 랭킹

 

 

핵심 기능 설명

1. 로그인/회원가입 (DB)

시스템 소개

로그인 및 회원가입 기능은 DataBase에 플레이어의 정보가 저장되어야하는 기능입니다.

 

핵심 기능

(1) AWS DataBase

초기 DB는 AWS에서 제공하는 RDS를 사용하였습니다.

EC2에 서버가 구축된다면 AWS RDS는 EC2와 같은 보안그룹으로 설정하여 EC2에만 접근 가능하도록 설정하고,

플레이어는 EC2의 서버와 통신을 하는 방식으로 개발할 예정이었습니다. 

그러나 AWS RDS의 Freetier 사용량이 초과하는 문제가 발생하여 요금이 청구되는 이슈가 발생했습니다.
이후 AWS의 EC2에 MariaDB를 설치하여 사용하는 방식으로 변경하였습니다.

 

구축한 DataBase의 Table은 탐색하는 데이터량을 줄이기 위하여,

콘텐츠별로 Table을 세분화하여 접근하도록 구성하였습니다.

 

(2) 입력 제한 설정

플레이어가 회원가입을 진행할 시 입력에 제한사항이 존재했습니다.
중복된 아이디와 닉네임은 사용이 불가능하였기에 MariaDB의 데이터를 확인하여 처리하였으며,
욕설과 같이 사용할 수 없는 아이디와 닉네임은 로컬의 DataSheet의 데이터 리스트를 통해 확인하였습니다.
간단한 글자 입력 또는 입력 글자 수의 제한은 코드작업을 통해 제한을 두었습니다.
  

[글자수 제한] → [사용할 수 없는 아이디] → [중복된 아이디] 
제약사항은 위 순서로 데이터의 확인 Cost가 높지 않다고 판단한 작업부터 진행하여

불필요한 DB 연결 또는 데이터 확인이 없도록 설계하였습니다.

플레이어가 정상적으로 로그인을 완료하면 MariaDB의 데이터를 로컬에 존재하는 PlayerData 클래스에 저장하여 유저의 데이터를 가져오게 작업되었습니다. 

 

 

2. 가상 키보드

시스템 소개

VR 환경에서 사용자가 게임에 정보를 입력하기 위한 기능.

 

핵심 시스템

(1) 입력 문자열 변환

기본적으로 입력된 버튼의 값을 문자열에 추가하는 구조로 개발되었습니다.

그러나 단순하게 문자열에 추가하는 구조는 한글 입력 기능에 자모조합이 이루어지지 않았기에,

문제를 해결하기 위하여 입력된 문자열을 변환하는 작업이 이루어졌습니다.

 

①  유니코드로 변환한 값을 초성, 중성, 종성 자모조합

 

② 이중모음, 이중자음을 조건식을 통해 변환

 

 

3. 콘텐츠 플레이 제한

시스템 소개

미니마니모의 플라잉 스타는 2시간에 한 번 플레이가 가능하며, 하루에 8번 플레이 제한이 있습니다.

 

핵심 시스템

(1) 플레이 가능여부 판단 기능

플레이어가 콘텐츠를 진행하면 DB와 로컬 데이터에 플레이한 시간과 오늘 플레이 횟수를 저장합니다.

플레이어가 플라잉 스타를 다시 플레이할 경우 로컬 데이터의 플레이 시간과 횟수를 확인하여 플레이 가능여부를 판단하게 됩니다.

 

플레이가 2시간에 한 번 가능한 것에 비하여 플레이 시도는 빈번하게 이루어질 수 있기 때문에 DB 데이터를 계속해서 확인하는 것은 비효율적이라고 판단하였습니다.

플레이시도는 로컬에 저장된 데이터를 우선적으로 확인하고 로컬에 저장된 데이터가 플레이 가능하다고 판단되었을 경우 DB의 데이터를 로컬 데이터와 동기화 시킨 후 다시 한 번 확인하는 방식으로 개발되었습니다.

이러한 방식으로 DB와의 통신을 줄이면서 로컬데이터의 변조에 대응할 수 있게 되었습니다.

 

 

4. NPC 대화 (DataTable)

시스템 소개

NPC와의 대화는 여러개의 대사와 선택지가 존재하는 시스템입니다.

플레이어는 NPC와의 대화를 통해 아이템을 교환하고 콘텐츠를 진행할 수있습니다.

 

 

핵심 시스템 

(1) DataSheet

대화 시스템은 하나의 UI에서 대화의 데이터를 교체하는 방식으로 작업되었습니다.

NPC는 각각 고유한 ID와 시작 대사 ID를 갖고 있으며 이를 통해 DataSheet의 NPC 대사와 선택지, 다음 대사 ID를 출력하는 시스템을 만들었습니다.
또한 DataSheet에 사운드와 애니메이션 컬럼을 통해 해당 대사ID가 발생할 시, NPC의 애니메이션과 보이스 사운드가 발생하도록 개발되었습니다.
이러한 기능으로 기획자가 DataSheet에 데이터를 추가/수정하는 것만으로 NPC와의 대화를 자유롭게 컨트롤 할 수 있게 되었습니다.

 

 

5. 친구

시스템 소개

친구 시스템은 플레이어가 다른 플레이어와 상호작용 수 있는 시스템으로,

친구 신청 시스템과 친구 리스트를 확인할 수 있는 페이지로 이루어져 있습니다.

 

핵심 시스템

(1) 플레이어 확인

서로의 정보를 확인하기위해 Photon 기능을 활용하여

Player가 접속할 시 플레이어 정보를 서로 주고 받는 방식으로 동기화 하였습니다.

대상	Player 접속시 행동
Player	접속중인 Player에게 자신의 정보를 담은 RPC함수를 실행시켜 각자의 로컬데이터에 정보를 저장.
Master Client	접속한 Player에게 접속중인 모든 Player의 데이터를 저장시키는 RPC함수 실행

 

(2) 친구 신청

서로의 정보를 확인하기위해 Photon 기능을 활용하여

Player가 접속할 시 플레이어 정보를 서로 주고 받는 방식으로 동기화 하였습니다.

 

이렇게 상대방의 정보를 확인했으면, 원하는 상대방에게 친구 신청을 보내야 했습니다.

PunRPC를 활용하여 자신의 정보가 포함된 함수를 상대방에게 실행시키는 것으로

의사를 주고 받는 기능을 구현했습니다.

플레이어(A)는 다른 플레이어(B)를 클릭하여 친구 신청을 할 수 있습니다.

 

B에게는 누구로부터 친구 신청이 들어왔는지 알 수 있어야 했기 때문에,

A가 친구 신청을 보낼시 B에게 자신의 UID와 닉네임을 전달하였습니다.

 

B가 친구 수락을 진행하면 B의 친구 리스트에 A를 추가하는 동시에

A에게 자신의 B의 정보를 보내 A친구 리스트에 추가 시키는 코드를 실행시켰습니다.

 

본 프로젝트에서는 Photon PUN2를 사용하여 PunRPC 함수를 통해 신청/수락 정보를 전송하였습니다.

 

(3) 친구 리스트

친구 등록이 완료된 친구는 친구 리스트에서 확인이 가능합니다.플레이어가 친구 리스트를 확인하기 위해서는 친구 목록에 해당하는 플레이어의 정보를 가져와야 했습니다.

친구 목록을 DataBase에서 가지고 오는 코스트를 줄이고자

친구 등록시, 로컬과 DataBase 모든 공간에 데이터를 저장하게 하였습니다.

이로써 로컬에 저장된 친구 정보 만으로도 DataBase의 친구 Player의 정보를 가지고 올 수 있었습니다.