"2분반-쌀장수"의 두 판 사이의 차이

cdc wiki
이동: 둘러보기, 검색
(개념설계안)
(기술적 기대효과)
 
(같은 사용자의 중간 판 35개는 보이지 않습니다)
50번째 줄: 50번째 줄:
 
*전 세계적인 기술현황
 
*전 세계적인 기술현황
 
**Optimistic rollup
 
**Optimistic rollup
***블록체인에서 트랜잭션 처리의 효율성을 높이기 위해 고안된 스케일링 솔루션이다. 모든 트랜잭션이 유효하다고 가정하고 검증 없이 블록에 바로 추가하는 것이 큰 특징이며, 사기 증명 메커니즘을 통해 잘못된 트랜잭션을 처리한다. 이 방식을 이용하면 메인체인보다 더 많고 빠르고 저렴하게 트랜잭션을 처리할 수 있다.
+
:::블록체인에서 트랜잭션 처리의 효율성을 높이기 위해 고안된 스케일링 솔루션이다. 모든 트랜잭션이 유효하다고 가정하고 검증 없이 블록에 바로 추가하는 것이 큰 특징이며, 사기 증명 메커니즘을 통해 잘못된 트랜잭션을 처리한다. 이 방식을 이용하면 메인체인보다 더 많고 빠르고 저렴하게 트랜잭션을 처리할 수 있다.
  
 
**Zero knowledge proof
 
**Zero knowledge proof
***정보를 알고 있음을 보이고 싶은 prover가 이를 검증하고 싶은 verifier에게 정보를 제공하지 않고 증명하는 방식이다. Prover가 Challenge 과정에서 Verifier에게 올바를 value를 제공함으로써, Verifier는 Prover를 확률적으로 신뢰하고, 이를 반복해 Prover가 정보를 가지고 있음을 확신할 수 있다.
+
:::정보를 알고 있음을 보이고 싶은 prover가 이를 검증하고 싶은 verifier에게 정보를 제공하지 않고 증명하는 방식이다. Prover가 Challenge 과정에서 Verifier에게 올바를 value를 제공함으로써, Verifier는 Prover를 확률적으로 신뢰하고, 이를 반복해 Prover가 정보를 가지고 있음을 확신할 수 있다.
  
 
**challenge based verification
 
**challenge based verification
***이 프로토콜은 아비트럼의 부정확하거나 악의적인 상태 보고를 방지하기 위해 고안된 프로토콜이다. 매니저가 제출한 스마트 계약의 상태에 검증자가 이의를 제기(도전)하면 이 프로토콜이실행된다. 도전이 성공한다면 매니저는 페널티를 받고 도전을 한 검증자는 보상을 받으며 실패한다면 그 반대이다. 이 프로토콜과 optimistic rollup 기술로 인해 문제가 발생시에만 검증 작업을 해서 효율성을 극대화한다.
+
:::이 프로토콜은 아비트럼의 부정확하거나 악의적인 상태 보고를 방지하기 위해 고안된 프로토콜이다. 매니저가 제출한 스마트 계약의 상태에 검증자가 이의를 제기(도전)하면 이 프로토콜이실행된다. 도전이 성공한다면 매니저는 페널티를 받고 도전을 한 검증자는 보상을 받으며 실패한다면 그 반대이다. 이 프로토콜과 optimistic rollup 기술로 인해 문제가 발생시에만 검증 작업을 해서 효율성을 극대화한다.
  
 
**off-chain computation
 
**off-chain computation
***블록체인 외부에서 복잡한 연산을 처리한 후 결과만 블록체인에 기록하는 방식으로, 확장성, 성능 및 비용 효율성을 높이기 위해 사용됩니다. 대표적인 구현 방식으로는 Layer 2 솔루션, 상태 채널, 오라클이 있으며, 이를 통해 블록체인의 느린 처리 속도와 높은 수수료 문제를 해결할 수 있습니다.
+
:::블록체인 외부에서 복잡한 연산을 처리한 후 결과만 블록체인에 기록하는 방식으로, 확장성, 성능 및 비용 효율성을 높이기 위해 사용됩니다. 대표적인 구현 방식으로는 Layer 2 솔루션, 상태 채널, 오라클이 있으며, 이를 통해 블록체인의 느린 처리 속도와 높은 수수료 문제를 해결할 수 있습니다.
  
 
*특허조사 및 특허 전략 분석
 
*특허조사 및 특허 전략 분석
80번째 줄: 80번째 줄:
 
*경쟁제품 조사 비교
 
*경쟁제품 조사 비교
 
**Axie Infinity
 
**Axie Infinity
***초기에 디자인된 P2E 게임인 만큼 완전한 탈 중앙화가 아닌 일부 게임 상품을 게임사에서 자체적으로 발행한 가상화폐를 사용함 이로인해 문제가 발생한 이력또한 있는만큼 완전한 탈 중앙화를 지향해 차별점을 둠
+
:::초기에 디자인된 P2E 게임인 만큼 완전한 탈 중앙화가 아닌 일부 게임 상품을 게임사에서 자체적으로 발행한 가상화폐를 사용함 이로인해 문제가 발생한 이력또한 있는만큼 완전한 탈 중앙화를 지향해 차별점을 둠
 
**2048
 
**2048
***2048게임의 경우 오프라인 환경에서 개인이 한 판씩 즐기는 게임이고 아이템이 존재하지 않는다. 반면 이번에 출시할 게임의 경우 온라인 리더보드를 구현하여 유저간의 순위가 표시될 수 있게 하고 그 순위에 따른 보상을 차등화하여 더 높은 점수 획득을 위한 유인으로 삼는다. 추가로 사망 후 부활과 블록 제거와 같은 아이템을 추가하여 게임을 더 다채롭게 즐길 수 있도록 구현할 예정이다.
+
:::2048게임의 경우 오프라인 환경에서 개인이 한 판씩 즐기는 게임이고 아이템이 존재하지 않는다. 반면 이번에 출시할 게임의 경우 온라인 리더보드를 구현하여 유저간의 순위가 표시될 수 있게 하고 그 순위에 따른 보상을 차등화하여 더 높은 점수 획득을 위한 유인으로 삼는다. 추가로 사망 후 부활과 블록 제거와 같은 아이템을 추가하여 게임을 더 다채롭게 즐길 수 있도록 구현할 예정이다.
  
 
*마케팅 전략 제시
 
