KiTFOx's Notepad 📝

일주일만에 쓰는 개발일지네

생각보다 시간이 엄청 빨리간다

임시 타이틀 화면을 제작하였다

어느정도 또 디자인 수정을 거칠것이지만 PoC 단계로는 이정도면 되지 않을까

동료분이 카드 시스템을 제작하셨다

나는 중간에서 클래스 구조를 좀더 짜고 수정하고 어느 위치에서 만나고 이런 것들을 의논하고 디자인을 좀 만지는 과정들을 거쳤다

중간중간에 ChessAI를 짜고 있었는데 중간에 한번 꼬인터라 클래스 구조를 엎고엎는 상황이 왔다

이것도 다 미래를 위한 값진 실패겠지

좀 더 속도를 내야겠다

2/7일 전에는 테스트해보고 마무리 할 수 있었으면 좋겠다

아무래도 설 이슈도 있고 정리 이슈도 있기 때문에ㅠ

다음에 해야할 것

1. ChessAI 빨리 마무리하기

2. 승리 조건 만들기

3. 카드 이미지 제작

4. 스테이지 보상 제작

이외에는 이펙트, 연출, 스테이지 레벨디자인 정도 필요하겠지

사실 이펙트, 연출도 필요없다 레벨디자인을 빨리 만들기 위해서는 코어루프를 만드는게 중요하니까

개발일지가 아니라 개발일기가 되어버린 느낌

다음번에 쓸 때는 좀 더 알찬 내용을 적어야겠는걸

마음이 심란하고 힘들때는 뭔가에 집착하는게 덜 힘들다

연락을 기다리며 개발에 집중해야겠다

아트가 없기 때문에 내가 어느정도 컨셉과 느낌을 잡아야하는데

아이패드로 끄적끄적 찾아보면서 그려보고 있다

여러가지 레퍼런스를 찾아보고 있는데 아트란 어렵다 언제나

이 게임의 초창기 기획안에 대해서 잠깐 설명을 하고 넘어가면 재미있을 것 같다

초기 기획안

이 게임은 게임랩 에픽프로젝트 때, "뭐예요, 내 성 돌려줘요"라는 기획에서부터 시작했다

기획의 제목은 기존의 다른 동료분의 기획에서 따온 제목이였다

새로운 기획안을 짜려고 했을 떄, 이것저것 게임을 찾아보다가 "네크로댄서"라는 게임이 재미있어보였고, 구매해서 해보았다

해당 구간에서 굉장히 재미있게 플레이 했고, 이러한 느낌의 한턴한턴 움직이는 방식을 채택하고 싶었다

그리고 당시에 갑자기 왜 빠지게 되었는지 모르겠지만 "쟈이아니즘 - 퉁퉁이"에 빠져서 "뺏어온다는 경험"을 유저가 느낄 핵심 경험으로 잡고 싶었다

그래서 정했던

3가지 Pillars

그리고 턴과 세뇌 시스템 구성

좀 더 자세하게 많지만 생략하겠다

여튼 이걸 들고갔는데, 사실 여러가지 검증 과정에서 룰의 오류가 많다는 의견을 받았고, 그 당시에는 드랍했던 부분이 있었다

보완하는 과정에서 유저들이 잘아는 룰이 있어야한다는 의견이 있어서 체스 룰을 가져오면 어떨까라는 생각을 가졌지만 포기했던 기획안이다

그러면서 찾아보았던 체스 룰을 따르는 게임인 "샷건킹"

하지만 체스룰을 따르면서 어떻게 재미있게 만들까? 라는 과정에서 드랍되었던 부분이 있었다

그 도중에 지금 동료분이 굉장히 흥미로워하면서 종이 PoC를 하는 과정에서 나도 꽤나 흥미가 갔었고 결론적으로 여유로워진 지금 개발해보자는 이야기를 하게 되었다

따라서 지금은 샷건킹을 레퍼로 많이 보고 있긴한데, 샷건킹은 로그라이크로써 굉장히 탄탄하게 잘 짜여져있는 듯하다

이것저것 끄적여보면서 그리고 있는 러프한 이미지를 던지고 이만 개발일지를 마쳐야겠다

현재 참고하고 있는 키워드들은 #스케치쉐이더 #흑백 #스탠실 이다

물론 많이 바뀔 것이다

기획의 틀이 정해졌고, 장르를 섞고 싶다는 나의 의견이 조금 반영되어 카드 + 변형체스 의 게임을 만들기로 결정이 되었다

턴제로 변경

기존 방식은 클릭을 통해서 턴이 넘어가는 형식이였다

하지만 카드형식으로 움직임과 가져오기(세뇌)를 조작하기 위해서 버튼 클릭 형식을 덜어내고, End Turn 버튼을 통해 둘의 턴이 바뀌도록 변경하였다

이 이유는 WHITE의 턴에서 여러장의 움직임 + 가져오기가 가능하도록 제작하기 위함이다

물론 코스트는 주어진다

블랙 체스 이동 제작

현재는 BLACK 턴일 때, 말들이 한번에 순서대로 이동하도록 제작했다

움직임 우선순위는 킹,퀸,룩,비숍,나이트,폰 순서이다

개발 파트를 분리해서 본격적인 작업에 돌입했다

동료분 - 기획 + 카드 드로우 개발(만능...ㄷ)

나 - ChessAI  개발 + 기획보조

빨리 마무리하면 카드 시스템 관련해서 여러가지 작업들을 진행하던가 아니면 아트쪽 부분을 한번 다듬을까 싶다

목표는 2/7일전에 마무리해서 itch.io에 무료로 올리는것!

아트적인부분들은 사실상 포기상태지만.. 어케든 안될까?ㅎㅎ..

클래스 설계 과정

분명 또 뒤엎고 뒤엎히겠지만 기록용이다

ChessAI 이동 알고리즘에 대해서 얘기한 내용들

아무래도 킹의 경우에는 무조건 상대 킹을 잡기 위한 행동을 하면 안되기 때문에 해당 내용들에 대해서 얘기를 나눴다

개발 일지 4번째나 되서 이 게임의 핵심 키워드가 뭐인지를 밝히자면,

니꺼도 내꺼, 내꺼는 내꺼! - 퉁퉁이 대사

결국, 제일 먼저 세운 재미는 "남의 것을 뻇어와서 내것으로 만든 후 패로 사용하는 재미"이다

핵심 재미 3가지는 슬슬 증명해야겠지

아마 조만간 제작하고, 뽑아내긴 해야할 것이다

PoC도 게임랩 친구들한테 한번 돌릴거니까

혹독한 피어리뷰를 받아보자..

추가로 만들 것

1. 블랙 체스말 체크메이트 가능한 최적의 위치 + 가장 움직이는 비용이 적은 곳 찾아서 이동시키기

2. 체크메이트 시스템 - 게임오버 조건 설정

조만간 체스룰을 따르는 코어루프를 제작할 수 있을 것 같다.

승리 조건에 대해서 다시 얘기해봐야하지만 기본적으로는 체스룰을 따라서 킹을 죽이면 게임을 이기는 형식으로 제작할 것 같다.

오늘 제작한 것

1. 갈 수 있는 곳을 표시하고 해당 지점으로 이동한 다음 해당 지점 안에 기물이 있으면 공격해서 없애버릴 수 있다.

2. 스테이지에 따라서 기물 종류에 따라 갯수가 달라지도록 제작(Scriptable Object 사용)

3. 기물의 종류와 숫자에 따라서 어느 위치에 배치되도록 제작

기본적으로 아래 룰을 따름

4 → 3 → 5 → 2 → 6 → 1 → 7

킹,퀸,룩,비숍,나이트로 맨 윗줄을 채우지 못했을 경우, 그 다음줄 부터 Pawn을 Spawn하도록 설정

다음에 제작할 것

1. 승리조건(체크메이트)

2. 체스말 종류와 생성순서에 따른 이동 우선순위 부여

3. 체스말 이동 제작

기본적으로 체스의 룰을 먼저 만들고 나서 생각하자! 라는 마인드로 만들고 있다

물론 체스룰만 따르는 것은 아니지만

