배틀퀸(BattleQueen) – 페이지 13

버그픽스

2024년 6월 20일2024년 6월 20일배틀퀸(BattleQueen)에 게시됨댓글 남기기

버그는 끊임없이 나온다. 원래 그렇다. 우리가 괜찮은 게임이라 부르는 것들은 모두 이런 담금질을 거친다. 그리고 이 포스팅은 좀 심심하다. 기록할 게 별로 없다.

화살은 버튼을 누르고 있으면 쏘는 타이밍을 잠시 지연시킬 수 있다. 그 전까진 이것이 무기한 가능했는데, 1.5초로 제한하자. 그 이상 누르고 있으면 강제로 발사한다.

앗.. 생각보다 빨리 끝났다. 이제 오로라로 넘어가자.

달래의 이펙트

2024년 6월 19일2024년 6월 20일배틀퀸(BattleQueen)에 게시됨댓글 남기기

6.19

화살에 이펙트를 붙이지 않으면 덩어리감이 없어 눈에 잘 띄지 않으므로 뭐라고 붙여야 한다. 그래서 생각해낸 것이 삐죽삐죽한 이펙트이다.

드래곤 플라이트를 만들 당시, 캐릭터 주변에 붙는 가시이펙트는 맥스를 이용해서 만들었었다. 당시는 자체엔진을 사용했기 때문에 파티클로 저걸 구현해낼 방법이 없어서 맥스로 만든 걸 익스포트해서 썼었는데, 유니티라면 되지 않을까

오.. 잘 된다.

화살은 완료

뜻밖에 매우 어려웠던 대각선 화살. 이게 왜 어려웠냐면 스케일때문이다. 현재는 파티클을 생성시킨 후, 세로스케일을 줄여서 사용하고 있는데, 이것이 월드 기준으로 계산된다. 따라서 이것을 로컬기준으로 변경하려면 몇가지 설정이 필요하다. 일단 렌더러 설정에서 렌더정렬을 Local로 바꿔주고

스케일링 모드를 하이라키로 바꿔준다.

그리고 스케일을 줄인 후, 로테이션 또한 하이라키에서 제어해야 한다.

처음엔 파티클의 기울기를 StartRotation에서 제어하고 있었는데 이게 오답이었다. 이것 때문에 저녁작업시간을 홀라당 날려버렸다. 흑흑

6.20

이펙트를 등록하려면 많은 과정을 거쳐야 하는데, 이것이 너무 번거롭게 느껴져서 리팩토링. 이제 데이터에 이펙트 정보가 없다면 빈 정보를 생성하고, 좌우 반전 이펙트의 경우 오른쪽 정보를 먼저 찾아보도록 변경했다. 코드가 한결 깔끔해졌다. 그럼 스테이트 정보도 이렇게 하면 더 깔끔하겠네! 싶어서 봤더니, 스테이트는 빈 데이터를 사용하는 경우가 거의 없어서 의미가 없었다.(비어있는 경우는 None과 Idle밖에 없었다!)

달래의 작업이 끝났다. 버그픽스로 넘어가자.

달래의 2기 애니메이션 작업

2024년 6월 13일2024년 6월 19일배틀퀸(BattleQueen)에 게시됨댓글 남기기

6.13

일단 활을 들었으니 활은 쏘아야 한다. 그리고 대공기를 넣으려 했는데… 앨리스도 닐리도 대공기를 가지고 있기 때문에 밸런스가 좀 안맞다. 때문에 달래는 대공기를 빼기로 했다. 대신 공중으로 화살을 날리기로 하자.

활쏘기(Shot) : ↓→A or B, 홀드 시 타이밍 지연
공중으로 활쏘기(ShotAir) : ↓←A or B, 홀드 시 타이밍 지연
날아차기(FlyingKick) : ↓←K
반격(Parrying) : →B(상단) or ↓B(하단) or↑B(점프공격)
- 기술명 – 미시기장(靡恃己長) – 자신의 장점을 믿지 마라.
난타(Combo) : →←↓→B
- 기술명 – 화무십일홍(花無十日紅) – 열흘 붉은 꽃은 없다.

그리고 2기 데미지 모션들이 필요하다. 기본적으로 닐리와 같고, 더 추가가 되지는 않았다.