*마케팅 전략 제시
**기존에 존재하던 2048과 같은 게임을 오프라인에서만 즐길 수 있던 점에서 벗어나 다른 유저들과  
+
**기존에 존재하던 2048과 같은 게임을 오프라인에서만 즐길 수 있던 점에서 벗어나 다른 유저들과 경쟁하며 플레이 가능한 점을 강조한다. 또한 아이템의 추가로 더 다채로운 방식의 즐거운 게임 플레이가 가능하고 기존 전략의 부재로 상대적으로 난이도가 높게 느꼈던 유저라면 아이템을 통해 더 높은 점수를 기록할 수 있음을 강조한다.
경쟁하며 플레이 가능한 점을 강조한다. 또한 아이템의 추가로 더 다채로운 방식의 즐거운 게임 플레이가 가능하고 기존 전략의 부재로 상대적으로 난이도가 높게 느꼈던 유저라면 아이템을 통해 더 높은 점수를 기록할 수 있음을 강조한다.
 
 
**게임을 통하여 경쟁에 따른 보상과 금융시장에 대한 이해를 높일 수 있다는 점을 강조하여 게임이라는 여가활동을 통해 스트레스를 해소할 수 있을뿐만 아니라 동시에 가상화폐에 및 금융 시장 원리에 대한 공부와 체험이 가능함을 어필한다.  
 
**게임을 통하여 경쟁에 따른 보상과 금융시장에 대한 이해를 높일 수 있다는 점을 강조하여 게임이라는 여가활동을 통해 스트레스를 해소할 수 있을뿐만 아니라 동시에 가상화폐에 및 금융 시장 원리에 대한 공부와 체험이 가능함을 어필한다.  
 
**자체 발행 토큰이 아닌 여러 거래소에 상장된 토큰인 아비트럼을 차용하여 신뢰성이 높음을 강조하고 거래량이 많고 시가총액이 높음을 근거로 보유시 좋은 결실을 획득할 수 있는 유망한 재화임을 알린다.
 
**자체 발행 토큰이 아닌 여러 거래소에 상장된 토큰인 아비트럼을 차용하여 신뢰성이 높음을 강조하고 거래량이 많고 시가총액이 높음을 근거로 보유시 좋은 결실을 획득할 수 있는 유망한 재화임을 알린다.
92번째 줄: 91번째 줄:
 
===개발과제의 기대효과===
 
===개발과제의 기대효과===
 
====기술적 기대효과====
 
====기술적 기대효과====
내용
+
*Optimistic rollup 방식을 사용하면서 더 높은 tps와 저렴한 fee로 네트워크를 이용할 수 있음
 +
*Zero knowledge proof 방식으로 사용하여 트랜잭션을 처리함으로써 프라이버시와 보안을 강화할 수 있음
 +
*Zero knowledge proof scaling solution 네트워크의 성능을 향상시킴
 +
 
 
====경제적, 사회적 기대 및 파급효과====
 
====경제적, 사회적 기대 및 파급효과====
내용
+
*여지껏 해외에만 존재해 왔던 p2e게임을 선보이며 대한민국 게임 산업계에서 새로이 개발 가능한 형태의 게임 모델을 제시함
 +
*거동이 불편하다 등의 이유로 노동을 통한 금융 가치 생산이 어려운 사람들이 경제활동을 시작할 수 있도록 간접적으로 지원함
 +
*한국사회에는 생소한 가상화폐와 게임이 결합된 형태의 게임을 소개하고 많은 유저들이 이를 즐길 수 있게 함
  
 
===기술개발 일정 및 추진체계===
 
===기술개발 일정 및 추진체계===
 
====개발 일정====
 
====개발 일정====
내용
+
[[파일:캡스톤 일정.png]]
 +
 
 
====구성원 및 추진체계====
 
====구성원 및 추진체계====
내용
+
*김민중:
 +
::서울시립대학교에 재학중인 학부생으로 컴퓨터과학을 전공중인 4학년 학생 개발자. 이번 프로젝트에서 Unity 엔진을 사용하여 게임 개발 부분을 담당한다.
 +
 
 +
*김정훈:
 +
::서울시립대학교에 재학중인 학부생으로 컴퓨터과학을 전공중인 4학년 학생 개발자. 이번 프로젝트에서 React를 사용하여 프론트엔드 부분을 담당한다.
 +
 
 +
*백승현:
 +
::서울시립대학교에 재학중인 학부생으로 컴퓨터과학을 전공중인 4학년 학생 개발자. 이번 프로젝트에서 Java/Spring을 사용하여 백엔드 부분을 담당한다.
 +
 
 +
*신희용:
 +
::서울시립대학교에 재학중인 학부생으로 컴퓨터과학을 전공중인 4학년 학생 개발자. 이번 프로젝트에서 Solidity를 사용하여 스마트 컨트랙트 부분을 담당한다.
  
 
==설계==
 
==설계==
108번째 줄: 123번째 줄:
  
 
====평가 내용====
 