카드로 이동을 주고, 새로운 스킬을 선택할 수 있게끔 만드는 턴제 게임을 만들 것이다

물론 중간에 기획이 바뀌고 새로운 것들이 추가될 수 있겠지만?

앞으로 더 만들 것!

1. 적 AI 시스템

2. 버그 수정

3. 카드 드로우 시스템

이건 크래프톤 정글 게임랩에서 Epic 프로젝트할 때 드랍되었더 내 아이디어인데 하루에 조금씩 한번 개발해보고자 한다

시간을 쪼개서 집중해서 조금씩 여러개를 개발해보는 방식을 한번 해볼까 싶다!

PoC 처럼 아주 작은 빌드를 만들어서 테스트해보고 재미있는지 보고싶어서 시작하는 것들이긴하다

뭐 덤으로 재미있으면 좀 더 개발해서 Itch.io에 올리고 그럴 생각이다

에픽프로젝트할 떄 굉장히 많은 아이디어들이 있었는데 그것들 다 PoC로 개발해보면 재미있지 않을까ㅎㅎ

일단 이 게임은 체스 룰을 따르기 때문에 체스 보드판을 먼저 만들었다

8x8 체스판을 제작하였고, 그 위에 체스 말들을 스폰하였다

파란색은 폰

갈색은 룩

양옆 노란색은 나이트(색상 변경해야겠네)

연두색은 비숍

핑크색은 퀸

노란색은 킹

으로 일단 구성하였다

PoC는 프리미티브(기본제공)가 국룰 아니겠는가!

ChessPiece라는 부모클래스를 생성하고 나머지 Chess 말들은 상속받아서 구성하는 형태로 제작하였다

차근차근 만들어 봅시다!

앞으로 해야할 일

1. 턴제로 만들기
2. 클릭하면 어디로 이동시킬 수 있는지 가시화하기(UI)
3. 체스 AI 만들기

IK 사용해서 한번 조작이 어려운 게임을 만들어보고자 한다

나름 재미있지않을까?!

PoC 느낌으로 빠르게 제작하는 것을 목표로 하고 있다

PoC 빨리 만들고 주변 사람들에게 반응을 한번 보고.. 또 다른거 개발하고 해야지

https://assetstore.unity.com/packages/tools/animation/fast-ik-139972

일단 IK란 무엇인가?

애니메이션에서 IK(Inverse Kinematics) 기술은 캐릭터나 객체의 말단(손이나 발) 위치를 설정하면, 해당 위치에 도달하기 위해 캐릭터의 관절(어깨, 팔꿈치, 손목 또는 허벅지, 무릎, 발목)이 자동으로 조정되는 기술

IK 특징

1. 목표 기반 움직임

2. 실시간 계산

3. 효율적이고 자연스러운 움직임

IK VS FK(정운동학 : Forward Kinematics)

FK (Forward Kinematics) : 관절들을 순서대로 직접 조작해서 말단 위치를 결정하는 방식

어깨 → 팔꿈치 → 손목 순으로 각도를 설정해야 손의 위치가 결정됨

장점 : 제어가 세밀하고 애니메이터가 원하는 자세를 정확히 구현 가능

단점 : 자연스러운 움직임을 만들기 위해 많은 수작업이 필요함

IK(Inverse Kinematics) : 말단의 목표 위치를 설정하면 나머지 관절들이 자동으로 조정됨

장점 : 캐릭터가 목표를 잡거나 바닥을 디디는 동작 등에서 매우 빠르고 직관적

단점 : 설정에 따라 비자연스러운 자세가 나올 수 있어 추가 조정이 필요

처음 이 게임을 만들고 싶은 것은 맥주를 그저 따르는 게임인데 잘 기울여야하는 게임이였다

IK를 활용해서 우스꽝스러운 게임을 만들고 싶었는데 IK를 활용하려고 하다보니까 내가 생각한 게임이 안나올수도 있겠다는 결론이 나는데..

Chanined Together나 이런 게임들은 IK를 활용한 게임이 아닌가? 싶기도 하고 좀 더 생각해봐야겠다

1. 문제 요약

좌표 평면을 좋아하는 진수는 x축과 y축이 직교하는 2차원 좌표평면에 점을 찍으면서 놀고 있음
진수는 두 양의 정수 k,d가 주어질 때 다음과 같이 점을 찍으려 함
원점 (0,0)으로부터 x축 방향으로 a*k(a=0,1,2,3...), y축 방향으로 b*k(b=0,1,2,3...)만큼 떨어진 위치에 점을 찍음
원점과 거리가 d를 넘는 위치에는 점을 찍지 않음 -> 반지름이 d인 원 안에서 모든 것을 해결함
k가 2, d가 4인 경우에는
(0,0),(0,2),(0,4),(2,0),(2,2),(4,0) 위치에 점을 찍어 총 6개의 점을 찍음
정수 k와 원점과의 거리를 나타내는 정수 d가 주어졌을 때, 점이 총 몇 개 찍히는지 return하는 solution 함수 완성

2. 코드

#include <string>
#include <vector>
#include <cmath>

using namespace std;


long long solution(int k, int d) {
    long long answer = 0;
    
    for(long long i=0;i<=d;i+=k){
        int y = sqrt(pow(d,2)-pow(i,2));
        answer+=y/(long long)k+1;
    }
    
    return answer;
}

3. 해설

이 문제에서 가장 주의해야할 점은 long long 이라는 자료형으로 변환인 것 같다

원점과의 거리가 d를 넘는 위치에는 점을 찍지 않는다는 전제 조건은 반지름이 d인 원 안에 모든 점들은 위치할 수 있다는 말과 같다

x 축의 방향으로는 a*k, y 축의 방향으로는 b*k 만큼 떨어진 위치에 점을 찍는다고하여서 k만큼 증가하는 for.문을 사용하면 된다

 int y = sqrt(pow(d,2)-pow(i,2));

y의 최댓값을 위의 코드로 구하고, 해당 최대 y값/k 를 하면 그 안에 b*k를 만족하는 갯수를 구할 수 있고, 0인경우를 포함해야하기 때문에 +1을 해준다

1. 문제 요약

k 개를 골라 상자 하나에 담아 판매
귤을 크기별로 분류했을 때 서로 다른 종류의 수를 최소화하고 싶음

처음에는 문제가 헷갈렸는데 결국 같은 크기의 귤을 모아서 최대한 판매하려고 하는 문제이다

2. 코드

#include <string>
#include <vector>
#include <algorithm>

using namespace std;


bool cmp(const pair<int,int>& lValue,const pair<int,int>& rValue){
    return lValue.second>rValue.second;
}

int solution(int k, vector<int> tangerine) {
    int answer = 0;
    
    vector<pair<int,int>> tangerinePair;
    
    sort(tangerine.begin(),tangerine.end());
    
    /*for(int i=0;i<tangerine.size();i++){
        printf("%d ",tangerine[i]);
    }
    printf("\n");*/
    
    int prev = tangerine[0];
    tangerinePair.push_back(make_pair(tangerine[0],0));
    for(int i=0;i<tangerine.size();i++){
        //printf("%d ",tangerine[i]);
        if(prev==tangerine[i]){
            tangerinePair[tangerinePair.size()-1].second++;
        }
        else{
            tangerinePair.push_back(make_pair(tangerine[i],1));
            prev=tangerine[i];
        }
    }
    //printf("\n");
    
    sort(tangerinePair.begin(),tangerinePair.end(),cmp);
    
    int count=0;
    for(int i=0;i<tangerinePair.size();i++){
        //printf("%d %d\n",tangerinePair[i].first,tangerinePair[i].second);
        if(count>=k) break;
        count+=tangerinePair[i].second;
        answer++;
    }
    
    
    return answer;
}

3. 해설

먼저 vector<int> tangerine 벡터를 오름차순으로 정렬합니다

정렬한 다음  vector<pair<int,int>> tangerinePair에 <귤의크기,갯수>를 담았다

int prev = tangerine[0];
tangerinePair.push_back(make_pair(tangerine[0],0));