방어 (Block) – 엔진에선 3분할 된다.
앉아서 방어(CrouchBlock) – 마찬가지로 엔진에선 3분할 된다.
소점프킥(SmallJumpKick)
소점프킥 착지(SmallJumpKickLanding)
일직선 날아가기(DamageFlying)
날아가 벽에 부딪히기(DamageFlyingWall)
바닥에 엎드려 떨어지기(KnockDownFront)
공중에서 바닥에 꽂히기(DamageJumpSlam)
SlamAir의 넉다운 모션(KnockdownSlam) : DamageSlam에서 짤라쓴다.
회전하며 맞기(DamageScrewCW)
회전하며 맞기(DamageScrewCCW)
맞고 날아가기(DamageKnockback) : DamageJumpHeavy와 같다.
길게 맞기(DamageHeavyLong) : DamageHeavyHead와 같다. 연출상 딜레이를 두고 맞아야 할 때 사용한다.

6.14

모션의 구성을 생각해서 분리한 뒤에, 스테이트를 등록하고… 기존에 만들었던 시스템에 맞추어 코드를 수정하고… 즉, 준비작업만 2시간 남짓. 자동화도 어려운 작업이라 일일이 손으로 해야 한다. 챙겨야 할 것들이 참 많다.

6.15

활 쏘기, 공중쏘기는 발동이 느려서 대공기로는 조금 어려울 것 같고, 견제용이다. 그런데 숫자채우려고 넣은 날아차기가 뜻밖에 매우 고성능이다. 이제 반격을 만들어 보자.

반격! 번거롭긴 했는데 생각보다 구현은 쉬웠다. 가용시간은 1/6초인데, 노인이라 그런가. 맞추기가 꽤 어렵다.

닐리 작업하다가 달래를 보니 좀 심심한 느낌이 든다. 모션 느낌이 아직 많이 덜 잡혔지만 오늘은 타임오버.

6.16

모션 디테일 중. 활쏘기 프레임이 꽤 많이 나와서 회수동작을 넣었는데 너무 번잡시럽게 느껴진다. 내일 다시 고민해 보자.

6.17

활쏘기 프레임을 고민하다가 조상님들은(스파2) 어떻게 했을까? 를 살펴보았다. 지금까지는 장풍이 충분히 느리다면, 화면 안에 2개의 장풍이 존재할 수 있게 된다. 하지만 게임내에서 장풍을 2개 본 기억이 없는데, 지금까지는 이것이 화면비율때문이라고 생각했었다. 격투게임이 유행하던 시절의 화면비는 4:3이었다. 현재의 16:9화면에 비해 가로화면이 짧으므로 다음 장풍이 나타나기 전에 이전 장풍이 화면밖으로 사라진다…라고 생각했는데, 아니다! 장풍은 1개만 발사하도록 강제되고 있었다. 와. 정말로 섬세한 게임이다. 전설이 될만하다. 왜 이 쉬운 방법을 생각못했을까…

공중으로 화살을 날릴 땐 각도가 맞아야 한다. X로 4, Y로 2이동할 때 이 화살의 정확한 각도는 몇일까? 자비스에게 물어보자.

따라서 26도 정도 기울여 모션을 만들면 정확하다.

반격에 성공했을 땐 상대의 1타를 무시하고 역공을 한다. 비단 격투 게임뿐 아니라 거의 모든 게임에서 카운터는 후한 점수를 주기 때문에, 맞으면 넉백이 되는 강력한 공격이다. 그런데 비주얼이 너무 약하게 제작된 것 같아서 한 번 고쳤는데… 여전히 약해 보인다는 것이 좀 고민이다. 하지만 더 뾰족한 수도 떠오르지 않으니.. 그냥 하기로 하자.

6.18

점프와 하단 반격모션

그 다음은 초필. 용호난무.

때리는 건 내일 해보자.

러프는 잡았고…

6.19

모션 디테일도 잡았고, 이제 내일은 세컨더리 애니메이션을 해보자.

달래는 치마본의 움직임이 모두 수동이다.뚫리지 않도록 잘 조절해 주자.

으으음. 대충 된 듯? 이펙트 넘어가자.

버그 픽스

2024년 6월 11일2024년 6월 13일배틀퀸(BattleQueen)에 게시됨댓글 남기기

6.11