====평가 내용====
직관적이고 깔끔한 UI/UX 디자인을 통해 사용자 경험을 향상시킨다. 또 사용자 피드백을 잘 반영하여 지속적으로 시스템을 개선시켜 유저의 충성도를 높인다.
+
*직관적이고 깔끔한 UI/UX 디자인을 통해 사용자 경험을 향상시킨다. 또 사용자 피드백을 잘 반영하여 지속적으로 시스템을 개선시켜 유저의 충성도를 높인다.
P2E의 핵심인 공정한 토큰 분배는 사용자 만족도를 높이는 중요한 요소이다. 서버를 안정시키고 최적화된 알고리즘을 통해 원활한 분배를 하도록 한다.
+
*P2E의 핵심인 공정한 토큰 분배는 사용자 만족도를 높이는 중요한 요소이다. 서버를 안정시키고 최적화된 알고리즘을 통해 원활한 분배를 하도록 한다.
경쟁 요소를 추가하여 사용자 참여를 독려한다. 순위에 따라 보상을 차등화하면서 지속적인 경쟁을 유도해 사용자 이탈율을 낮출 수 있다.
+
*경쟁 요소를 추가하여 사용자 참여를 독려한다. 순위에 따라 보상을 차등화하면서 지속적인 경쟁을 유도해 사용자 이탈율을 낮출 수 있다.
고득점을 기록하기 위한 아이템 판매를 통해 수익을 증가시킨다. 그러나 지나치게 상업화되어 사용자가 유출되지 않도록 주의하고 사용자 경험을 저하시키지 않는 선에서 운영한다.
+
*고득점을 기록하기 위한 아이템 판매를 통해 수익을 증가시킨다. 그러나 지나치게 상업화되어 사용자가 유출되지 않도록 주의하고 사용자 경험을 저하시키지 않는 선에서 운영한다.
정기적인 업데이트를 통해 사용자에게 새로운 콘텐츠와 기능을 제공하여 지속적인 흥미를 유도한다. 이 과정에서 버그 수정과 보안 패치가 포함되어야 하며, 이를 통해 사용자 신뢰도를 높이도록 한다.
+
*정기적인 업데이트를 통해 사용자에게 새로운 콘텐츠와 기능을 제공하여 지속적인 흥미를 유도한다. 이 과정에서 버그 수정과 보안 패치가 포함되어야 하며, 이를 통해 사용자 신뢰도를 높이도록 한다.
  
 
===개념설계안===
 
===개념설계안===
 +
*게임 ui : 최고점수 , 현재 점수 , 각종 아이템과 게임보드를 직관적으로 구성한다
  
 
[[파일:개념설계안-1.png]]
 
[[파일:개념설계안-1.png]]
 
+
*게임보드를 매트릭스로 매핑하여 데이터를 관리해 아이템을 구현한다
게임 ui : 최고점수 , 현재 점수 , 각종 아이템과 게임보드를 직관적으로 구성한다
 
게임보드를 매트릭스로 매핑하여 데이터를 관리해 아이템을 구현한다
 
 
 
 
예시:
 
예시:
board = [ [2, 2, 4, 8],
+
[ [2, 2, 4, 8],
 
   [16, 4, 8, 4],  
 
   [16, 4, 8, 4],  
 
   [2, 8, 4, 2],  
 
   [2, 8, 4, 2],  
 
   [0, 4, 0, 2] ]
 
   [0, 4, 0, 2] ]
게임 보드의 상황을 지속적으로 저장, undo 아이템을 사용하면 저장된 데이터를 불러와 보드를 재구성
+
*게임 보드의 상황을 지속적으로 저장, undo 아이템을 사용하면 저장된 데이터를 불러와 보드를 재구성
 +
 
 +
*onlyOwnerModifier 모디파이어를 통해 오직 관리자만이 claim 함수를 호출 할 수 있게하여 reentrancy attack등 여러 해킹 방법을 원천봉쇄하여 보안을 높인다. claim 함수 또한 기존 토큰 컨트랙트의 transfer 함수를 호출하는 방식을 이용하여 gas fee를 최적화 한다.
  
 
[[파일:개념설계안-2.png]]
 
[[파일:개념설계안-2.png]]
 
◇ onlyOwnerModifier 모디파이어를 통해 오직 관리자만이 claim 함수를 호출 할 수 있게하여 reentrancy attack등 여러 해킹 방법을 원천봉쇄하여 보안을 높인다. claim 함수 또한 기존 토큰 컨트랙트의 transfer 함수를 호출하는 방식을 이용하여 gas fee를 최적화 한다.
 
  
 
===이론적 계산 및 시뮬레이션===
 
===이론적 계산 및 시뮬레이션===
토큰 보상 시뮬레이션  
+
* 토큰 보상 시뮬레이션  
- 주간 리더보드 순위별 토큰 분배량 시뮬레이션  
+
** 주간 리더보드 순위별 토큰 분배량 시뮬레이션  
* 1위: 5 ARB  
+
::: 1위: 5 ARB  
* 2위: 3 ARB  
+
::: 2위: 3 ARB  
* 3위: 1 ARB  
+
::: 3위: 1 ARB  
- 예상 필수 주간 토큰 소모량: 9 ARB  
+
** 예상 필수 주간 토큰 소모량: 9 ARB  
- 연간 필수 필요 토큰량: 468 ARB  
+
** 연간 필수 필요 토큰량: 468 ARB  
  
스마트 컨트랙트 가스비 분석  
+
* 스마트 컨트랙트 가스비 분석  
- 토큰 전송 시 평균 가스비: 21,000 gas  
+
** 토큰 전송 시 평균 가스비: 21,000 gas  
- Arbitrum 네트워크 평균 가스 가격: 0.001 gwei  
+
** Arbitrum 네트워크 평균 가스 가격: 0.001 gwei  
- 주간 보상 지급 시 예상 가스비: 약 0.000021 ETH  
+
** 주간 보상 지급 시 예상 가스비: 약 0.000021 ETH  
  
서버 부하 시뮬레이션  
+
* 서버 부하 시뮬레이션  
- 동시 접속자 수: 최대 100명 가정  
+
** 동시 접속자 수: 최대 100명 가정  
- 필요 서버 사양: * CPU: t2.medium (2 vCPU) * RAM: 4GB * Storage: 20GB  
+
** 필요 서버 사양: * CPU: t2.medium (2 vCPU) * RAM: 4GB * Storage: 20GB  
- 예상 월간 트래픽: 약 50GB
+
** 예상 월간 트래픽: 약 50GB
  
 
===소프트웨어 상세 설계===
 
===소프트웨어 상세 설계===
초기 기획 단계에서 웹 서비스 게임으로 가정하였고, JavaScript로 작성된 오픈 소스를 찾아 이를 이용하려 했으나, 게임에서 사용할 리소스 파일들을 활용하는데 어려움을 겪었으며, 유니티를 이용해 게임을 수정하기 위해 C#코드로 수정하는 과정에서 시간이 너무 지체된다고 판단하여 유니티를 사용한 오픈 소스 코드를 찾아 이를 수정하여 구현하기로 결정했다.
+
* 초기 기획 단계에서 웹 서비스 게임으로 가정하였고, JavaScript로 작성된 오픈 소스를 찾아 이를 이용하려 했으나, 게임에서 사용할 리소스 파일들을 활용하는데 어려움을 겪었으며, 유니티를 이용해 게임을 수정하기 위해 C#코드로 수정하는 과정에서 시간이 너무 지체된다고 판단하여 유니티를 사용한 오픈 소스 코드를 찾아 이를 수정하여 구현하기로 결정했다.
오픈소스 출처 : https://goraniunity2d.blogspot.com/2018/10/2048.html
+
::오픈소스 출처 : https://goraniunity2d.blogspot.com/2018/10/2048.html
  