for(int i=0;i<tangerine.size();i++){
    if(prev==tangerine[i]){
        tangerinePair[tangerinePair.size()-1].second++;
    }
    else{
        tangerinePair.push_back(make_pair(tangerine[i],1));
        prev=tangerine[i];
    }
}

그 후, 귤의 갯수에 따라 vector<pair<int,int> tangerinePiar를 정렬해주었다

sort(tangerinePair.begin(),tangerinePair.end(),cmp);

bool cmp(const pair<int,int>& lValue,const pair<int,int>& rValue){
    return lValue.second>rValue.second;
}

그리고 for문을 이용하여 중복되는 갯수들을 k와 비교하여 더해줘서 수를 넘어가면 break하도록 제작하여주었다

int count=0;
for(int i=0;i<tangerinePair.size();i++){
    if(count>=k) break;
    count+=tangerinePair[i].second;
    answer++;
}

1. 문제 요약

열은 컬럼, 행은 튜플
첫번째 컬럼은 기본키로서 모든 튜플에 대해 그 값이 중복되지 않도록 보장

(요약하자면 id 같은 고유 번호라는 것)

1. 해시 함수는 col, row_begin, row_end 을 입력으로 받음
2. 테이블의 튜플(행)을 col번째 컬럼의 값을 기준으로 오름차순 정렬을 하되, 
만약 그 값이 동일하면 기본키인 첫 번째 컬럼의 값을 기준으로 내림차순 정렬함

정렬된 데이터에서 S_i를 i번째 행의 튜플에 대해 각 컬럼의 값을 i로 나눈 나머지들의 합으로 정의
row_begin <= i <= row_end 인 모든 S_i를 누적하여 bitwise XOR 한 값을 해시 값으로서 반환함

2. 코드

#include <string>
#include <vector>
#include <algorithm>

using namespace std;

int sortIndex;

bool cmp(vector<int> lValue,vector<int> rValue){
    if(lValue[sortIndex]==rValue[sortIndex]) return lValue[0]>rValue[0];
    return lValue[sortIndex]<rValue[sortIndex];
}

int solution(vector<vector<int>> data, int col, int row_begin, int row_end) {
    int answer = 0;
    sortIndex=col-1;
    
    /*for(int i=0;i<data.size();i++){
        for(int j=0;j<data[i].size();j++){
            printf("%d ",data[i][j]);
        }
        printf("\n");
    }*/
    
    sort(data.begin(),data.end(),cmp);
    
    /*printf("\n\n");
    
    for(int i=0;i<data.size();i++){
        for(int j=0;j<data[i].size();j++){
            printf("%d ",data[i][j]);
        }
        printf("\n");
    }*/
    
    int s2;
    for(int i=row_begin-1;i<row_end;i++){
        s2=0;
        for(int j=0;j<data[i].size();j++){
            s2+=data[i][j]%(i+1);
            //printf("%d : %d %d ~~\n",(i+1),data[i][j],data[i][j]%(i+1));
        }
        //printf("%d !!\n",s2);
        answer= answer^s2;
    }
    
    
    return answer;
}

3. 해설

먼저, 테이블의 튜플을 col 번째 컬럼의 값을 기준으로 오름차순 정렬을 합니다

여기서 주의할 점은 col 번재 이기 떄문에 vector의 col-1의 값을 기준으로 정렬해야한다는 점입니다

int solution(vector<vector<int>> data, int col, int row_begin, int row_end) {
    int answer = 0;
    sortIndex=col-1;
    ...
}

bool cmp(vector<int> lValue,vector<int> rValue){
    if(lValue[sortIndex]==rValue[sortIndex]) return lValue[0]>rValue[0];
    return lValue[sortIndex]<rValue[sortIndex];
}

sortIndex라는 변수에 col-1을 할당해주고, algorithm 라이브러리의 sort함수와 제가 정의하는 cmp 비교함수를 이용하여 정렬을 진행했습니다

만약 비교 벡터들의 sortIndex 위치의 값이 같은 경우 기본키를 기준으로 내림차순 정렬을 진행하였습니다

그 후에는 ^ 연산자를 이용하여 XOR 비트 연산을 진행하였습니다

비트연산 XOR 이란?

베타적 OR 연산이라고도 부르는데

두 비트가 서로 다른 경우에만 1이 되고 그렇지 않으면 0이 되는 특이한 연산자

int s2;
for(int i=row_begin-1;i<row_end;i++){
    s2=0;
    for(int j=0;j<data[i].size();j++){
        s2+=data[i][j]%(i+1);
    }
    answer= answer^s2;
}

row_begin-1 에서 row_end까지 비트연산을 한 값들을 answer에 저장하였습니다

data[i][j]%(i+1)

는 정렬된 데이터에서 S_i를 i번째 행의 튜플(행)에 대해 각 컬럽의 값을 i로 나눈 나머지입니다

1. 문제 요약

절댓값이 10c 형태인 정수들이 적힌 버튼
현재 층 수에 버튼에 적혀 있는 값을 더한 층으로 이동
엘리베이터가 위치해 있는 층과 버튼의 값을 더한 결과가 0보다 작으면 엘리베이터는 움직이지 않음
0층이 가장 아래층
버튼 한번 당 돌 한개
최소한의 돌 최대한으로 내려가기
10단위로 나머지 계산
2,5,5,4 -> 16
1,6 -> 1+(10-6) = 5
7~9 인 경우 반올림해서 빼는 경우가 더 이득
1~5 인 경우 그냥 빼는 경우가 이득
2000 + 500 + 50 + 4
작은 결과들을 모아서 큰 결과 값을 만들 수 있는지 확인해보기

2. 코드

#include <string>
#include <vector>

using namespace std;

//최적의 사용 돌 갯수 구해서 answer에 더해주는 함수
void GetOptimalStoneCount(int& storey,int& answer){
    int count = storey%10;
    
    if(count<5) answer+=count;
    else{
        if(count==5&&storey%100<50){
            answer+=count;
        }
        else{
            answer+=10-count;
            storey=storey+10-count;
        }
    }
    storey/=10;
    //printf("%d, %d\n",storey,answer);
}

int solution(int storey) {
    int answer = 0;

    while(storey>1){
        GetOptimalStoneCount(storey,answer);
    }
    
    return answer+storey;
}

3. 해설

제가 선택한 알고리즘의 방법은 10씩 나눈다음 해당 값이 반올림이 가능한지 아닌지를 판별하는 것을 채택했습니다.

예를 들어, 맨 끝의 자리 숫자가 6이상인 경우 -6을 통해 6번 돌을 사용하는 것보다 한자릿수를 늘려서 처리하는 것이 이득입니다. 56의 경우 5+6 = 11 보다 4+6 = 10 의 경우 1의 이득을 더 볼 수 있습니다.

이러한 로직을 바탕으로 코드를 짜게 되면 최적의 돌을 구할 수 있습니다.

다만 5의 경우 주의해야할 점이 555, 545 이 경우입니다.

545의 경우 5+4+5 = 14가 최적의 돌의 경우의 수입니다.

만약 반올림을 해버리는 경우 5+5+5 = 15가 되기 때문에 더 많은 돌을 사용하게 됩니다.

555의 경우가 제일 헷갈려서 시간을 오래쓰게 되었습니다.

555의 경우,

560 -> +5  : 5번(+1)
600 -> +40 : 4번(+10)
1000 -> +400 : 4번(+100)
0 -> -1000 : 1번(-1000)

if(count==5&&storey%100<50){
	answer+=count;
}

해당 if문을 통해 10의 자리 수가5보다 작은 경우에는 반올림을 해주지 않고 그대로 - 를 감행하고, 반대의 경우에는 반올림을 진행하여 이득을 보는 형태로 코드를 사용하였습니다.

4. 테스트 케이스

999 -> 1+1 = 2

55 -> 5+5 = 10

75 -> 5+2+1 = 8

155 -> 5+4+2 = 11

545 -> 5+4+5 = 14

555 -> 5+4+4+1 = 14

이벤트 큐 패턴

메시지나 이벤트를 보내는 시점과 처리하는 시점을 디커플링함

