시리즈물로 제작 중입니다. 이전 내용과 이어집니다.
https://songmin9813.tistory.com/4(3. 게임 데이터 수집)
4. Picoke
뼈대만을 기획하고 설명하는 데에도 꽤나 많은 시간을 잡아먹었다. 게임 데이터를 만들고 이를 활용하는 첫 번째 게임으로 Picoke이라는 게임을 기획하였다.
가제는 Pic-Matching 프로젝트, 이후 ‘그림을(picture) 콕!’ 하고 눌러 정답을 확인하는 것에서 착안, 그리고 공작을 의미하는 peacoke의 언어유희인 Picoke으로 확정 짓게 되었다.
Aladdin에서 알파벳 하나 바꾼 Alardin부터 여기저기에 숨어있는 작명 센스가 비슷비슷한 것 같다…
해당 게임을 만들면서 스스로 지키고자 했던 규칙은 다음과 같았다. 이는 추후 만들게 될 이미지 기반 게임의 공통점이기도 하다.
- 플레이 타임은 최대 5분을 넘기지 않는 미니 게임으로 구성되어야 한다.
- 튜토리얼(연습 화면) 없이 한 화면안에 게임 설명이 이루어질 간단한 게임성을 가져야 한다.
- 사용자간의 인터랙션이 주된 콘텐츠가 되어야 한다.
상기 메커니즘적 제약사항이 아닌 FE/BE의 구성에 따른 기술적 제약사항은 다음과 같다.
- 한 번의 이미지 로드로 게임이 진행되어야 한다.
- WebView 형식으로 제작되는 콘텐츠여야 한다.
- 여러 해상도에서도 크기가 적응적으로 변화되어야 한다.
- 사용자 간의 전화통화(Web RTC)는 상시 진행 중임을 전제한다.
각 사용자가 게임을 시작하게 되면 사용자별로 6개의 키워드 별 랜덤 사진을 출력하게 한다. 그리고 상대방이 가지고 있는 사진 중 하나를 정답으로써 노출시키고 서로의 대화를 통해 상대방이 말하는 사진이 무엇인지를 모두 맞춰야 하는 게임으로 구성하였다.
해당 게임을 수행하기 위해 호출되는 데이터는 다음과 같다.
let inputData = {
subject: "other user's answer",
images: [
"random image0.png",
"random image1.png",
"random image2.png",
"random image3.png",
"random image4.png",
"random image5.png",
],
answer: "my answer(random image0~5)",
};
원래는 1. 정답 확인 버튼을 누르면 2. 상대방 기기 측에서 정답을 확인하는 것이 이상적인 형태일 것이다. 하지만 처음 만드는 게임이라 기기간 통신보다는 input/output data를 명시하는 방식에 대해서 구조화시키는 작업에 더 집중을 했던 것 같다.
이러한 이유로 정답 확인 버튼을 누르면 상대 기기 측에서 정답 체크 정보를 보내는 것이 아니라, 아예 같이 제공된 정답 정보를 클라이언트 단에서 자체검사하여 성공/실패 여부만을 FE로 보내는 것으로 로직을 작성하였다.
어찌 보면 하나의 꼼수라고도 할 수 있겠지만, FE 단에서도 유저 간 소통하는 방식에 대해서 명시를 한 것이 하나도 없었기에 일단은 돌아가는 게임 하나는 만들어보자! 하는 건 있었던 것 같다.
//Part of appEvent Listener
if (selected === inputData.answer) //correct!
window.ReactNativeWebView.postMessage(JSON.stringify({ type: "CORRECT", message: "TRUE" }));
else if (selected !== 0) //wrong!
window.ReactNativeWebView.postMessage(JSON.stringify({type: "CORRECT", message: "FALSE",}));
else console.log("Not in react native");
하나의 클라이언트에서 계속 성공/실패 여부를 들으면서 FE는 현재 맺어진 사용자가 모두 성공을 반환하는지를 검사한다. 둘이 모두 맞았을 경우 게임은 종료되고, 한 명이라도 틀렸을 경우 게임은 종료되지 않고 30초 동안 터치가 먹히지 않는 잠금 상태가 유지된다.
단, 이때도 실시간으로 전화통화가 진행중이기에 아무것도 클릭이 되지 않다 하더라도 인터랙션에 의한 정답 유추는 가능하도록 게임을 의도하였다.
이는 추가적으로 6개의 이미지를 완전 탐색하게 된다면 6*6=36가지 수밖에 존재하지 않았기 때문에라도 최소한의 안전장치는 필요하여 만든 잠금 시스템이기도 하였다.
게임이 정상적으로 종료된다면 BE에서 사전에 명시해놓은 output data를 생성하여 FE로 보내게 된다. 명시된 output data와 게임이 종료되는 로직이 포함된 코드는 아래의 코드와 같다.
//output data below
const outputData={
data: {
data: {//optional keys
is_cleared: false
},
play_time: 0,
trial: 0
},
end_time: "2022-10-18T07:26:09.676Z",//garbage value
start_time: new Date().toISOString()
};
//endGame logic below
const endGame = () => {
makeOutputData();
requestGameHasEnd();
};
const makeOutputData = (is_cleared=true) => {//save game datas
outputData.end_time = new Date().toISOString();
outputData.data.play_time = playSeconds - 1;
outputData.data.trial = failCount;
outputData.is_cleared = is_cleared;
};
const requestGameHasEnd = () => {
if (window.ReactNativeWebView)
window.ReactNativeWebView.postMessage(JSON.stringify({type: "OUTPUT_DATA",message: outputData}));
else
console.log("Not React Native WebView");
// alert({ message: "error" });
};
어찌 보면 단순해 보일 수 있는 로직을 구조화하고, 이를 간단한 미니게임으로 만들어 배포했다는 점에서 가장 큰 의의를 주고 싶은 첫 번째 게임이었다.
이러한 내용은 추후 다른 이미지 게임에 원활하게 확장/적용할 수 있는 기반을 마련해주었고, 여기서는 해보지 못한 기술/로직을 다른 게임에서 구현해보는 건 어떨까?라고 생각해보는 좋은 계기가 되었다.
'개발 > 소프트웨어 마에스트로' 카테고리의 다른 글
SWM에서 게임 개발로 살아남기(6. Deleterow) (0) | 2022.11.22 |
---|---|
SWM에서 게임 개발로 살아남기(5. Twigitizer) (0) | 2022.11.20 |
SWM에서 게임 개발로 살아남기(3. 게임 데이터 수집) (0) | 2022.11.16 |
SWM에서 게임 개발로 살아남기(2. 게임 기획) (2) | 2022.11.14 |
SWM에서 게임 개발로 살아남기(1. 개요) (0) | 2022.11.12 |