게임의 규칙과 진행을 담당하는 GameManager 클래스와 타일의 움직임을 제어하는 Moving 클래스, 게임 내에서 사용되는 아이템의 수량과 같은 정보를 담당하는 ItemManager 클래스, 아이템의 정보를 외부와 주고 받기위해 파일을 만들기 위한 JsonfileHandler 클래스로 구성했다.  
+
* 게임의 규칙과 진행을 담당하는 GameManager 클래스와 타일의 움직임을 제어하는 Moving 클래스, 게임 내에서 사용되는 아이템의 수량과 같은 정보를 담당하는 ItemManager 클래스, 아이템의 정보를 외부와 주고 받기위해 파일을 만들기 위한 JsonfileHandler 클래스로 구성했다.  
  
GameManager 클래스는 인스턴스가 하나만 존재하므로 싱글턴 패턴을 사용했고 타일의 생성과 병합을 판단하는 기능을 한다. 게임의 실시간 상태를 저장하고 점수도 해당 클래스에서 조작한다. 게임에 존재하는 3종류의 아이템도 해당 클래스 내부에 존재한다. 클래스의 흐름은 Start() 메서드에서 초기 타일을 생성하고 입력을 판단해 타일의 이동과 병합, 아이템의 사용을 인식 하고 이에따른 점수 변화를 반영한다. 게임이 끝났을때 게임 종료 UI를 띄우는 기능도 담당한다.
+
* GameManager 클래스는 인스턴스가 하나만 존재하므로 싱글턴 패턴을 사용했고 타일의 생성과 병합을 판단하는 기능을 한다. 게임의 실시간 상태를 저장하고 점수도 해당 클래스에서 조작한다. 게임에 존재하는 3종류의 아이템도 해당 클래스 내부에 존재한다. 클래스의 흐름은 Start() 메서드에서 초기 타일을 생성하고 입력을 판단해 타일의 이동과 병합, 아이템의 사용을 인식 하고 이에따른 점수 변화를 반영한다. 게임이 끝났을때 게임 종료 UI를 띄우는 기능도 담당한다.
  
Moving 클래스는 타일의 움직임등을 제어하는데 필요한 변수등을 담고 있다. 타일이 이동중인지 여부를 나타내거나 타일이 병합되었는지 등을 판단하는 bool형 변수가 존재하고 타일이 이동해야 할 목표 좌표를 저장하는 변수가 존재한다.
+
* Moving 클래스는 타일의 움직임등을 제어하는데 필요한 변수등을 담고 있다. 타일이 이동중인지 여부를 나타내거나 타일이 병합되었는지 등을 판단하는 bool형 변수가 존재하고 타일이 이동해야 할 목표 좌표를 저장하는 변수가 존재한다.
  
ItemManager 클래스는 아이템의 수량관리 및 아이템의 현황을 UI에 반영하는 기능을 담당하는데 게임내의 데이터가 외부와 소통하는 유일한 요소이므로 따로 클래스를 파서 관리하기로 결정하였다. 해당 클래스에 존재하는 메소드를 이용해 초기 아이템의 개수와 아이템 사용에 따른 개수 변화등을 게임 매니저에게 UI를 업데이트하도록 설계했다.  
+
* ItemManager 클래스는 아이템의 수량관리 및 아이템의 현황을 UI에 반영하는 기능을 담당하는데 게임내의 데이터가 외부와 소통하는 유일한 요소이므로 따로 클래스를 파서 관리하기로 결정하였다. 해당 클래스에 존재하는 메소드를 이용해 초기 아이템의 개수와 아이템 사용에 따른 개수 변화등을 게임 매니저에게 UI를 업데이트하도록 설계했다.  
  
JsonfileHandler 클래스는 게임이 끝났을때 점수와 아이템의 개수 등 외부로 전해야 하는 데이터를 Json파일의 형태로 저장하거나, 외부에서 Json파일을 읽어 데이터를 ItemManager에 전달하기 위해 만든 클래스이다. Json 파일의 경로를 담당하는 기능도 구현돼있다.
+
* JsonfileHandler 클래스는 게임이 끝났을때 점수와 아이템의 개수 등 외부로 전해야 하는 데이터를 Json파일의 형태로 저장하거나, 외부에서 Json파일을 읽어 데이터를 ItemManager에 전달하기 위해 만든 클래스이다. Json 파일의 경로를 담당하는 기능도 구현돼있다.
  
가상화폐 지갑인 MetaMask와 연동하는 동시에 디지털 서명을 받아오는 connectMetaMask() 함수와 이를 바탕으로 서버에 유저의 정보를 요청하는 fetchUserData(address, message, signature) 함수를 구현하였다. 이후 fetchUserData() 함수의 실행 성공 시, displayUserInfo() 함수를 구현해 My Page에 유저의 정보를 출력하였다. 또한 유저의 닉네임을 수정하는 updataNickname() 함수와, 2048 게임에 사용하는 아이템을 구매하는 buyItem() 함수를 구현하였다.
+
* 가상화폐 지갑인 MetaMask와 연동하는 동시에 디지털 서명을 받아오는 connectMetaMask() 함수와 이를 바탕으로 서버에 유저의 정보를 요청하는 fetchUserData(address, message, signature) 함수를 구현하였다. 이후 fetchUserData() 함수의 실행 성공 시, displayUserInfo() 함수를 구현해 My Page에 유저의 정보를 출력하였다. 또한 유저의 닉네임을 수정하는 updataNickname() 함수와, 2048 게임에 사용하는 아이템을 구매하는 buyItem() 함수를 구현하였다.
  