보통의 이벤트는 동기적으로 연산

이벤트를 보내고, 처리하는 동안 스레드가 멈춰버리는 상황이 발생

이를 해결하고자 나온 것이 이벤트 큐 패턴이다

이벤트 발생 시, 명령을 담아 둘 공간이 필요한데 Queue에 이벤트를 담아둔다

튜토리얼 시스템에서 사용할 수 있음

그리고 이벤트가 순차적으로 진행이 되길 원할 때 사용할 수 있음

예를 들어 업적을 달성했을 때,

업적 달성에 대한 반응들이 나타나야함

만약 업적 달성이 Popup과 Sound를 출력하는데,

여러가지 업적을 한번에 달성했을 경우 해당 업적 달성에 대한 피드백을 동시적으로 출력하면 안되는 경우 FIFO 방식으로 처리할 수 있도록 이벤트 큐 패턴을 사용하면 된다

큐에 넣는 이유는 결과를 기다리지 않기 위해서이다

이벤트를 보내고, 처리하는 동안 스레드가 멈춰버리는 상황을 방지하기 위해서이다

이벤트 큐는 관찰차 패턴의 비동기형

주의사항

1. 모든 이벤트, 메시지 시스템은 피드백 루프가 생기면 안됨
2. 유기적으로 계속 연결되는 이벤트들을 넣으면 이벤트 큐 패턴을 사용하는 의미가 없어짐
3. 이벤트를 처리하는 코드 내에서는 이벤트를 보내지 않아야함

W02+는 나에게 있어서 시간과의 싸움이였다

포더킹에서 뽑은 주제에서 여러가지를 가지고 오고 싶었는데 주말에 경조사때문에 본가에 내려가야하는 일이 생겼다

결론적으로 만들고 싶은 게임은 포더킹의 룰을 따르는 턴제 게임이였는데

지금 생각해보면 4일(목,금,월) 동안 만들기에 너무 빡센 일정이 아니였나 싶다

이 당시에는 심지어 ChatGPT의 도움은 1도 받지 않아서 굉장히 비효율적인? 느린 코더였다

ChatGPT의 도움을 받게 된 이야기는 나중에 더 이야기하려고 한다

왜 필요한지 왜 하게되었는지? 왜 하면 좋은지? 왜 하면 안좋은지?

다시 돌아와서 내가 포더킹에서 가져오고자 했던 핵심 기능들은 이것들이였다

포더킹에서 가장 매력적이라 생각이 들었던 시스템은 동전 던지기와 역할을 이용한 전략을 통해 역전하는 것이였다.

결국 용병기사단이라는 게임을 만들었다

3명의 용병을 선택하고, 용병 3마리를 이용해서 제일 높은 곳까지 가서 보스를 깨면 되는 게임이다

낮에는 이동을 할 수 있고, 밤에는 타일 위에 몬스터가 소환되는 형식이였다

원래 컨셉은 최고의 술을 찾아 떠나는 컨셉이였는데 기획적으로는 취함 메커니즘이 있었다

약간 주기적으로 술을 마시지 않으면 스트레스를 받지만 술을 마시면 취함 상태가 되서 확률이 저하되는 그런 기획이였는데 ㅋㅋㅋ 이런것들을 넣기에는 너무 많은 시간이 걸릴것 같아 결국 모두 빠졌다

그래도 이 컨셉을 다시 살리고 싶긴한데 어디 올리려고 하면 포더킹 같은 저 동전 시스템은 바꿔야겠지 싶다

아닌가 가져가고 그냥 포더킹에서 이런것들을 따왔고, 연습용으로 만든 게임이라고 그냥 적어야겠다

그리고 실제 만든 선택지 창

변명거리를 하자면 턴제 게임을 처음만들어봐서 어떤식으로 짜야할지 생각보다 감이 잘 안왔다

아닌가 좀 볼륨이 컸나..?

난 분명히 턴제 게임을 선호하지 않는 편이라 생각했는데 제작할 때 재미있었고, 도움도 많이 되었다

사실 핵심 시스템 [턴 미루기]를 너무 만들고 싶었다

나는 포더킹에서 턴 미루기라는 시스템이 너무 매력적이였는데 (물론 턴제 게임에서 굉장히 유리하고 강력한 스킬이라는 것을 이제는 안다) 그 시스템을 만들고 싶었다!

여기서 많은 에러가 발생했고..시간은 지체되고..마음은 급하고 아주 난리도 난리가 아니였다

육각 타일때문에 이모저모 고민을 많이 했던 시기였다

이런것도 화이트보드에 적어가면서 고민해보고

옆자리 정성님과도 대화를 많이했고, 정성님도 육각형 타일을 채택하고 둘다 고통받았더랬지🤣

사실 이때는 1주차때 같이 팀했던게 커서 정성님이랑 많은 대화를 했던 것 같다

특히나 옆조에서 다키스트 던전을 채택했어서 더 그랬을지도!

다키스트 던전은 게임랩 들어가기 전에 조금 해보고 들어갔어서 뭔가 친밀감이 생겼었다

그리고 같은 조였던 으명님에게 신선한 충격을 받았더랬다

으명님은 포더킹 확률 시스템을 따와서 부루마블+땅따먹기를 결합한 게임을 만드셨는데 그 시도 자체가 나에게 있어서는 충격적이였다

자연스럽게 피쳐를 녹여내면서 색다른 게임이라는 생각이 들었고 재미와 창의는 이런건가? 라는 생각이 들게 해주셨다

그 주에도 그런 말을 많이 하긴했지만 나중에 이 글을 보시면 엄청 부끄으쓱해하실 것 같다ㅎㅎ

이 당시에 빌드가 엉망이였는데

망가진 내 빌드에 대해서 친절하게 물어봐주시고

내가 수정할 때까지 기다려주신 간석님에게 굉장한 감사 인사를 전하고 싶다

그 당시에는 여러가지로 속상한 마음도 크고 굉장히 잘 마무리하고 싶은 마음이 커서

그저 내 게임을 기다려주고 플레이해줬다는 사실이 너무 감사했다

작은 친절에도 굉장한.. 감동이였달까

작은 비밀이라면 그 다음 주차때 내가 가진 미니초코과자를 좋아하셔서 많이 가져다드렸다

하지만 아마 그저 피어리뷰를 해야할 게임이 작동이 안되서 그랬던것 아닐까😅

그래서 피어리뷰를 해야할 대상이 아니였음에도 가서 피어리뷰를 남겼었다

실제로 굉장히 잘만들기도 하셨고 카메라 흔들림을 잘쓰신다는 생각을 했었다

P.S 저녁에 돌아오면서 찍은 기숙사 사진

경조사 때문에 갔던 경주 사진

마음은 초조했지만ㅋㅋ 너무 이뻤던 한옥

적다보니 2주만에 나는 참 많은 것들을 깨닫게 된것 같다

항상 도전과 남들에게서의 배움을 게을리하지 말아야겠다

사실 크래프톤 정글 게임랩 3기가 이렇게까지 빨리 모집을 할줄 몰랐다..

원래 수료하고 나면 천천히 작성하려고 했지만 들어오는 분들이 궁금해하실만한 것들을 간략하게 적어보려고 한다.

이 게임은 내가 크래프톤 정글 게임랩 2기에서 제작한 게임이다!

이 프로젝트에서 제작 관리자로써 여러가지 역할들을 했다...고 자부한다

https://store.steampowered.com/app/3349860/Dr_COG/

2024년 12월 17일에 출시를 하는데 현재 출시 버전은 작업이 다 끝난 상태이다.

들어가셔서 위시리스트 한번씩 눌러주시면 감사하겠습니다..ㅎㅎ!

각설하고,

내가 이 포스팅을 쓰는 이유는 굉장히 크래프톤 정글 게임랩 생활에 만족했기 때문이다.

사실 여기에 들어오기까지 굉장히 고민을 많이 했던 사람으로써 여러가지를 말해줄 수 있을 것 같다.

주차에 대해서 포스팅을 쓰다가 말았지만 이건 수료하고 나서 열심히 더 쓸 것 같고..