닐리는 마법사이기 때문에 마법이 완성되면 다 된것처럼 보인다. 하지만 운석에 가려 망토가 흩날리는 것이 잘 보이지는 않는다. 그 외에도 이런 잘 안보이는(하지만 엉성하면 티나는) 애니메이션이 많다. 이걸 해보자.

그런데 앨리스의 모션이 생각보다 호환이 잘된다.넘어가도 될 것 같다. 그럼 닐리의 작업은 여기서 마무리해도 될 것 같다.

하지만 그간 작업하면서 새롭게 튀어나온 버그들이 많다.

6.12

닐리의 킥잡기는 캐릭터를 거꾸로 세운다. 당연히 이 땐 캐릭터의 앞머리가 뒤집어질 것 같다. 그런데… 이것이 앨리스를 앨리스답지 않게 보이게 한다는 의견이 있었다.

물리적인 관점에서 보면 앞머리가 뒤집어지는 것이 맞다. 하지만 이것이 앞머리 몇가닥에 의해 캐릭터가 달라지는 만화적 관점에서 본다면 유지되는 것도 괜찮은 것 같다. 그리고 무엇보다 중요한 건 머리카락이 아니다! 이러한 정책은 향후의 작업량에도 많은 영향을 준다. 따라서 앞머리를 고정해보자. 아무리 단단히 고정해도 유니티에선 조금씩은 움직인다. 다이나믹 본이 있으니까.

두번째로 많았던 의견은 ‘왜 팬티가 민트색이야?’라는 의견이었다. 그것은 개인적 취향이므로 안고칠 예정이다. (여담이지만 이건 일부러 좀 튀게 했다. 흰색은 너무 흔하고, 너무 어울리면 그냥 유니폼같아서.)

원래 닐리의 장풍모션은 원래는 서서 지팡이만 까딱이는 수준이었다. 하지만 실제로 게임에 적용해 보니 발사지점이 높아서 장풍을 앉아서 피할 수 있는 문제가 있었다. 그 때서야 왜 스파2 터보(..맞나?)의 춘리가 왜 그런 엉거주춤한 자세로 장풍을 쏘는 지 깨닫게 되었다. 서나 앉으나 장풍이 맞아야 하는 문제도 있지만, 낮게 날아가는 장풍은 점프로 피하기도 쉬운 것이다. 정말 많은 시행착오끝에 나온 게임이었겠구나. 싶었다.

6.13

야호. 다 했다. 대시는 추후 작업이다. 며칠 전에 지인사무실에서 간이테스트를 했던 적이 있었는데, 가장 개선되었면 좋을 것 같은 요소였다. 21세기 유저가 플레이하기엔 아무래도 답답한 모양. 그래서 추가하기로 결정했다.

달래의 필살기 작업으로 넘어가자. 얘도 할 것이 참 많다.

닐리의 이펙트 #2

2024년 6월 8일2024년 6월 11일배틀퀸(BattleQueen)에 게시됨댓글 남기기

6.8

이펙트가 루프되는 경우, 이펙트가 사라질 때 바로 active를 끄면 안된다. 갑자기 사라져 어색하기 때문이다. 난 코루틴을 매우 싫어하지만, 이런 걸 처리하기엔 또 코루틴만한 게 없다.

오늘의 깨달음. 파티클의 라이프타임은 3가지가 있는데 Constant, ConstantMin, ConstantMax가 그것이다. 이 중 Constant는 항상 ConstantMax값과 같은 값을 리턴한다. 따라서 이걸 계산해 Duration으로 맞추고 Looping을 끄면 … 의미없네…? 그냥 Duration을 짧게 맞춰두면 된다. 게다가 길어봐야 5초니까…

…를 생각하다가 챗GPT에게 물어봤는데 훨씬 간단한 방법이 있다.(…)

    public void RemoveLoop(GameObject effect)
    {
        ParticleSystem[] particles = effect.GetComponentsInChildren<ParticleSystem>();

        foreach (ParticleSystem particle in particles)
        {
            particle.Stop();
        }

        StartCoroutine(CoroutineRemoveLoop(effect));
    }

    IEnumerator CoroutineRemoveLoop(GameObject effect)
    {
        ParticleSystem particle = effect.GetComponent<ParticleSystem>();

        while (particle.IsAlive(true))
        {
            yield return null;
        }

        Remove(effect);
    }