Leaderboard 접속 시, 최고 점수를 기준으로 상위 10명의 유저의 정보를 출력하는 fetchLeaderboard() 함수를 구현하였다. 등수, 닉네임, 최고 점수를 표시하고, 각 등수별로 수령하게 될 Token수를 함께 출력한다. 또한, My Page와 Leaderboard에서 Game Page로 넘어가기 위해 MetaMask의 연동 여부를 확인하는 event를 구현하였다.
+
* Leaderboard 접속 시, 최고 점수를 기준으로 상위 10명의 유저의 정보를 출력하는 fetchLeaderboard() 함수를 구현하였다. 등수, 닉네임, 최고 점수를 표시하고, 각 등수별로 수령하게 될 Token수를 함께 출력한다. 또한, My Page와 Leaderboard에서 Game Page로 넘어가기 위해 MetaMask의 연동 여부를 확인하는 event를 구현하였다.
  
인프라는 AWS EC2와 RDS를 사용하여 구성되었다. EC2를 통해 서버 애플리케이션을 호스팅하고, RDS를 통해 관계형 데이터베이스를 관리하도록 설계했다. 서버는 클라이언트 요청을 처리하며, RDS는 사용자 정보와 아이템 데이터를 저장한다. 정적 리소스는 Nginx를 통해 제공하여 클라이언트가 WebGL로 빌드된 게임을 로드할 수 있도록 했다.
+
* 인프라는 AWS EC2와 RDS를 사용하여 구성되었다. EC2를 통해 서버 애플리케이션을 호스팅하고, RDS를 통해 관계형 데이터베이스를 관리하도록 설계했다. 서버는 클라이언트 요청을 처리하며, RDS는 사용자 정보와 아이템 데이터를 저장한다. 정적 리소스는 Nginx를 통해 제공하여 클라이언트가 WebGL로 빌드된 게임을 로드할 수 있도록 했다.
  
백엔드 설계는 MVC 패턴을 기반으로 구성되었다. 클라이언트 요청은 Controller단에서 받아 Service 계층으로 전달되며 Service단에서는 비즈니스 로직을 처리하고 Dao 계층을 통해 데이터베이스와 상호작용한다. 이 구조를 통해 코드의 유지보수성을 높이고 계층 사이의 역할을 분리하였다. 또 데이터베이스 테이블은 사용자 정보를 관리하는 User 테이블과 사용자 아이템을 관리하는 Items 테이블로 분리하여 데이터 정규화를 수행했다. User 테이블은 사용자 고유의 Web3 지갑 주소를 PK로 사용하며, Items 테이블은 web3 지갑 주소를 FK로 하여 User 테이블을 참조한다.
+
* 백엔드 설계는 MVC 패턴을 기반으로 구성되었다. 클라이언트 요청은 Controller단에서 받아 Service 계층으로 전달되며 Service단에서는 비즈니스 로직을 처리하고 Dao 계층을 통해 데이터베이스와 상호작용한다. 이 구조를 통해 코드의 유지보수성을 높이고 계층 사이의 역할을 분리하였다. 또 데이터베이스 테이블은 사용자 정보를 관리하는 User 테이블과 사용자 아이템을 관리하는 Items 테이블로 분리하여 데이터 정규화를 수행했다. User 테이블은 사용자 고유의 Web3 지갑 주소를 PK로 사용하며, Items 테이블은 web3 지갑 주소를 FK로 하여 User 테이블을 참조한다.
  
로그인 과정에서는 클라이언트에서 전달받은 Web3 주소와 서명을 검증하여 사용자가 메시지에 실제로 서명한 지갑 소유자인지 확인한다. 이 과정에서 클라이언트는 MetaMask를 통해 메시지와 서명을 생성하고 서버는 클라이언트가 보낸 서명과 메시지를 사용하여 서명을 복구한 후 제공된 주소와 비교하는 방식으로 검증을 수행한다. 서명이 유효하면 데이터베이스에 정보가 있을시 로그인을 하고 없을시 새로운 사용자를 생성한다.
+
* 로그인 과정에서는 클라이언트에서 전달받은 Web3 주소와 서명을 검증하여 사용자가 메시지에 실제로 서명한 지갑 소유자인지 확인한다. 이 과정에서 클라이언트는 MetaMask를 통해 메시지와 서명을 생성하고 서버는 클라이언트가 보낸 서명과 메시지를 사용하여 서명을 복구한 후 제공된 주소와 비교하는 방식으로 검증을 수행한다. 서명이 유효하면 데이터베이스에 정보가 있을시 로그인을 하고 없을시 새로운 사용자를 생성한다.
  
 
==결과 및 평가==
 
==결과 및 평가==
 
===완료 작품의 소개===
 
===완료 작품의 소개===
 
====프로토타입 사진 혹은 작동 장면====
 
====프로토타입 사진 혹은 작동 장면====
내용
+
[[파일:프로토타입_3.png]]
 +
[[파일:프로토타입_2.png]]
 +
[[파일:프로토타입.png]]
 +
 
 
===관련사업비 내역서===
 
===관련사업비 내역서===
내용
+
[[파일:정산내역.png]]
  
 
===완료작품의 평가===
 
===완료작품의 평가===
내용
+
[[파일:평가내용.png]]
  
 
===향후계획===
 
===향후계획===
  토크노믹스에 관련된 전반적인 부분 개선(아이템 구매 비용 및 포인트: 토큰 비율)
+
*토크노믹스에 관련된 전반적인 부분 개선(아이템 구매 비용 및 포인트: 토큰 비율)
  2048 외의 다른 미니게임
+
*2048 외의 다른 미니게임
  컨트랙트 프록시 패턴 업그레이드
+
*컨트랙트 프록시 패턴 업그레이드
  CI/CD 환경 구축으로 무중단 배포
+
*CI/CD 환경 구축으로 무중단 배포
  게임 내 UI/UX 딥블루 색상 디자인
+
*게임 내 UI/UX 딥블루 색상 디자인
  게임 내에서 사용할 수 있는 보다 많은 아이템
+
*게임 내에서 사용할 수 있는 보다 많은 아이템

2024년 12월 17일 (화) 22:13 기준 최신판

프로젝트 개요

기술개발 과제

국문 : 스마트 컨트랙트가 결합된 p2e 2048

영문 : p2e 2048

과제 팀명

쌀장수

지도교수

안상현 교수님

개발기간

2024년 9월 ~ 2024년 12월 (총 4개월)

구성원 소개

서울시립대학교 컴퓨터과학부 2019XX00** 백*현(팀장)

