개발일지 링크

#1 - 플레이어 기본 조작

#2 - 무기 기틀 세우기

#3 - 무기 종류 추가 및 업그레이드 구현

#4 - 기본 몬스터

#5 - 몬스터 스폰

#6 - 즉사 공격, 가까운 적 탐색, 데미지 표기

#7 - 플레이어 스텟

#8 - 성능 최적화 (움짤 주의)

#9 - Experience Point

#10 - 넉백 / 미티어 스트라이크

#11 - 경험치 및 레벨업 UI

서론

지난 개발일지는 UI 관련이라 보여줄 것도 없었는데 실베...

관심을 받는 것은 좋지만 일반인에겐 재미없는 내용 뿐이라고 생각이 든다.

최근에는 개발과정 중 고민거리 위주로 작성하고있는데,

이게 나름 읽어줄만한 내용이니 보내는 걸까 싶기도 하고...

개발일지에 대한 반응이 있으면 보람이 있어서

굳이 칭찬이 아니더라도 개선을 원하거나 개발일지의 방향성이나 궁금한 부분이 있다면 편하게 댓글 남겨도 되는 것 !

요즘 개발이 재밌게 잘 되고 있는데 개발을 방해하는 요소가 생겨버렸다.

전에 개발했던 프로그램을 남이 쓰고 싶다고 해서 여기저기 퍼지는 것은 곤란하기에 락을 거는 작업을 하고있다.

하지만 프로그램 자체를 디컴파일해서 락만 제거 후 컴파일을 막을 정도의 실력은 없는지라

일반인 수준에서만 복제를 못할 수준으로 구현하려고 생각중이다.

서버같은 것은 없으므로 생각해본 방법은

1. 설치 프로그램을 사용자가 실행하면 바이오스의 시리얼 넘버같은 고유값을 해싱등을 이용해 알아볼수 없게 텍스트로 출력

2. 이를 복사해서 나에게 전달

3. 이 값을 전자 서명 후 사용자에게 전달

4. 사용자가 값을 설치 프로그램에 입력하면 설치 프로그램에서 공유키로 복호화 후 1번의 값과 동일하다면,

해당 값으로 라이센스 파일 생성 및 프로그램 설치

5. 사용자가 프로그램 실행 시 프로그램에서 라이센스와 바이오스 시리얼를 1번방법과 같이 해싱한 값이 같다면 실행

쓸데없이 복잡하긴 하지만 겸사겸사 공부하는 버릇이 발동해버린듯 싶다.

컴퓨터 보안 지식이 빈약한지라 부족한 부분이 있다면 조언 부탁드려요 !

지난 이야기

경험치 UI 및 레벨업을 구현했었다.

당시 문제점으로는 한번에 여러번의 레벨업 시 동시에 실행되는 것이 있었다.

그 문제를 해결한 방법은 경험치 획득 시 레벨업을 한번에 시키는 것이 아닌

무기 업그레이드 애니메이션이 종료될 시에

레벨 업이 가능한지를 다시 체크하고 레벨업을 하는 것이다.

결과는 이런식으로 완료 후 다시한번 출력된다.

뱀서를 진행하며 불편하게 느꼈던 점 중 하나가 무기 선택 후 바로 진행이 되는데

한번에 2레벨 이상 증가가 되면 무기 선택 후 0.1초정도 진행이 되다 다시 레벨업이 되는 것.

이 문제를 개선했으니 만족 !

Skill point

이번 시스템 구현에 시간을 꽤나 사용한 이유 중 하나가

exp, hp, sp 모두 작동 방식이 조금씩 다르다는 점이었다.

이후에 뉴비뉴비분들이 칸 단위 게이지, 바 형식의 게이지를 구현할 때

도움이 되었으면 싶어서 자세히 짚고 넘어가려고 한다.

sp부터 알아보도록 하자.

처음에는 무조건 데쉬로 생각을 하고 진행했는데

한결같이 선을 정해두지 않은 탓에 욕심이 커져서

캐릭터 별로 고유 스킬을 하나씩 달아주는 것도 재밌지 않을까 생각이 들었다.

따라서 기존 데쉬 게이지를 Sp 게이지로 변경하게 되었다.

이는 쿨타임 마다 1칸씩 회복되며, 사용 시에는 1칸을 소모한다.

기본 캐릭터는 데쉬 기술이며, 텔레포트, 존야, 공격가능한 돌진기 등등을 생각해두었다.