particle.Stop()은 생성을 멈추는 거고 IsAlive()는 잔여파티클이 완전히 사라졌는가 조사하는 것이다.

그른데 만들어놓고 보니 이거 찰 땐 불 안붙이는 게 자연스러워 보인다(…) 빼자.

파이어볼의 작은 파편 불꽃들은 이펙트가 명중한 후에도 남아야 한다. 하지만, 파이어볼 본체는 사라져야 어색하지 않다. 그렇기 때문에 2개의 처리는 다르다. 이걸 위해 발사체변수에 tailEffect를 넣었다.

아직 발사할 때와 맞을 때의 이펙트가 덜 됐지만 졸려서 여기까지.

6.9

‘마법을 사용하고 있다’라는 신호를 주기 위해 지팡이 끝에 이펙트를 달이야 한다. 이에 이펙트 탈부착 시스템이 필요했고, 이를 구현. 발사 이펙트 자체는 어려운 작업이 아니지만, 시스템을 잡느라 오래걸렸다. 그리고 알아낸 놀라운 사실. 지금까지 지팡이 본이 익스포트 안되고 있었다! 잘도 돌아갔군.

더불에 머티리얼 관리 문제도 새롭게 부상했다. 마법사라서 그런지, 생각보다 머티리얼이 많이 나온다.

6.10

이제 메테오를 만들자.

메테오- 두두두두

트레일도 달고,

이펙트는 끝나가지만 모션은 아직 더미이다. 일단 잡히는 모션에 이펙트를 추가하고, 애니메이션을 손보기로 하자.

6.11

잡기에 마법적인 요소가 들어있으므로, 이펙트를 추가하자.

이펙트를 만들고 붙이는 데 시간이 너무 오래 걸린다. 뭔가 좋은 방법이 있을 것 같은데…

닐리의 이펙트 #1

2024년 6월 5일2024년 6월 7일배틀퀸(BattleQueen)에 게시됨댓글 2개

6.5

닐리는 방어할 때 얼음을 사용할 예정이다. 본래는 애니메이션 작업을 해야 하지만, 얼음을 얹었을 때 모션을 정확히 보려면 셰이더가 우선구현되어야 한다. 때문에 얼음 셰이더가 필요한데, 이것은 곧 굴절셰이더이다. 이는 이미 빗방울을 구현할 때 해보았지만, 이는 셰이더 그래프를 통한 포스트프로세스로 구현한 것이고, 입체적인 모양은 다시해야 한다. 이건 모르니까 유튜브를 찾자.

굴절을 아주 정확하게 구현하려는 것은 아니니, 그 자체는 어렵지 않다. 하지만 SceneColor를 어찌가져오는지 몰랐다. 여기에 잘 설명이 되어 있는데, 문제는 GrabPass{}를 URP에선 못쓴다고 한다.

chatGPT에게 물어보니 URP에선 이것 대신 _CameraOpaqueTexture를 사용하면 된다고 한다. 이 텍스처는 반투명렌더 전의 오파쿠 상태를 텍스처로 사용할 수 있게 해준다. 때문에 Transparent큐에서만 사용할 수 있다. AlphaTest에서 사용해도 고장난다.

기본형은 다 만들었으니 이제 꾸며보자.

소품이 점점 늘어난다.

된 것 같음.

6.6

얼음 셰이더는 완성을 했으나 문제가 하나 있다. 타격효과까지 굴절되어 버리는 것이다. 이를 원하지 않으므로 ZTest를 Always로 설정해주고 싶다. 이를 위해선 ZTest부분을 열거형으로 설정해서 제어해주어야 한다.

    Properties
    {        
        [NoScaleOffset] _MainTex ("Cutout Texture", 2D) = "gray" {} 
        [HDR] _Color ("Color", Color) = (1, 1, 1, 1)
        _Threshold ("Cutout Threshold", Float) = 0 
        
        [KeywordEnum(Less, Greater, LEqual, GEqual, Equal, NotEqual, Always, Never)] _ZTest("ZTest Mode", Float) = 2        
    }