서울시립대학교 컴퓨터과학부 2018XX00** 김*훈

서울시립대학교 컴퓨터과학부 2019XX00** 김*중

서울시립대학교 컴퓨터과학부 2019XX00** 신*용

서론

개발 과제의 개요

개발 과제 요약

  • 간단하게 플레이 가능한 p2e게임을 개발한다.
  • 스마트 컨트랙트를 통해 가상화폐 분배 기능을 만든다.
  • 웹3월렛 로그인 구현을 통해 가상화폐 개인 지갑과 게임 환경을 직접 연결 가능하게 제작한다.
  • 게임 점수를 일정 주기로 정산하여 유저들의 순위를 표현하는 리더보드 구현한다.
  • 서버와 데이터베이스 등의 인프라를 바탕으로 게임 환경 유지 및 유저의 포인트와 토큰 소유량을 모니터링한다.
  • 다중 접속이 가능한 환경을 제공한다.

개발 과제의 배경

  • 높아지는 가상 화폐에 대한 관심 속에서 일상적으로 접하기 쉬운 게임을 통해 부담 없이 투자와 시장에 대한 이해 고조
  • 즐거운 여가 활동을 통해 금융 시장과 가상화폐에 대한 이해 증진
  • 경제 활동이 힘든 소외계층에게 접근성이 좋은 방법으로 경제적 자립의 기회를 마련

개발 과제의 목표 및 내용

  • 스마트 컨트랙트를 통한 가상 화폐 발급 기능 구현
  • 원활하게 플레이 가능한 게임 환경 구현
  • 항상 게임에 접속 가능한 무중단 배포 환경 제공
  • 다중 접속 가능한 환경 제공

관련 기술의 현황

관련 기술의 현황 및 분석(State of art)

  • 전 세계적인 기술현황
    • Optimistic rollup
블록체인에서 트랜잭션 처리의 효율성을 높이기 위해 고안된 스케일링 솔루션이다. 모든 트랜잭션이 유효하다고 가정하고 검증 없이 블록에 바로 추가하는 것이 큰 특징이며, 사기 증명 메커니즘을 통해 잘못된 트랜잭션을 처리한다. 이 방식을 이용하면 메인체인보다 더 많고 빠르고 저렴하게 트랜잭션을 처리할 수 있다.
    • Zero knowledge proof
정보를 알고 있음을 보이고 싶은 prover가 이를 검증하고 싶은 verifier에게 정보를 제공하지 않고 증명하는 방식이다. Prover가 Challenge 과정에서 Verifier에게 올바를 value를 제공함으로써, Verifier는 Prover를 확률적으로 신뢰하고, 이를 반복해 Prover가 정보를 가지고 있음을 확신할 수 있다.
    • challenge based verification
이 프로토콜은 아비트럼의 부정확하거나 악의적인 상태 보고를 방지하기 위해 고안된 프로토콜이다. 매니저가 제출한 스마트 계약의 상태에 검증자가 이의를 제기(도전)하면 이 프로토콜이실행된다. 도전이 성공한다면 매니저는 페널티를 받고 도전을 한 검증자는 보상을 받으며 실패한다면 그 반대이다. 이 프로토콜과 optimistic rollup 기술로 인해 문제가 발생시에만 검증 작업을 해서 효율성을 극대화한다.
    • off-chain computation
블록체인 외부에서 복잡한 연산을 처리한 후 결과만 블록체인에 기록하는 방식으로, 확장성, 성능 및 비용 효율성을 높이기 위해 사용됩니다. 대표적인 구현 방식으로는 Layer 2 솔루션, 상태 채널, 오라클이 있으며, 이를 통해 블록체인의 느린 처리 속도와 높은 수수료 문제를 해결할 수 있습니다.
  • 특허조사 및 특허 전략 분석
    • 특허조사
    • 특허전략
      • 게임의 아이디어자체는 저작권에 의한 보호를 받을 수 없지만 UI , UX 등이 과도하게 유사하거나, 소스코드 자체에서 유사성이 발견될경우 특허법에 저촉될 수 있다. 이를 피하기 위해 오픈소스 코드를 사용하고, 창의적인 UI , UX를 개발한다.
      • Cross-Platform 게임에서 NFT전송에 관한 프레임워크가 특허로 출원되어 있으므로, 이를 위반하지 않도록 주의한다.
      • 컨트랙트를 작성 할 때 오픈 소스인 OpenZeppeline 라이브러리를 사용하고, 라이선스를 명시한다. OpenZeppeline 라이브러리는 MIT 라이선스를 사용하고 있어 상업적 이용이 가능하지만, 저작권 표시와 라이선스 사본을 포함해야하므로 이를 반드시 준수하도록 한다.
  • 기술 로드맵
    • Arbitrum One의 초기 버전 출시 (2021년 Q2)
    • TPS(초당 트랜잭션 수) 증가를 위한 기술적 최적화 (2022년 Q1)
    • Layer 3 솔루션에 대한 연구 및 구현 (2023년 Q2)
    • Zero Knowledge Proofs(ZKPs)와의 통합을 통해 프라이버시 및 보안 강화 (2023년 Q3)

시장상황에 대한 분석

  • 경쟁제품 조사 비교
    • Axie Infinity
초기에 디자인된 P2E 게임인 만큼 완전한 탈 중앙화가 아닌 일부 게임 상품을 게임사에서 자체적으로 발행한 가상화폐를 사용함 이로인해 문제가 발생한 이력또한 있는만큼 완전한 탈 중앙화를 지향해 차별점을 둠
    • 2048