바 형식의 hp와 모양을 통일해주기 위해 아래 짤에 보이는 기존의 고기모양이 아닌 게이지 형식으로 변경했다.

좌상단에 보이듯이 1차 디자인을 해보았는데 되었는데 몬가... 몬가다...

너무 짧아서 그런가 싶어 길게 늘려보았다.

여전히 몬가... 이상하다.

이런저런 고민결과, sp는 최대 5칸으로 할 생각이라 칸의 길이를 늘려주기로 했다.

조금은 괜찮아진 듯 싶다.

길이를 늘려서 성장 후의 모습을 그려보았다.

조금 디자인이 마음에 들지 않지만 이정도면 된 듯 싶다.

그래픽 에셋을 구매해놓고 전체 디자인을 수정하고 싶지는 않아 이대로 진행하기로 했다.

그래봤자 이후에 설명할 부분에서 이것저것 열심히 뜯어고쳤다...

작동하도록 구현할 차례 !

필요한 변수들을 선언해보았다.

적다보니 헷갈리고 어지럽고 너무 많아서 모르겠다.

기능을 먼저 구현하기로 했다.

Sp 최대치를 설정해주는 함수

플레이어 스크립트에서 Sp 최대치가 초기화되거나 변동될 경우 이벤트를 발생시키고,

그 이벤트를 이 함수가 구독하여 실행된다.

기준이 될 너비 같은 값들은 const로 선언하여 이후 리팩토링나 디버깅 시 헷갈리지 않도록 해주었다.

간단하므로 위 코드에 대한 설명은 생략해도 될 듯 싶고,

내부 게이지 설정함수를 설명하기 전에 먼저 디자인 변동이 생겨 그것부터 설명하겠다.

위 최대치 함수가 적용되었고 간단하게 회복되도록 구현해본 사진이다.

구현하고 보니 굉장히 어색하다.

sliced로 처리했는데 중간중간 명암이 있어 여러 스프라이트를 사용해 구간별로 나누어주었는데도 어색하다.

고민에 고민을 하다 명암이 문제인가 싶었다.

시험삼아 적용해보니 훨씬 깔끔해졌다.

이 그래픽 제작자가 꽉 차 있지 않을때의 게이지의 모습을 항상 중앙에 명암을 처리해두다보니

명암이 계속 움직이면서 어색해보이는듯하다.

추가적으로 게이지가 스르르 증가하는 것이 아닌 3도트씩 증가하도록 해주었다.

혹시나 싶어 아예 게이지 별(테두리)로 명암을 주고,

내가 이상한거 아닐까 원본을 다시 사용.

이것도 괜찮아보인다.

그래픽 에셋 수정을 하고싶지 않아 이대로 진행을 하기로 결정하고 회복이펙트를 만들었다.

간단하게 sp에 미리 머티리얼을 달아두고 이 머티리얼 값을 변경하는 방식.

지난 번과 마찬가지로 allin1spriteshader를 사용했고 glow를 변경시켜주는데,

아마 나중에 포스트프로세싱을 약간 사용하면 더 이뻐질거라 생각한다.

반짝임이 둔한 느낌이라 yoyo루프 대신 처음에 바로 밝아지도록 변경했고,

중앙의 명암이 어색하게 느껴져 다시 테두리의 명암을 바꾸었다.

괜찮아진듯 싶으면서도 뭔가 어색하다.

이전의 명암문제가 역시 문제인듯 하다.

게이지의 명암을 단순화시키고 아이콘에도 효과를 주었다.

이제 좀 만족스러운 느낌!이지만 여전히 뚝뚝 끊기는게 답답하게 느껴졌다.

1도트씩 채워지도록 수정.

그럭저럭 자연스러운 느낌이 되었다 !

아직도 어색해보이는 문제는 그래픽 에셋의 탓이라고 생각한다.

오른쪽 끝의 가운데 도트가 튀어나온 것 때문에 마스크를 사용하지 않았고,

좌우 양 끝의 명암이 존재하므로 slice를 사용하며 양 끝 지점에서는 sprite 자체도 변경해주는 방식으로 구현했다.

Sp 반짝임 이펙트 함수

스프라이트 교체 및 미리 달아둔 머티리얼의 값을 변경시킨다.

내부 도트 개수만큼의 게이지 너비를 설정하는 함수

먼저 받은 sp게이지의 비율(0~1)로부터 너비 도트만큼을 곱한 뒤 소수점을 버린다.

이렇게해서 비율에 따른 도트 수를 구하고,