3기 합격자 분들은 그때 가서 보면 훨씬훨씬 도움이 될 것이다.

사실 앞선 포스팅에서 내가 어떻게 준비했는지 인터뷰를 어떻게 했는지를 다 보고 왔으리라 생각하고 다른 내용들을 적어보려고 한다.

1. 나는 왜 지원했는가?

솔직하게 얘기하자면 취업준비를 하다가 지원을 했다.

제작년에 게임업계로 다시 뛰어들고자 회사를 그만뒀고, 취업준비를 하면서 잘되지 않았다.

그 당시 1기에 지원을 할까말까 굉장히 고민했었고, 사실 1분 자기소개 동영상에서 벽을 느껴 하지 않았다.

이거에 고민하시는 분들은 그래도 한번 도전하라고 말해주고 싶고, 충분히 가치있는 일이라 말해주고 싶다.

결론적으로 나는 스팀게임 런칭 프로세스에 대해서 알고 싶어서 지원했다.

스팀게임 런칭 프로세스에 대해서 자세하게 알 수 있는 곳도 거의 없고, 막막했기 때문이다.

물론 알더라도 팀을 꾸린다는 건.. 다른 일이다. 굉장히 어려운일이라 1차적으로 면접을 통해 뽑히면 좋은 사람들이 있을 거라는 보장이 있었다.

물론 1기의 'Frostrain'의 영향도 컷다. 스트리머의 영상을 보고 나도 잊고 있었던 2기의 존재를 다시 생각하게 되었다.

2. 왜 만족하는가?

사람.사람.사람 또 사람이다

여기에서 나는 그저 롤만 열심히 했던 사람이었다. 물론 유투브 에디션으로 많은 게임들을 보았고, 알고 있었지만 확실히 그 게임을 즐겨서 해본 사람과 동영상으로 본 건 확실한 차이가 있다. 실제로 코치님들도 그 게임을 직접 해보라고 많이들 말씀하셨고, 여기서 산 게임이 30개가 넘는다.. 쪼그라든 내 통장

게임업계에서 제일 중요한건 동료다. 기획, 아트, 프로그래머, 마케팅 등등 여러가지 직군의 사람들이 한개의 제품을 만드는 곳이고, 그들의 성향은 매우 다르다.(내가 지금까지 겪어본 느낌으로는)

게임을 좋아하는 사람들끼리 게임에 대해 얘기하는 것은 매우 즐거운 일이고, 서로 빨리 친해질 수 있다고 생각한다.

물론 재미에 대해서 이야기하는 것은 다르다.

여러가지 얘기하고 싶은 것들이 많은데, 궁금한 점이 있다면 댓글을 통해 얘기하면 친절하게 답변 드릴 수 있을 것 같다!

3. 여기서 무엇을 배웠는가?

일단 말할 수 있는건 다양한 재미인 것 같다.

사람들은 게임에서 무슨 재미를 느끼는지, 어떻게 하면 좀 더 재밌게 만들 수 있을지를 많이 배운 것 같다.

서로서로 재미를 느끼는 부분들이 많이 달라서, 서로를 이해하기도 하고, 신기해하기도 하며 우당탕탕 배우지 않았을까

[재미에 대한 고찰] 이건 인디게임개발자라면 꼭 숙지해야하는 것이 아닐까 싶다.

4. 난 기획 혹은 아트 혹은 프로그래머인데 잘 할 수 있는가? 나에게 도움이 되는가?

여기서 기획을 하고 싶은데 아트로 프로젝트를 참여한 친구들도 있다.

심지어 아트에 두각을 나타낸 친구들도 많고, 프로그래밍을 할 줄 알지만 팀 내 기여를 하기 위해서 기획자 혹은 아트로 참여를 하는 친구들도 있었다.

모두가 우려했지만 그 친구들은 열심히 했고, 잘했고, 결국 출시까지 왔다.

두려워할 것도 없고, 그저 하면 된다.

그리고 기획,아트,프로그래밍 서로 협업하는 업무가 많기 때문에 다른 분야를 안다는 것은 굉장히 장점이 될 수 있다고 나는 생각한다. 특히나 1인 개발을 목표로 하는 친구들이라면 더더욱

개인적으로 나는 아트를 하는 친구들이 에픽 프로젝트(스팀런칭)에서 가장 많이 배울 것이라 생각한다.

이만큼 많은 기획자와 프로그래머들과 협업을 빡세게 해볼 기회가 흔치 않지 않을까?!

5. 취업에 도움이 되는가?

여기서 배울 수 있는 것은 3가지이다.

1. 팀에서 내가 무슨 기여를 할 수 있는가?

2. 나와 맞지 않는 사람과 어떻게 조율하며 프로젝트를 진행할 수 있는가?

3. 더 나은 게임을 만들기 위해 무슨 고민들을 더 해야하는가?

개발 능력은 사실 오롯이 자기자신이 헤쳐나가야 부분이라고 나는 생각한다.

하지만 협업 경험과 극복 경험은 다른 사람과 해보지 않으면 얻을 수 없는 경험이지만 회사에서 굉장히 중요하게 생각하는 부분이니까 나는 100% 도움이 된다고 생각한다.

하지만 위의 3가지는 팀프로젝트를 해보지 않으면, 얻을 수 없는 경험이다.

특히나 출시 해본! 경험이니까 더욱더 소중

6. 식사?는 어떻게?

일단 2기는 알아서 사먹었다. 그리고 3기부터는 더 좋은 건물에서 생활한다고 하니.. (그저 부럽다)

대신 2기는 대학교 기숙사여서 기숙사 식당이 있어서 비교적 싸게 먹은 것 같은데 새로운 건물은 모르겠다.

한끼당 5500원정도에 괜찮은 급식 느낌의 식사였다. 그리고 배달과 편의점을 많이 갔더랬지

안좋은점도 있었다.

여기서만큼 인디게임에 열정 있는 친구들을 다시 만날 수 있을까?

어려울 것이라 생각이 든다.

너무 정들어버린 게임랩 2기 친구들.. 🥲

또 궁금한 것들이 있다면 업데이트해서 글을 수정해보겠습니다!

마지막으로, 우리 2기 친구들이 만든 게임 링크들도 첨부하겠습니다!

12월 17일에 출시하니 많은 관심 부탁드립니다~~! 🥰

2주차에 드디어 팀원들이 변경되었다.

사실 1주차때 게임잼하고 랜덤 런치조하고 이러느라 좀 정신이 없기도 했고..

적응은 안됐지만 적응하려고 노력중이였다.

W02에서는 "피쳐 리스트"라는걸 작성해보라고 하셨다.

"피쳐 리스트"가 대체 뭐지...하면서 다들 시작했던것 같다.

사실 아직까지도 감이 오진 않지만 "게임을 구성하고 있는 것들"이라고 생각하면 좀 마음이 편해질지도

팀에서 분석할 게임을 한개씩 고르는 시간이였다.

사실 난 거의 대부분 생존 게임을 했던 터라 프로스트펑크만 얘기하긴 했는데 그마저도 20시간 정도밖에 되지 않아서 제일 많은 플레이타임을 가진 게임을 선정하고자 했다.

그 중에서 박맨이 했던 200시간 했던 발더스게이트를 할까 했는데 피쳐리스트가 너무 많을 것 같아서 50시간의 포더킹을 하자고 했다.

압긍을 받은 게임으로 고르라고 하셨었는데, 우리는 대체로 긍정적을 선택해서 나중에 코치님 앞에서 땀을 흘렸지..ㅎㅎ

하지만 결론적으로 말하자면 나에게 있어서 턴제 게임과 TRPG 장르에 대해서 많은 것을 배우게 해 준 게임이였고, 실제로도 재밌었다.

때마침 포더킹이 세일을 해서 나머지 팀원들이 모두 사서 3인으로 같이 플레이했다.

게임 분석이라는 명목 아래 엄청 재밌게 플레이했던 것 같다!

피쳐리스트 분석했던 화이트 보드 판이다.

게임에 대해서 분석하는 것 자체가 너무 재미있었다.