2048게임의 경우 오프라인 환경에서 개인이 한 판씩 즐기는 게임이고 아이템이 존재하지 않는다. 반면 이번에 출시할 게임의 경우 온라인 리더보드를 구현하여 유저간의 순위가 표시될 수 있게 하고 그 순위에 따른 보상을 차등화하여 더 높은 점수 획득을 위한 유인으로 삼는다. 추가로 사망 후 부활과 블록 제거와 같은 아이템을 추가하여 게임을 더 다채롭게 즐길 수 있도록 구현할 예정이다.
  • 마케팅 전략 제시
    • 기존에 존재하던 2048과 같은 게임을 오프라인에서만 즐길 수 있던 점에서 벗어나 다른 유저들과 경쟁하며 플레이 가능한 점을 강조한다. 또한 아이템의 추가로 더 다채로운 방식의 즐거운 게임 플레이가 가능하고 기존 전략의 부재로 상대적으로 난이도가 높게 느꼈던 유저라면 아이템을 통해 더 높은 점수를 기록할 수 있음을 강조한다.
    • 게임을 통하여 경쟁에 따른 보상과 금융시장에 대한 이해를 높일 수 있다는 점을 강조하여 게임이라는 여가활동을 통해 스트레스를 해소할 수 있을뿐만 아니라 동시에 가상화폐에 및 금융 시장 원리에 대한 공부와 체험이 가능함을 어필한다.
    • 자체 발행 토큰이 아닌 여러 거래소에 상장된 토큰인 아비트럼을 차용하여 신뢰성이 높음을 강조하고 거래량이 많고 시가총액이 높음을 근거로 보유시 좋은 결실을 획득할 수 있는 유망한 재화임을 알린다.

개발과제의 기대효과

기술적 기대효과

  • Optimistic rollup 방식을 사용하면서 더 높은 tps와 저렴한 fee로 네트워크를 이용할 수 있음
  • Zero knowledge proof 방식으로 사용하여 트랜잭션을 처리함으로써 프라이버시와 보안을 강화할 수 있음
  • Zero knowledge proof scaling solution 네트워크의 성능을 향상시킴

경제적, 사회적 기대 및 파급효과

  • 여지껏 해외에만 존재해 왔던 p2e게임을 선보이며 대한민국 게임 산업계에서 새로이 개발 가능한 형태의 게임 모델을 제시함
  • 거동이 불편하다 등의 이유로 노동을 통한 금융 가치 생산이 어려운 사람들이 경제활동을 시작할 수 있도록 간접적으로 지원함
  • 한국사회에는 생소한 가상화폐와 게임이 결합된 형태의 게임을 소개하고 많은 유저들이 이를 즐길 수 있게 함

기술개발 일정 및 추진체계

개발 일정

캡스톤 일정.png

구성원 및 추진체계

  • 김민중:
서울시립대학교에 재학중인 학부생으로 컴퓨터과학을 전공중인 4학년 학생 개발자. 이번 프로젝트에서 Unity 엔진을 사용하여 게임 개발 부분을 담당한다.
  • 김정훈:
서울시립대학교에 재학중인 학부생으로 컴퓨터과학을 전공중인 4학년 학생 개발자. 이번 프로젝트에서 React를 사용하여 프론트엔드 부분을 담당한다.
  • 백승현:
서울시립대학교에 재학중인 학부생으로 컴퓨터과학을 전공중인 4학년 학생 개발자. 이번 프로젝트에서 Java/Spring을 사용하여 백엔드 부분을 담당한다.
  • 신희용:
서울시립대학교에 재학중인 학부생으로 컴퓨터과학을 전공중인 4학년 학생 개발자. 이번 프로젝트에서 Solidity를 사용하여 스마트 컨트랙트 부분을 담당한다.

설계

설계사양

제품의 요구사항

설계사양.png

평가 내용

  • 직관적이고 깔끔한 UI/UX 디자인을 통해 사용자 경험을 향상시킨다. 또 사용자 피드백을 잘 반영하여 지속적으로 시스템을 개선시켜 유저의 충성도를 높인다.
  • P2E의 핵심인 공정한 토큰 분배는 사용자 만족도를 높이는 중요한 요소이다. 서버를 안정시키고 최적화된 알고리즘을 통해 원활한 분배를 하도록 한다.
  • 경쟁 요소를 추가하여 사용자 참여를 독려한다. 순위에 따라 보상을 차등화하면서 지속적인 경쟁을 유도해 사용자 이탈율을 낮출 수 있다.
  • 고득점을 기록하기 위한 아이템 판매를 통해 수익을 증가시킨다. 그러나 지나치게 상업화되어 사용자가 유출되지 않도록 주의하고 사용자 경험을 저하시키지 않는 선에서 운영한다.
  • 정기적인 업데이트를 통해 사용자에게 새로운 콘텐츠와 기능을 제공하여 지속적인 흥미를 유도한다. 이 과정에서 버그 수정과 보안 패치가 포함되어야 하며, 이를 통해 사용자 신뢰도를 높이도록 한다.

개념설계안

  • 게임 ui : 최고점수 , 현재 점수 , 각종 아이템과 게임보드를 직관적으로 구성한다

개념설계안-1.png

  • 게임보드를 매트릭스로 매핑하여 데이터를 관리해 아이템을 구현한다

예시:

[ [2, 2, 4, 8],
  [16, 4, 8, 4], 
  [2, 8, 4, 2], 
  [0, 4, 0, 2] ]
  • 게임 보드의 상황을 지속적으로 저장, undo 아이템을 사용하면 저장된 데이터를 불러와 보드를 재구성
  • onlyOwnerModifier 모디파이어를 통해 오직 관리자만이 claim 함수를 호출 할 수 있게하여 reentrancy attack등 여러 해킹 방법을 원천봉쇄하여 보안을 높인다. claim 함수 또한 기존 토큰 컨트랙트의 transfer 함수를 호출하는 방식을 이용하여 gas fee를 최적화 한다.

개념설계안-2.png

이론적 계산 및 시뮬레이션

  • 토큰 보상 시뮬레이션
    • 주간 리더보드 순위별 토큰 분배량 시뮬레이션
1위: 5 ARB
2위: 3 ARB
3위: 1 ARB
    • 예상 필수 주간 토큰 소모량: 9 ARB
    • 연간 필수 필요 토큰량: 468 ARB
  • 스마트 컨트랙트 가스비 분석
    • 토큰 전송 시 평균 가스비: 21,000 gas
    • Arbitrum 네트워크 평균 가스 가격: 0.001 gwei
    • 주간 보상 지급 시 예상 가스비: 약 0.000021 ETH
  • 서버 부하 시뮬레이션
    • 동시 접속자 수: 최대 100명 가정
    • 필요 서버 사양: * CPU: t2.medium (2 vCPU) * RAM: 4GB * Storage: 20GB
    • 예상 월간 트래픽: 약 50GB