Enum어트리뷰트는 쓸 때마다 맨날 까먹는데, 자료도 별로 없어서 검색해도 잘 안나온다. chatGPT도 잘 모른다. 이 기회에 적어두자. 이후 커맨드 설정부에서

        Pass
        {            
            Cull Off
            Zwrite On
            ZTest [_ZTest]

일케 써주면 사용할 수 있다. 참고로 블렌드 모드는 엔진에 이미 지정이 되어 있는데

[Enum(UnityEngine.Rendering.BlendMode)] _BlendMode ("Blend Mode", Float) = 1

요래 선언하면 된다.

확실하게 앞에 찍기 위해 큐도 하나 높여준다. 빌드 테스트도 완료. 잘 돌아간다. 내부적으로는 셰이더가 2개로 분리되었을 것이라 추정한다.

얼음 작업이 이어지는 가운데, 입이 유별나게 하얘써 살펴봤더니… 오.맙소사. Transparent큐에서는 그림자 정보를 받지 못한다!

별 수 없이 컷아웃을 써야 한다. 이걸 안쓰고 싶었던 이유는 립스틱 때문인데… 포기해야 할 듯.

얼음은 주변의 빛을 반사하기 때문에, 스테이지마다 색이 달라야 한다.

되게 번거롭다.으악!

6.7

닐리의 트레일을 처리하던 중 트레일 구동방식이 좀 잘못되어 있음을 깨달았다. 이대로 진행해도 괜찮지만, 별로 깔끔하지가 않아서 앨리스로 거슬러 올라가 다시 처리하기로 했다. 트레일 코드를 고치고, 익스포트를 하고, 유니티에서도 셰이더 코드를 수정하고…다시 닐리로 돌아온다. 분명 귀찮은 일이지만, 각잡고 하면 의외로 빨리 끝난다.

한 동작이지만, 컨트롤러가 없으니 또 허전해서 추가.

영락없는 가일.

하지만 하나 달라야 하는 것이… 불속성이어야 한다. = 맞은 상대는 불에 타야 한다. = 셰이더를 만들어야 한다.

이글이글… 기본적인 원리는 킹오파에서 파렛 오프셋(?)에서 아이디어를 얻었다. 하지만 이것만으로는 좀 모자라고…

불은 어차피 필요하니 미리 만들어 두자. 파티클 생성시에 SDF를 두껍게 썼더니 적절하게 볼륨감이 생겨서 예쁜 모양이 됐다.

활활. 이제 붙이자.

닐리의 2기 애니메이션 제작 #1

2024년 6월 1일2024년 6월 11일배틀퀸(BattleQueen)에 게시됨댓글 남기기

6.1

닐리의 컨셉은 가일이다. 어쩌다보니 그렇게 됐다. 필살기 계획은 다음과 같다.

파이어볼(FireBall) : ←모으고 → A, B
섬머솔트킥(RollingJumpKick) : ↓ 모으고 ↑ K
날기(Wing) : 공중상태에서 ↑모으기. 다 모이면 앞으로 날아간다.
메테오(Meteor) : ← 모으고 →←→ B. 초필

마법사를 격투 게임에 녹여내려니 파이어볼 외에는 생각이 안나고, 가일이니까 대공기 하나 쯤 있어야 하니 섬머솔트킥을 넣었다(?)

그 외에도 추가 모션들이 필요하다. 앨리스 때 설정한 것에서 스턴이 빠지고 좀 더 추가됐다.

방어 (Block)
앉아서 방어(CrouchBlock)
소점프킥(SmallJumpKick)
소점프킥 착지(SmallJumpKickLanding)
일직선 날아가기(DamageFlying)
날아가 벽에 부딪히기(DamageFlyingWall)
바닥에 엎드려 떨어지기(KnockDownFront)
공중에서 바닥에 꽂히기(DamageJumpSlam)
SlamAir의 넉다운 모션(KnockdownSlam) : DamageSlam에서 짤라쓴다.
회전하며 맞기(DamageScrewCW)
회전하며 맞기(DamageScrewCCW)
맞고 날아가기(DamageKnockback) : DamageJumpHeavy와 같다.

모으기 기술의 특징은 사용이 어려운 대신 발동딜레이가 짧다는 것이다. 앨리스의 기술들이 6~12프레임의 발동딜레이를 가진다면, 닐리는 좀 더 빨라야 한다. 모션을 만들 땐 이 점에 주의해야 한다.

날기를 구현하기 위해선 빗자루가 필요하다. 마법사니까!

아무리 간단한 사물이라도 꼭 러프를 그려보는 편이 좋다.오랫만에 다 까먹었을 것 같은 모델링을 해보자.

블렌더엔 커브챔퍼기능이 없다. 이게 없어서 그동안 애드온을 깔아서 썼었는데, 블렌더가 버전업되며 더 이상 그 애드온을 지원하지 않게 되었다. 혹시 4.0의 커브에 챔퍼 혹은 베벨기능이 추가됐을까? 싶어서 살펴보았지만 보이지 않는다.

그런데 유튜브에 튜토리얼을 찾아보니 Curve가 아닌 Mesh상태에서 베벨을 준 후 커브로 옮겨오는 것이 아닌가…? 그..그러네?! 왜 이 생각을 못했지? 맥스 기준으로 생각하다보니 당연히 있어야 할 것이 없다는 생각이었는데, 블렌더는 엣지 모델링이 가능하므로 이 쪽에 맞추어 생각을 해야 한다. 오늘의 깨달음. 커브의 베벨을 사용하려면 메쉬를 써라.

모델링을 하고

색칠을 하자.

6.2

이제 모션을 러프하게 제작한다. 이 모션들을 기반으로 코드를 짜자.

익스포트를 해서 본격적으로 코드를 짜려고 하니 버그가 말도 안되게 많이 나왔다. 한숨 잔 다음 맑은 정신으로 도전하는 편이 좋겠다.

타격 시 밀리는 양에 따라 먼지를 조절하고 싶어서 파티클의 이미터에 접근해야 하는 코드가 필요했다. 그런데 유니티의 버스트는 구조가 이상하다.

            foreach (ParticleSystem particle in particles)
            {
                ParticleSystem.EmissionModule emmision = particle.emission;

                int burstCount = emmision.burstCount;
                ParticleSystem.Burst[] bursts = new ParticleSystem.Burst[burstCount];
                emmision.GetBursts(bursts);

                for (int i = 0; i < bursts.Length; i++)
                {
                    bursts[i].cycleCount = (int)(Mathf.Abs(pushDistance) / 0.1f);
                }

                emmision.SetBursts(bursts);
            }

GetBurst()는 Burst객체를 리턴하고 GetBursts()는 배열을 리턴해야…. 할 것 같은데 int를 리턴한다.(??) 기존 버스트의 숫자하나를 바꾸고 싶을 뿐인데, 새 인스턴스를 만들어서 갈아끼우는 비효율적인 방식을 쓰고 있다. 알고 보니 GetBurst()로 얻은 객체도 읽기 전용인 듯? Get은되는데 Set이 안된다.

으..모으기 처리도 쉽지 않다. 키가 많이 충돌하는데, 조용한 새벽에 각잡고 봐야할 것 같다.

6.3

키처리 완료. 이제 1초를 모아야 장풍이 나간다. 어우.. 어렵다. 그런데 앉아서 대기군인 하려니 키 충돌이 있다… 세상에! 21세기에 키충돌이라니!

…를 다시 조사해보니 코드에 L,R입력 중 하나만 받게 되어 있었다. 둘 다 누르면 선입력된 것만 적용된다. 그..그럼 그렇지.

섬머솔트 킥! 잘 어울린다. (?)

발사체는 현재 데이터가 없는데, 생각보다 많은 데이터가 필요하다. 이에 대한 시스템을 먼저 구축해야 할 것 같다.

6.4

오늘의 깨달음.

유니티의 c#스크립트에서 그냥 tag를 불러와도 해당 게임오브젝트의 tag를 알아서 리턴한다. 굳이 .gameObject.tag 로 안써도 된다. 원래 이랬나..?!

발사체를 맞았을 때의 밀림처리, 발사체가 화면 밖으로 나갔을 때의 처리등을 구현했다. 풀매니저는 필요없을 거라 생각했는데, 안만들었으면 큰일날 뻔했다.

그냥 게임매니저 아래에 마구잡이로 저장해놓았던 리소스들은 순식간에 늘어난다.

닐리의 기본 콤보. 모으기 커맨드는 정말 어렵다.

버그 픽스

2024년 5월 31일2024년 5월 31일배틀퀸(BattleQueen)에 게시됨댓글 남기기

5.31

이펙트 매니저를 손보며 발생한 문제가 꽤 됐었다. 그런데 절반 정도는 그냥 게임로직에 관련된 것이라는 것이 웃기다…여튼 이런 작은 것들을 손보다 보면 게임이 좀 더 완성됐다는 느낌을 받아서 기분이 좋아진다.

눈깜빡임은 간헐적으로 일어나야 한다. 현업에 있을 땐 이런걸 애니메이션에 박아넣곤 했는데, 이것이 캐릭터를 로봇처럼 보이게 하는 원인이 됐었다. 이런 비정기적 움직임은 랜덤수를 이용해 코드로 처리하는 것이 자연스럽다.

그 외에 눈에 보이지 않는 작업을 처리. .. 끝인가!? 일찍 끝났네?!

이제 닐리의 2기 애니메이션 작업으로 넘어가자

앨리스의 이펙트 #2

2024년 5월 28일2024년 5월 31일배틀퀸(BattleQueen)에 게시됨댓글 2개

5.28

유니티의 셰이더는 프로퍼티의 이름이 변하면 정보가 초기화된다. 때문에 애써 맞춰놓은 색상정보가 날아가기 쉽다. 원론적으로 이야기하자면 프로퍼티의 이름이 변하면 안되지만, 개발하며 어디 그게 쉬운 일인가. 이름으로 판독하는 처리가 얼마나 많은데.

때문에 나중에 닥쳐올 불행을 미리 대비하는 마음으로 레벨데이터 매니저를 새로 만들었다. 씬의 번호에 따라 미리 세팅된 조명과 먼지의 색정보등을 넣어주는 방식이다.

하지만 작업을 하고 나니 문제가 또 있는데, 셰이더가 늘어난다…! 별로 바람직하지가 않다. 프로퍼티로 구분하면 안될 것 같고, 파티클이름으로 구분해야 할 것 같다. 그럼 파티클을 만들 때마다 이름에 신경써야 하잖아…싶었는데 별수가 없다. 다시 되돌리자.

많은 고민 끝에 배경과의 호환을 위해 파티클의 게임오브젝트에 이름을 예약어로 사용하기로 했다. dust, stratum, soil, crack의 이름은 예약어로 사용된다. 리소스의 이름엔 항상 앞에 대문자를 붙이는 규칙이 있으니, 원칙적으로는 충돌하지 않는다. 그 외 HDR로 지정된 컬러프로퍼티엔 리니어변환을 해주어야 한다. 그런데 이게 정확하지가 않다… 이에 대해 조금 조사를 했는데 최종 화면에 나오는 컬러를 구하는 법은 톤매핑까지 거치며 매우 복잡해지는 것 같다. 뭐 그렇게 중요한 것은 아니고 비슷하게는 나오니, 넘어가기로 하자.

이제 스테이지별로 이펙트가 다른 색깔로 표현된다.

머티리얼을 정리하고, 발도장 이펙트도 완료…했는데 너무 후져서 사거리 좀 늘려야 할 듯

5.29

아휴. 안끝나…

어류겐할 때 검기 모양이 동그란게 안어울려서 셰이더 로직을 수정하자.

하고 싶은 걸 해봤는데 별로 안예쁘다…되돌리자.

요 기술엔 둥그런 먼지를 추가.

공중에서 Slam데미지를 맞을 경우의 처리가 되어있지 않아서 처리했다.

데미지 모션이 정말 많다. 포스트는 이펙트 작업인데, RnD작업이 훨씬 더 많아.

5.30

이래저래 삽질이 많았던 작업프로세스는 점차 분명해져간다. 모든 문제는 결국 어떤 방향으로든 해결되기 마련이다. 그렇다면 이 쯤에서 효율성에 대해 한 번 더 고민을 해보자.

지금은 이펙트를 Left/Right를 분리해 만들고 있다. 파티클시스템은 단순히 스케일-1로 해결되지 않는 경우가 많기 때문이다. 이거… 정말 안될까?

스케일을 좌우반전했을 때, 문제가 되는 부분은 파티클이미터가 기울어져 있는 경우이다. 이것은 트랜스폼이 아니고 이미터의 정보이기 때문이다. 그럼 트랜스폼을 기울이면 될 것 아닌가?

…는 전혀 엉뚱한 값이 튀어나온다. 안되나 보다.

위치는 반전이 된다. 그렇다면 기울어져 있는 이미터의 각도만 바꿔주면 되는 것 아닐까?

이미지를 바꿔보니 문제가 하나 더 있다. 이미지는 Flip되어야 한다. 일단 여기까지 적용가능 여부를 확인해보자.

오? 일단 요기까지는 작동한다. 시운전 끝났으니까 실전에 적용해보자.

2시간 가까이 시도했…지만, 실패했다. 고려할 게 너무 많다. 그렇다고 조건을 줄이면 이펙트 제작에 제약이 많아진다. 이거 정말 안되네. 에이…

오늘의 깨달음. 프로퍼티의 HDR은 단순히 숫자를 1이상 쓸 수 있도록 해주는 것이 아니다. Color프로퍼티를 좀 일원화시켜보고자 이를 적용해봤는데, 그냥 컬러는 톤매핑을 거치지 않은 러프한 색을 내보낸다.

방어 이펙트도 작업완료. 맞은 후엔 배우는 것이 있다.

5.31

일단 이렇게 앨리스의 이펙트를 완료. 파란색 머리는 2P가 헛갈려서 바꿔놓은 것이다.

이펙트 시스템을 구축하며 헤집어 놓은 코드들 때문에 버그가 많이 쌓였다. 이를 한 번 정리하고 가는 편이 좋아보인다.

앨리스의 이펙트

2024년 5월 24일2024년 5월 29일배틀퀸(BattleQueen)에 게시됨댓글 남기기

5.24

먼저 기존의 이펙트를 조금 손보아야 한다. 먼지 이펙트는 지금까지 무언가 2%부족한 느낌이 있어서 바닥과의 연결부가 되는 이펙트를 추가하자. 원래는 캐릭터처럼 뒤쪽에 그림자를 뿌려볼 생각이었는데, 파티클이 머티리얼을 1개밖에 받지 못한다. 그래서 셰이더를 개조해 한 번에 2번을 그릴 수 있는 2pass셰이더로 만들었더니, 이번엔 또 두번째 패스에서 커스텀 데이터를 받지 못한다. 옘병!

별 수 없이 아랫부분에 그림자스러운 그라데이션을 약간 주고, 점프할 때 ‘팟!’하는 느낌의 쇼크이펙트를 추가하자. 이것은 시간으로 따지면 0.2초 정도 되는데, 이 짧은 순간의 유무가 완성도에 상당한 영향을 끼친다.

그리고 이 결론을 얻기까지 저녁 작업 시간을 모두 할애했다….나머지는 내일

스샷찍고 나니 위치가 좀 안맞는다…

이제 먼지는 된 것 같고,

파티클은 좀 더 작은 입자를 추가.

기존 작업 수정은 끝났고, 해야 할 것들에 대해서 정리해 보자.

공용 이펙트:

Grappling – 잡았을 때.
DustDamageSlam – 내리꽂기 공격을 당했을 때. (돌이 튀어야 한다.)
DamagePush – 데미지를 받고 크게 밀릴 때
Block – 방어했을 때

앨리스 이펙트

AliceCrouchKickDust – 둥글게 땅을 훑는 스타일의 먼지
AliceCrouchPunchHeavyDust
AliceTripleAttack_Dust_01
AliceTripleAttack_Dust_02 : 01과 같은데 좀 더 길다.
AliceUpperSlash
AliceStomp
AliceBash

그런데 이펙트의 위치를 어떻게 잡을 것인가? 결국은 데이터가 필요하다. 먼저 애니메이션 이벤트리스너에 Effect()를 추가하고, 여기에 데이터문자열을 건네준다. 데이터는 스트링과 구조체의 딕셔너리로 이루어진다.

        effectData["SuperAttack"] = new EffectDataStruct{
            prefabString = "SuperAttack",
            followCharacterDirection = true,
        };

        effectData["DustLanding"] = new EffectDataStruct{
            prefabString = "DustLanding",
        };

쓰고 나니 현재 열거형으로 사용하고 있는 State도 딕셔너리로 처리하면 편하지 않았을까. 싶긴 한데, 속도면에선 그냥 열거형에 접근하는 쪽이 아무래도 빠를 것 같다. (업데이트에서 정말 뻔질나게 찾으니까…)