노션페이지도 엄청 빡빡하게 적었던 것 같고.. 박맨의 엄청난 노력이 들어간 노션 페이지 붙여넣고 싶군

이 재미 포인트들에 대해서는 W02+ 포스팅에서 더 적게 될 것 같다.

초심자 기준에서 체감되었던 재미포인트들을 선정하였고, 해당 포인트를 기준으로 실제로 구현해보고자 하였기 때문이다.

이외 잡담들

이 당시에 박맨이 저녁밥먹으러 갔을 때, 말을 놓는게 어떻냐고 해서 좋다고 했다.

박맨이 굴린 스노우볼로 나중에 다른 사람들에게 말 놓자고 먼저 편하게 얘기할 수 있었던 것 같다.

처음으로 제일 먼저 출근했던 날 기념으로 사진을 찍었었더랬지..

근데 뭐 이런게 큰 의미가 있나 싶다. 그때는 부지런하게 다니고 싶었는데 컨디션 관리가 더 중요한 것 같은 시점이 오더라

W02는 사실 이틀정도밖에 되지 않아서 그렇게까지 분량이 없다.

크게 깨달은 점은 난 정말 게임을 얼마 안했구나! 였다ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

여기친구들은 찐이다..

게임잼에서 이틀동안 밤새고 그 다음 발제로 받았던 과제였는데 게임잼 결과물을 활용해서 더 재미있는 게임을 만든다 였다.
게임잼 팀원들과 자리는 유지하고 서로 다른 방향으로 재미있게 만들어보자! 였다
그룹 스터디 기반으로 할것 이라고 했지만 아이디에이션, 구현 과정을 함께 하진 않았고.. 더 친해졌던 것 같다ㅋㅋㅋㅋ
코치님들이 의도하셨던 것 중에 이것도 있지 않을까?ㅎ
3분 중에서는 한분과 대학교 채플 얘기 때문에 많이 친해졌다..^===^..
 
아, 그리고 이때부터 랜덤 런치조를 시작하였는데, 나는 룸메, 게임잼 팀원1 + 처음뵙는 분 이렇게 시작했어서 첫주차는 정말 편했다. 다른 사람들은 처음엔 굉장히 어색했지 않았을까
 
 

W01+ 과제

W01+ 과제를 하기 전에 W01 피드백에 대한 정리하는 시간을 혼자 가졌다.
뭐가 문제였는지 어떤 것이 불편했는지 알게 되는 것이 게임을 만드는 것에 굉장히 중요하다고 나는 생각한다.

 
이것말고도 로프 스윙 액션에 대해서 아쉽다는 평들이 많았다.
그래서 나는 게임잼에서 활용하지 못했던 로프 액션에 다시 도전하려고 노력했다.
결국에는 원하는 방향까지는 못갔지만 나에게 있어서는 큰 의미가 있었다.
되지 않는것!에 대한 이해랄까
좀더 시간이 많이 걸릴 것 같아서 탐구하려면 여기서 말고 나가서 해야할 것 같긴하다.
원래 하고 싶었던 것은 실제 로프 물리처럼 지형 지물에 걸리면 걸린 곳을 기점으로 다시 힘 계산
하지만 유니티가 제공하는 컴포넌트들로만은 해결하지 못할 것 같았고, 여러가지 버그들을 겪게 되었다.
게임은 완성해야하기에 어느정도 포기하고 게임을 좀 더 완성도 있게 만들려고 중간에 포기를 하게되었다.
이 점도 나에게 있어서는 달라진 점이라고 볼 수 있는데 개발 일정을 짜는데 있어서 좀 더 신경쓰게 된 것 같다.
 

 
과노님이 이곳 저곳 돌아다니다가 내 스윙에 대해서 많이 궁금해하시길래 완성되면 한번 봐주세요! 이랬는데 그 때 당시 표정에 부담이 보이셨다.
끝에 가서 게임 만드느라 대화를 많이 못했다. 생각해보니 그쪽도 바쁠텐데 말해놓고 미안했었다.
그리고 피어리뷰를 받았는데 과노님이 내꺼 안해도 되는데 해주셨더라
고마워서 나도 해주었다

훈훈한 랩생활 뿌-듯😁

하지만 지금 와서 피어리뷰 보면 다들 어색하고 그래서 뾰족하게 찌르진 않았던 것 같다
 
 

W01은 험난 그자체였다.

지방에서 올라갔기에 아침 11시까지 입소인데 수서역에서 경기대까지 1시간이 걸려서 6시에 기차를 탈 수밖에 없었고..

24인치 캐리어를 들고 왔다 갔다 하는거 정말 힘들다😂

라운지에서 체크인(?)을 하고 반팔티랑 명찰을 받고 카드키 받고 올라가서 룸메랑 인사를 나누고 같이 밥을 먹기로 했다.

1층에 있는 기숙사 식당에서 밥을 먹었다.

이제는 누가 누군지 알지만 그 당시에는 정신이 하나도 없었다ㅋㅋㅋ

룸메랑 같이 학군단으로 올라왔고 사실 너무 힘들었다.

언덕 실화입니까.. 땀뻘뻘 흘리며 올라왔다

자기소개 시간을 거쳤고 솔직히 말하자면 하나도 기억 안난다..(아마 다들 그렇지 않을까? 그래야만한다ㅋㅋㅋ)

사실 정말로 바로 일정 시작할줄 몰랐는데 일정 시작해버렸다..오자마자 게임잼을 시작했다.

제출한 게임은사실 정말로 바로 일정 시작할줄 몰랐는데 일정 시작해버렸다..오자마자 게임잼을 시작했다.

제출한 게임을 이용해서 4명이서 더 재미있는 게임을 만드는 것이였다.

선정한 주제는

1. 로프 액션(스윙, 달라붙기)
2. 퍼즐

이였다.

내가 로프 스윙 액션을 만들기로 했는데 사실 일정 관리를 너무 못했고, 안되면 쳐냈어야했는데 그러지 못했다.
결국 발표때는 스윙 액션을 다 빼고 제출하게 되었다.
결국 해당 내용때문에 다들 아쉽다는 평이 많았었고, 지금도 아쉽다.
팀원들이 레벨 디자인을 엄청 잘 만들어줬고, 지금도 대단하다고 생각한다.
생각보다 내 퍼포먼스가 너무 안좋다는 생각을 많이 하게 된 계기였다.
연구쪽으로 오래 붙잡고 있는 작업들을 많이 하다보니 프로토타이핑에는 강하지 못한 느낌이였다.

벌써 게임랩에 입소한지 5주가 지났지만 늦게서야 쓰는 합격 후기이다.

사실 5주동안 팀프로젝트에 대한 고민을 많이 했고, 지금도 하고 있는 중이다.

내가 어떤 사람인지 어떤 강점과 약점을 가지고 있는지 어떻게 이걸 극복할지 등등 이런 생각들에 머리가 아프긴하다ㅋㅋ

입소하기 전에 많은 고민을 했지만 입소 후 5주가 지난 지금에는 엄청 잘한 선택이라 생각한다.

열정있는 친구들, 예리한 감각을 가진 친구들, 노력하는 친구들 각기 자리에서 다들 게임에 대한 열정을 가지고 있다랄까

나보다 어린 친구들이지만 각기 다른 점으로 본받을 점이 많다고 생각이 든다. 내일 보면 진짜 뜬금없이 멋지다고 한번씩 말해줘야겠다. 블로그 들킬까봐 겁나네

나도 더 열심히 해야지!!💪 

아직까지 19주 정도 더 남았지만 더 많이 배울 수 있길 바라며 과정에 대해서 간략하게 적어보려고 한다.

먼저 자소서 내용의 일부이다.

협업 경험에 대한 1분 자소서 영상을 찍었고, 노션에서 미리 대본을 적어놓고 거의 그대로 읽었다고 보면 된다..

그래도 면접관분들이 다 보시니까 정성을 다해 찍으면 된다..ㅎㅎ

서류를 제출하고 나서 바로 사전 학습자료를 배부해주셨다

개별학습은 유니티 공식페이지를 통해 이루어졌고, 나는 유니티를 쓸 수 있지만 그 과정을 왠만해서는 다 이수하려고 노력하였다.