좌,우 가장자리에선 스프라이트가 달라지다보니 도트 수에 따라 스프라이트를 변경해준다.

마지막으로 도트 수 * 1도트당 캔버스에서의 너비를 곱해 크기 결정.

스위치문이 노가다스럽지만, 이것 외에는 방법이 떠오르지 않는다.

이러라고 있는 스위치문 아닐까...?

Sp가 변경될 때마다 실행될 함수

받는 파라미터는 0~1이 아닌 0~최대sp이다.

최대 2칸이고 1.5칸이 있을 경우 1.5를 받는다는 의미.

따라서 현재 칸수와 이전 칸수를 비교해 변동량만큼 해당하는 작업을 한다.

마지막으로 Sp가 변동될 때, 최대치가 변동될 때 이벤트를 발생시키고

이 이벤트를 구독해주면 끝 !

적고보니 간단하다...

Hp

현재 hp량 파악이 중요하다보니 초기 컨셉의 sp처럼 3칸씩 줄어들면 문제이므로

1칸씩으로 변경하게 되었고, 결국 sp도 이를 따르게 되어

hp를 구현하며 sp를 수정하게 되었다.

기획의 중요성...

hp의 경우 다 채워질 때 반짝이는 sp와 다르게 줄어들 때 반짝인다.

sp 반짝임 코드와 비슷하고 반짝이는 속도나 지속시간 정도만 다르므로 생략.

hp 최대치 설정 함수

const 상수를 너무 많이 사용해서 난해해보일 수 있으나

기본 캐릭터의 체력인 100일 때 sp가 딱 2칸에 맞추고 싶었고 이 너비가 200이면 깔끔하게 떨어지므로

게이지의 크기는 체력의 2배로 비례하게 되었다.

체력이 변동될 때 좌우 양끝의 명암에 따라 스프라이트 변경처리를 위해 최대치일 때 도트 너비수를 구해둔다.

체력바 테두리의 크기를 설정해주면 끝.

도트 수를 이용하는 이유는 1도트씩 단위므로 최대치 또한 1도트단위어야만

체력이 도트크기에 비례하지 않을 때의 문제를 방지하는 것이다.

이렇게 되면 hp가 약간 차이가 있다면 시각적으로만 같아보이겠지만,

내부 처리는 다른 쪽에서 하므로 문제없다.

이게... 기능별 분리의 중요성 아닐까...?

코드 설명하기가 편해졌다 !

체력 변동 시

현재 시각적으로 보이는 체력 도트 너비와 이전의 도트 너비가 다를 경우에 사이즈와 스프라이트를 변경한다.

sp의 경우에는 게이지의 너비가 정해져있지만 hp는 체력통 자체가 변동가능하므로 상수가 아닌지라

sp보다 switch문 사용에 제약이 생겨 지저분해졌다.

차라리 for문으로 비교하는게 더 깔끔할지도 모르겠다.

데미지 입을 시

데미지를 입을 경우 이펙트를 실행시킨다.

바로 이펙트를 실행시키고 싶으나 유니테스크의 반환형은 UniTask이므로 인스펙터 상에서 즉시 할당을 못한다.

데미지를 입을경우 반짝이며 줄어든다.

하지만 역시나도 마음에 들지 않는 부분이 있다.

뱀서마냥 체력이 주르륵 줄어든다는 점이다.

뱀서를 플레이하며 불편했던 점 중 하나인데

이펙트때문에 보이지도 않는데

피가 주르르륵 달고 내가 피가 줄은지도 모른 체 죽고나서

보스랑 잠깐 비빈사이에 죽어본 경험이 은근히 있다.

이를 방지해주도록 하자.

플레이어 데미지 관련

플레이어의 체력 시스템 코드 일부이다.

데미지를 받을 경우 자신이 현재 무적인지 체크하고 아닐 시에만 적용한다.

무적 타이머는 데미지를 받고 나서 무적이 될 시간동안 대기 후 무적을 해제해주는데,

Update가 아닌 FixedUpdate를 사용하여 프레임 차이로 인해 생길 문제를 방지해주었다.

체력 재생

다음으로 1초마다 회복되는 체력 재생을 구현해보자.

프레임마다 회복시켜줄 수도 있겠으나 양이 미미한지라 굳이 매프레임 시킬 필요는 없다고 생각된다.

방금 체력 시스템에서 추가된 코드이다.

SetRegenerationRate함수를 통해 플레이어가 스텟을 초기화하며 체력 시스템에 적용시켜준다.