소프트웨어 상세 설계

  • 초기 기획 단계에서 웹 서비스 게임으로 가정하였고, JavaScript로 작성된 오픈 소스를 찾아 이를 이용하려 했으나, 게임에서 사용할 리소스 파일들을 활용하는데 어려움을 겪었으며, 유니티를 이용해 게임을 수정하기 위해 C#코드로 수정하는 과정에서 시간이 너무 지체된다고 판단하여 유니티를 사용한 오픈 소스 코드를 찾아 이를 수정하여 구현하기로 결정했다.
오픈소스 출처 : https://goraniunity2d.blogspot.com/2018/10/2048.html
  • 게임의 규칙과 진행을 담당하는 GameManager 클래스와 타일의 움직임을 제어하는 Moving 클래스, 게임 내에서 사용되는 아이템의 수량과 같은 정보를 담당하는 ItemManager 클래스, 아이템의 정보를 외부와 주고 받기위해 파일을 만들기 위한 JsonfileHandler 클래스로 구성했다.
  • GameManager 클래스는 인스턴스가 하나만 존재하므로 싱글턴 패턴을 사용했고 타일의 생성과 병합을 판단하는 기능을 한다. 게임의 실시간 상태를 저장하고 점수도 해당 클래스에서 조작한다. 게임에 존재하는 3종류의 아이템도 해당 클래스 내부에 존재한다. 클래스의 흐름은 Start() 메서드에서 초기 타일을 생성하고 입력을 판단해 타일의 이동과 병합, 아이템의 사용을 인식 하고 이에따른 점수 변화를 반영한다. 게임이 끝났을때 게임 종료 UI를 띄우는 기능도 담당한다.
  • Moving 클래스는 타일의 움직임등을 제어하는데 필요한 변수등을 담고 있다. 타일이 이동중인지 여부를 나타내거나 타일이 병합되었는지 등을 판단하는 bool형 변수가 존재하고 타일이 이동해야 할 목표 좌표를 저장하는 변수가 존재한다.
  • ItemManager 클래스는 아이템의 수량관리 및 아이템의 현황을 UI에 반영하는 기능을 담당하는데 게임내의 데이터가 외부와 소통하는 유일한 요소이므로 따로 클래스를 파서 관리하기로 결정하였다. 해당 클래스에 존재하는 메소드를 이용해 초기 아이템의 개수와 아이템 사용에 따른 개수 변화등을 게임 매니저에게 UI를 업데이트하도록 설계했다.
  • JsonfileHandler 클래스는 게임이 끝났을때 점수와 아이템의 개수 등 외부로 전해야 하는 데이터를 Json파일의 형태로 저장하거나, 외부에서 Json파일을 읽어 데이터를 ItemManager에 전달하기 위해 만든 클래스이다. Json 파일의 경로를 담당하는 기능도 구현돼있다.
  • 가상화폐 지갑인 MetaMask와 연동하는 동시에 디지털 서명을 받아오는 connectMetaMask() 함수와 이를 바탕으로 서버에 유저의 정보를 요청하는 fetchUserData(address, message, signature) 함수를 구현하였다. 이후 fetchUserData() 함수의 실행 성공 시, displayUserInfo() 함수를 구현해 My Page에 유저의 정보를 출력하였다. 또한 유저의 닉네임을 수정하는 updataNickname() 함수와, 2048 게임에 사용하는 아이템을 구매하는 buyItem() 함수를 구현하였다.
  • Leaderboard 접속 시, 최고 점수를 기준으로 상위 10명의 유저의 정보를 출력하는 fetchLeaderboard() 함수를 구현하였다. 등수, 닉네임, 최고 점수를 표시하고, 각 등수별로 수령하게 될 Token수를 함께 출력한다. 또한, My Page와 Leaderboard에서 Game Page로 넘어가기 위해 MetaMask의 연동 여부를 확인하는 event를 구현하였다.
  • 인프라는 AWS EC2와 RDS를 사용하여 구성되었다. EC2를 통해 서버 애플리케이션을 호스팅하고, RDS를 통해 관계형 데이터베이스를 관리하도록 설계했다. 서버는 클라이언트 요청을 처리하며, RDS는 사용자 정보와 아이템 데이터를 저장한다. 정적 리소스는 Nginx를 통해 제공하여 클라이언트가 WebGL로 빌드된 게임을 로드할 수 있도록 했다.
  • 백엔드 설계는 MVC 패턴을 기반으로 구성되었다. 클라이언트 요청은 Controller단에서 받아 Service 계층으로 전달되며 Service단에서는 비즈니스 로직을 처리하고 Dao 계층을 통해 데이터베이스와 상호작용한다. 이 구조를 통해 코드의 유지보수성을 높이고 계층 사이의 역할을 분리하였다. 또 데이터베이스 테이블은 사용자 정보를 관리하는 User 테이블과 사용자 아이템을 관리하는 Items 테이블로 분리하여 데이터 정규화를 수행했다. User 테이블은 사용자 고유의 Web3 지갑 주소를 PK로 사용하며, Items 테이블은 web3 지갑 주소를 FK로 하여 User 테이블을 참조한다.
  • 로그인 과정에서는 클라이언트에서 전달받은 Web3 주소와 서명을 검증하여 사용자가 메시지에 실제로 서명한 지갑 소유자인지 확인한다. 이 과정에서 클라이언트는 MetaMask를 통해 메시지와 서명을 생성하고 서버는 클라이언트가 보낸 서명과 메시지를 사용하여 서명을 복구한 후 제공된 주소와 비교하는 방식으로 검증을 수행한다. 서명이 유효하면 데이터베이스에 정보가 있을시 로그인을 하고 없을시 새로운 사용자를 생성한다.

결과 및 평가

완료 작품의 소개

프로토타입 사진 혹은 작동 장면

프로토타입 3.png 프로토타입 2.png 프로토타입.png

관련사업비 내역서

정산내역.png

완료작품의 평가

평가내용.png

향후계획

  • 토크노믹스에 관련된 전반적인 부분 개선(아이템 구매 비용 및 포인트: 토큰 비율)
  • 2048 외의 다른 미니게임
  • 컨트랙트 프록시 패턴 업그레이드
  • CI/CD 환경 구축으로 무중단 배포
  • 게임 내 UI/UX 딥블루 색상 디자인
  • 게임 내에서 사용할 수 있는 보다 많은 아이템