실제로 과정에서 배운점도 많았고 유니티를 잘아는 사람들도 해보면 좋을 것 같다.

입학시험에서는 게임을 12시간동안 만들어서 제출하는 것이였고, 기획까지 다 해서 내는 것이였다

나는 간단하게 6스테이지로 구성된 동굴 탈출 게임을 만들었다.

로프를 이용해서 Spring Joint라는 컴포넌트를 사용해서 완벽하진 않지만 비슷하게 만들었고

(사실 이것때문에 1주차때 코딩에 난항을 겪었다. 팀원들에게 미안한 한말씀을..)

나는 6/4일 11시 30분에 면접을 봤고, 모든 부분을 다 말하긴 어렵겠지만 일부분 적어보려고 한다

사실 SpringJoint 관련해서 준비를 안하고 있었는데 학교 선배가 준비해야되지 않겠냐고 말해서 준비했는데 나와버렸다.

감사합니다 선배..ㅋㅋㅋㅋ

천천히 업데이트해서 주차별로 복기와 후기를 남기도록 해야겠다!

노션에 정리도 제대로 안하고 있긴한데.. 화이팅해보자~!!

최근 3기 모집 공고가 떠서 다들 궁금해서 많이 들어오시는 것 같은데 그런 분들을 위해 아래 글을 작성하였으니 한번 참고해보십시오!

디렉토리에 가서 .uproject 우클릭 → Switch Unreal Engine version → 원하는 버전 선택 → ok 버튼 클릭

하고 조금 기다리면 원하는 .uproject를 더블클릭해서 들어간다

Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.

안드로이드 비공개 테스트를 진행하던 도중 이러한 안정성 관련하여 에러가 발견되었다고 알려주었다

해당 내용을 찾아보니 Target API Level이 31 이상이면 이러한 비정상 종료를 겪게 된다고 한다

💡이 키워드로 검색(Ctrl+F)💡
이 출시 버전 및 모든 이전 버전에서는 다음 스택 트레이스를 통해 Android S에서 앱 비정상 종료를 일으키는 버그를 해결하려면 androidx.work:work-runtime:2.7.0의 명시적인 종속 항목이 필요합니다.

https://developers.google.com/admob/android/rel-notes?hl=ko

해결방법은 Build Settings - Player Settings - Publishing Settings - Build - Custom Main Gradle Template 활성화

그 후, Assets\Plugins\Android\mainTemplate.gradle 폴더로 가서 Main Template 을 열어줍니다

그 안에 아래에 해당되는 내용들을 삽입하여주면 됩니다

중복된 것은 제거하고 새롭게 변경해줍니다

dependencies {
  implementation 'com.google.android.gms:play-services-ads:20.4.0'

  // For apps targeting Android 12, add WorkManager dependency.
  constraints {
    implementation('androidx.work:work-runtime:2.7.0') {
      because '''androidx.work:work-runtime:2.1.0 pulled from
      play-services-ads has a bug using PendingIntent without
      FLAG_IMMUTABLE or FLAG_MUTABLE and will fail in Apps
      targeting S+.'''
    }
  }
}

한참을 헤매다가 애드몹 적용 후 에디터 상에서는 잘 작동하는데 안드로이드 폰에서 실행하니까 빌드 튕김 현상이 일어나서 결국 Logcat을 다운받아서 Log를 확인해보고 수정하는 과정을 거쳤다

예전에 Logcat 다운받아서 연결하고 하는게 굉장히 복잡했었는데 이제는 엄청 쉬워졌다

Window - Package Manager - Unity Registry - logcat 검색 해서 다운받으면 된다

실행방법은

Window - Analysis - Android Logcat을 클릭하여서 실행시키면 된다

이곳에서 해답을 찾았는데,

Assets - Google Mobile Ads 에서 넣는 것은 AppID이고 (숫자와 숫자 사이에 ~ 존재)

스크립트 내에서 쓰는 것은 광고 ID이다 (숫자와 숫자 사이에 / 존재)

먼저 Window - TextMeshPro - Font Asset Creator 를 클릭한다.

Custom Size 30

Padding 4

Atlas Resolution 4096 4096

Character Set 'Custom Range'

Render Mode SDFAA

💡Unicode 범위💡
영어 범위 32-126
한글 범위 44032-55203, 4352-4607, 12593-12643
특수문자 8200-9900

1. ShadowMap

빛의 관점에서 장면을 렌더링하고, 빛의 관점에서 보이는 모든 것은 환하게 표시하고 볼수 없는 것들은 그림자로 표시해야 한다는 것이다.

노란색 부분들이 빛의 시야에서 보이는 부분들이고 검정색 부분들이 빛의 시야에서 보이지 않는 부분이다.

수천개의 빛 방향 Ray를 통해 계산하는 것은 실시간 렌더링에서 굉장히 비효율 적이기 때문에 새로운 방법을 사용해야 한다.

이를 대안으로 생각한 것이 깊이 버퍼를 사용하는 것이다.

Shadow Map을 사용하는 방법은 두개의 패스로 구성하여 그리는 것이다.

1. 빛의 관점에서 깊이 버퍼를 계산하여 가장 가까운 깊이 값의 샘플을 추출 한다. (깊이 맵 or 쉐도우 맵)
2. 추가 테스트를 통해 현재 fragment가 그림자로 표시될지 아닐지 판단하여 그린다.

먼저 빛의 관점에서 깊이 버퍼를 계산하여 가장 가까운 깊이 값의 샘플을 추출한다.

//shadowMap vert
#version 430

layout(location=0) in vec3 coord3d;

out vec4 position;

uniform mat4 lightSpaceMatrix;
uniform mat4 Model;


void main(void)
{
   gl_Position = lightSpaceMatrix* Model * vec4( coord3d,1.0);
   position = gl_Position;
}

빛 공간의 위치 값을 position을 통해 fragment 쉐이더로 넘겨준다.

그리고 처음에는 fragment 쉐이더에 아무런 처리를 하지 않는다.

빈 fragment 쉐이더는 아무런 처리 없이 끝나면 깊이 버퍼가 업데이트 된다.

bias 값을 가지지 않고 그리게 되는 경우 아크네 현상이 일어난다.

하지만 bias를 0.005로 설정을 하면 자연스럽게 원에 그림자가 입혀지는 느낌은 아니다.

법선과 빛의 방향에 기초하여 bias 범위를 수정하도록 변경하였다.

float bias = max(0.05 * (1.0 - dot(normal, lightDir)), 0.005);

결과적으로 훨씬 자연스럽게 보이지만 너무 원의 그림자가 삭제되어버렸다.

아마 bias 범위가 안맞은 듯하다.

2. PCF 적용

PCF는 percentage-closer filtering 의 약자인데 안티 에일리어싱 방법 중 하나이다.

깊이 맵의 주변 텍셀을 샘플링하고 각각 개별 샘플에 대해 그림자인지 아닌지 판단하고 결과를 평균화한다.

float shadow = 0.0;
vec2 texelSize = 1.0 / textureSize(shadowMap, 0);
for(int x = -1; x <= 1; ++x)
{
    for(int y = -1; y <= 1; ++y)
    {
        float pcfDepth = texture(shadowMap, projCoords.xy + vec2(x, y) * texelSize).r; 
        shadow += currentDepth - bias > pcfDepth ? 1.0 : 0.0;        
    }    
}
shadow /= 9.0;

이 코드를 기반으로

float ShadowCalculationPCF(vec4 fragPosLightSpace,vec3 lightDir){
	vec2 size = textureSize(shadowMap,0);
	vec2 texelSize =  vec2(1.0,1.0)/size;

	vec3 projCoords = fragPosLightSpace.xyz/fragPosLightSpace.w;
	projCoords = projCoords*0.5+0.5;
	vec2 uv = projCoords.xy;
	float currentDepth = projCoords.z;
	float result = 0.0;

	vec2 textureSize = textureSize(shadowMap,0);
	float bias = 2.0/textureSize.x;
	
	//빛에 대한 표면 각을 기준으로 기울기의 양을 변경
	//bias = max(bias * (1.0 - dot(Normal, lightDir)), 0.005); 

	for(int x=-2;x<=2;x++)
	{
		for(int y=-2;y<=2;y++)
		{
			vec2 off = vec2(x,y)/size;
			result += InterpolatedCompare(shadowMap,uv+off,currentDepth,bias);
		}
	}

	return result/25.0;
}