나머지는 Update문에서 1초마다 체력재생을 진행해준다.

이 때 CurrentHp는 maxHp값을 넘지 않도록 setter에서 설정해주었다.

최대 체력

최대 체력은 변동사항이 생길 경우 변동사항만큼 현재 체력도 변동시켜준다.

게임 플레이 중 체력이 10 증가하게 되면 변화량인 10만큼 현재 체력도 증가하고

10 감소하게되면 10만큼 현재체력도 감소하게 된다.

이 때 최대 체력, 현재 체력 변경 이벤트를 모두 발생시켜주면

두 가지 모두 갱신이 된다.

각각 해당하는 일만 처리하게 나누어 주어 깔끔하게 느껴졌다.

물리 처리

구현을 하며 한 가지 궁금증이 생겼다.

몬스터와 플레이어 모두 트리거가 아닌 콜라이더다.

즉, 물리 엔진 처리에 비용이 더 들어간다.

여기서 보통 총알이 데미지를 주면 총알의 triggerEnter에 데미지 주는 기능을 구현하듯이,

몬스터가 CollisionStay 시에 플레이어에게 데미지 주는 기능을 구현하려고 했다.

그런데 문득 든 생각이 몬스터끼리 통과하면 안되므로 서로 간에 충돌이 가능하다는 것인데,

몬스터끼리도 CollisionStay를 발생시키게 된다는 것이다.

명백히 성능적으로 좋지 않다고 판단되었다.

따라서 실험을 해보았다.

대략 800마리의 몬스터가 존재할 때 플레이어와 부대끼며 테스트해보았다.

정확한 동일 상태의 테스트도 아니며, 빌드 후 테스트가 아닌 릴리즈 모드이다.

몬스터에게 CollisionStay 함수를 넣고 플레이어에게 데미지를 주는 방식이다.

몬스터의 OnCollisionStay2D가 1025번 호출되고 위 그래프의 하이라이트 된 부분의 차지하는 비율이 크다는 것을 알 수 있다.

반대로 플레이어의 OnCollisionStay를 이용해 닿은 몬스터로부터 데미지를 받아와 자신에게 데미지를 주도록 하였다.

현재 fps가 다르긴 하지만 더 낮은 fps임에도 불구하고 소모되는 시간이 적다.

따라서 몬스터 쪽에서는 OnCollision시리즈를 사용하지 않아야겠다는 결론으로 마무리.

물론 나의 경우에는 뱀서라이크이고, 몬스터가 매우 많고 서로 비비고 있으므로 그런 문제가 생긴것이니

상황에 맞게 구현하면 된다

이벤트 등록

플레이어 이벤트들을 각각 연결해주었다.

이 때 주의할 점은

빨간 네모박스의 dynamic과 아래 static이 있는데,

static으로 선택해줄 경우 이벤트를 invoke시키면 무조건 static으로 설정해준 값이 전달된다.

필요에 따라 잘 선택하도록 하자.

인스펙터에서 편리하게 초기화 순서 신경쓸필요 없이 등록해서 사용하단 점은 마음에 들지만

문제는 인스펙터가 길어지고,

함수명, 이벤트명 변경 시 초기화 된다는 등의 문제가 발생하는 것.

정말 너무나도 긴 인스펙터가 되어간다.

완성

밸런스는 잡혀있지 않은 상태라 작동하는 것만 확인해보면

각 몬스터의 power에 따라 플레이어의 체력이 감소하며

조금씩 체력이 회복되고 일정 주기로 데미지를 받는 모습을 확인할 수 있다.

UI가 그닥 만족스럽지는 않지만 나머지 UI가 추가되어 통일성이 느껴지면

그때는 조금 괜찮아보이지 않을까 생각한다.

적고보니 역시 별것 없는 내용인데 늘어지는 듯 하다.

그래도 간간히 첨부한 코드가 도움이 되었다는 분들이 계시니 만족한다.

다음에는 진짜로 아이템 풀로부터 꺼내오는 것을 구현할 듯 싶지만,

나도 체인 라이트닝이나 포물선을 그리는 마법을 만들고 싶어져서

그것부터 할지도 모르겠다.

+++ 내용 추가

피드백 받은대로 그라데이션을 아예 줄여보았다.

훨씬 깔끔해지지 않았나 싶다.

까먹었던 캐릭터 하단의 체력바도 말씀덕에 간단하게 추가해보았다.

피드백 너무 감사한 것 !