PCF를 구현하였다.

예제 코드에서는 4번의 샘플링을 거쳤지만 NewRo는 총 8번의 샘플링을 하였고 대신 bias값을 조금 키워주었다.

3. VSM

VSM은 Variance Shadow Mapping의 줄임말으로 Shadow edge를 부드럽게 처리할 수 있는 기법 중 하나이다.

PCF의 문제점은 깊이 버퍼에서 생성된 값을 하드웨어로 필터링 할 수 없다는 것이다.

즉 하드웨어에서 자동으로 셋팅해주던 깊이 버퍼 값을 필터링하여 개선하고 싶다는 것이다.

chebyshev는 PCF를 진행할 영역의 Shadowing 비율을 얻으려고 했다.

그래서 만든 부등식은 분산(Variance)를 사용한다.

1. dpeth와 depth*depth 값을 색상 fbo에 저장하고(32비트 floating 정밀도 사용)
2. chebyshev's 공식을 이용하여 어떤 fragmet가 그림자에 있는지 없는지 알아내고, fragment가 그림자에 가려질 확률을 계산한다.(자유로운 경계를 사용하기 때문에 매우 편리함)

자가 음영이 계속 발생하기 때문에 

glCullFace(GL_FRONT);

를 추가해주어야 한다.

glEnable(GL_DEPTH_TEST);

깊이 버퍼 활성화 코드도 넣어줘야한다.

//shadowMap frag
#version 430

out vec4 FragColors;
in vec4 position;

void main()
{

	float depth = position.z/position.w;
	depth = depth*0.5+0.5;

	float moment1 = depth;
	float moment2 = depth*depth;

	//return the partial derivative of an argument with respect to x or y
	//x 또는 y에 대한 인수의 부분 미분을 반환합니다.
	//도함수는 블록의 픽셀 값 사이의 차이를 취하여 계산됩니다.
	float dx = dFdx(depth);  
	float dy = dFdy(depth);
	moment2 += 0.25*(dx*dx+dy*dy);

   FragColors = vec4(moment1,moment2,0.0,0.0);
}

Shadow의 경계가 되는 부분을 판단하기 위해 분산값을 사용하여

특정 Depth 값의 차이가 클수록 분산 값이 더 커지는 점을 이용하여 Shadowing의 비율을 도출해낸다.

float ShadowCalculationVSM(vec4 fragPosLightSpace,vec3 projCoords){

	float p_max =0.0;
	projCoords = projCoords*0.5+0.5;
	float currentDepth = projCoords.z;

	vec2 moments = texture(shadowMap,projCoords.xy).rg;

	if(projCoords.z<=moments.x)
			return 1.0;
	float variance = max(moments.y-(moments.x*moments.x),0.0002);

	float d =  projCoords.z - moments.x;
	p_max=variance/(variance+d*d);

   return p_max;
}

많은 요인에 따라 좋은 결과가 나오지 않을 경우 max 값을 변경해주면 좋다고 한다.

조금더 자연스러워진다.

*해결해야 할 문제들*

1.  ortho 를 perspective로 변경 → Directional Light가 아닌 Spot Light 구현

참고한 사이트

1. 문제

bandage : {기술의 시전 시간, 1초당 회복량,추가 회복량}
health : 최대 체력
attacks : {몬스터의 공격 시간, 피해량}

Return : 모든 공격이 끝난 직후 남은 체력, 만약 체력이 0 이하면 -1 출력

2. 코드

#include <string>
#include <vector>
#include <iostream>

using namespace std;

/*

Return
- 모든 공격이 끝난 직후 남은 체력
- 만약 체력이 0 이하가 되어 죽으면 -1

Rule
- 추가 회복량 : bandage
- 최대 체력 : health
- 몬스터의 공격 시간과 피해량 : attacks
- t 초 동안 1초마다 x 만큼의 체력 회복
- t 초 연속으로 성공하면 y만큼 체력을 추가로 회복

*/

void heal(int& healStat,int healValue,int healthMax){
    healStat+=healValue;
    if(healStat>healthMax) healStat = healthMax;    
}

int solution(vector<int> bandage, int health, vector<vector<int>> attacks) {
    int answer = health;
    
    int endTime = attacks[attacks.size()-1][0];
    int combo=0,attackIdx=0;
    for(int i=0;i<=endTime;i++){
        if(attacks[attackIdx][0]==i){
            answer-=attacks[attackIdx][1];
            combo=0;
            attackIdx++;
        }
        else{
            combo++;
            heal(answer,bandage[1],health);
            if(combo==bandage[0]){
                //active combo
                heal(answer,bandage[2],health);
                combo=0;
            }
        }
        
        if(answer<=0){
            answer=-1;
            break;
        }
    }
    
    return answer;
}

3. 해설

	 int endTime = attacks[attacks.size()-1][0];
    int combo=0,attackIdx=0;
    for(int i=0;i<=endTime;i++){
        if(attacks[attackIdx][0]==i){
            //cout<<"attackIdx: "<<attackIdx<<endl;
            answer-=attacks[attackIdx][1];
            combo=0;
            attackIdx++;
        }
        else{
            combo++;
            heal(answer,bandage[1],health);
            if(combo==bandage[0]){
                //active combo
                heal(answer,bandage[2],health);
                combo=0;
            }
        }
        
        if(answer<=0){
            answer=-1;
            break;
        }
        //cout<<"health: "<<health<<endl;
    }

endTime 은 attacks 배열의 맨 마지막 인자의 공격 시간을 받아왔습니다.
attacks는 시간순으로 오름차순으로 정렬이 되어 있기 때문에 재정렬할 필요가 없습니다.
받아온 마지막 공격 시간까지 체크를 하는 for문을 작동시킵니다.
combo 는 콤보를 받아올 변수이고 attackIdx는 attacks 공격할 배열의 순서를 의미합니다.
attackIdx는 공격을 받을 때, 다음 인자로 넘어가도록 설계되어 있습니다.

if(attacks[attackIdx][0]==i)

위의 if문은 attackIdx 순서에 따른 공격 순서가 i(시간)과 같은지 체크 하는 구문입니다.
만약, attacks 배열이 {{1,5},{3,10}} 로 이루어져 있다면
- 시간 1일 때 5를 공격한다.
- 시간 3일 때 10을 공격한다.
입니다.
만약 attackIdx 가 0 이면, 시간 1일 때 공격을 시전하면 됩니다.

answer-=attacks[attackIdx][1];
combo=0;
attackIdx++;

만약 i(시간)이 맞다면, 공격이 시전됩니다.
따라서 answer(현재 체력)을 attacks[attackIdx][1](피해량)만큼 감소시킵니다.
콤보는 깨지기 때문에 0으로 바꾸어줍니다.
해당 공격을 받고 나서는 다음 공격을 체크할 수 있도록 attackIdx를 증가시켜줍니다.

else{
	combo++;
	heal(answer,bandage[1],health);
	if(combo==bandage[0]){
		//active combo
		heal(answer,bandage[2],health);
		combo=0;
	}
}

만약 공격을 받지 않는다면 치유를 합니다.
콤보의 갯수를 늘리고, 치유를 합니다.

void heal(int& healStat,int healValue,int healthMax){
    healStat+=healValue;
    if(healStat>healthMax) healStat = healthMax;    
}

힐은 healthMax(최대 체력)을 넘어가면 다시 조정됩니다.

if(combo==bandage[0]){
	//active combo
	heal(answer,bandage[2],health);
	combo=0;
}

만약 콤보를 달성하면 추가 체력이 치유되도록 설정합니다.

if(answer<=0){
	answer=-1;
	break;
}

만약 체력이 0이하가 된다면 for문을 벗어나고 -1을 출력합니다.