오로라의 필살기는 주로 잡기다. 이것만으로 할 일이 좀 더 많은 편인데, 이걸 한 이후에도 각 캐릭터에게 잡기에 해당하는 애니메이션을 추가해 주어야 한다. 많이 한 것 같은데, 아직 먼 길 가야 된다. 차근차근 가자.
팔돌리기에 트레일을 추가. 달리기 속도 높이니 뜻밖에 연계기가.. 되네?!
초필을 만들자.
팔돌리기만 반나절이 걸렸다. 힘든 애니메이션이었어. 그런데 아직 안끝났다는 것이…
6.28
와. 요근래 가장 힘든 작업이었다. 그나저나 화면이 좁네!
6.29
공중잡기와 초필살기에서 위치가 어긋나는 문제가 있었다. 현상은 같지만 원인이 달랐는데, 버그추적을 하다보니 결국 같은 문제였다는 것이 밝혀져서 허탈.. 덕분에 코드의 구멍을 좀 더 메울 수 있어서 완전히 헛된 시간은 아니었다.
오로라의 이펙트는 별 게 없다. 잡기 캐릭터이다 보니 거의 먼지투성이다. 별도의 포스트를 거치지 않고 빠르게 완료하자.
와… 어려웠다. 이제 정리 작업을 해보자.
오로라는 앨리스밖에 잡질 못한다. 왜냐면 앨리스에게만 잡기 모션이 포함되어 있기 때문이다. 이제 이것들을 다른 캐릭터들에게도 포함시켜 주어야 한다.
내가 게임을 개발하며 정말 많이 놀랐던 것이 이런 부분이다. 우리가 당연하다고 생각되는 것들은, 누군가의 손을 거친다. IT업계라고 하면 아주 놀라운 최첨단의 업무처리방식을 갖추고 있을 것 같지만, 내막을 살펴보면 대부분 누군가의 그림자 노동으로 이루어져 있다.. 자동으로 되는 건… 유감스럽지만, 거의 없다. 개발자란, 그냥 최신식 기술을 사용하는 일꾼일 뿐이다.
길게 맞기(DamageHeavyLong) : DamageHeavyHead와 같다. 연출상 딜레이를 두고 맞아야 할 때 사용한다.
커맨드기는 아직 구상 중이다. 잡기 캐릭터이니 초필은 커맨드잡기 확정이고, 필살기 중에도 하나는 있어야 한다. 그리고 버튼 연타기술도 구현돼야 한다. 버튼 연타는 구상한 기술입력 시스템의 마지막 퍼즐이다. 이 외에 버튼 2개이상 동시에 누르기 등이 있지만, 난 버튼 동시 발동을 별로 좋아하지 않으므로 패스하기로 하자.
허그(Hug) – ←↓→ A or B (구상 중)
대공잡기(AirCatch) – 공중에서 ←↓→ A or B (구상 중)
팔 휘두르기(Swing) – A연타 or B연타.
정신없이 쿵쾅쾅(SmashDown) – ↓←↓→ B 초필.
필살기 말고도 만들 모션은 많다. 차차 생각해보자.
방어부터 시작
이야야야아아아-ㅇ아-=
소점프킥. 얘는 연계기로 연결이 안됨.
야야야얍
방어 후 바로 반격을 할 수 있는 버그가 있어서 추적을 시작했는데, 해결까지 무려 4시간이 걸렸다.[…] 이게 전부터 재현이 안되던 버그였는데, 이번에 재현이 되어 추적 끝에 결국 해결. 지금까지 개발하며 어려운 상황을 많이 맞이해봤지만, 이번 버그는 역대급이었다. 아휴… 이제 안정될 때도 됐건만…
다시 애니메이션으로 돌아가자.
커맨드잡기 – Hug는 상대를 끌어안은 다음, 폭탄을 쥐어주고 본인은 떨어진다. 뱀파이어 세이버의 바레타와 같다. 원래는 끌어안는 척 하면서 뒤로 물러서 기계손으로 머리를 친 다음 쓰러진 상대를 덮치면 심판이 튀어나와 1,2,3을 외치려고 했는데…너무 길다!
폴짝. 이렇게 끌어안는다.실패 시 딜레이가 큼.
구현 중… 생각보다 손이 많이 간다.
6.24
작업이 하기 싫을 때가 있다. 모든 일을 의욕적으로 처리하기는 당연히 어렵다. 그럴 때 난 느릿느릿~하는 편을 택한다. 머리를 비우고 일을 천천히 진행하는 것이다. 클릭도, 타이핑도 느리게. 또박또박. 재미있게도 목표점에 다다르는 시간이 크게 차이가 나질 않는다. 아니, 오히려 더 빠를 때도 있다. 그리고 무엇을 했든, 그 결과가 의지를 충전해 준다. 글씨를 또박또박 쓰는 것과 같다. 하고 나면 뿌듯하다. 작업을 이어갈 수 있는 원동력이 된다.
그래서 일단…음. 폭탄을 만들었다.오로라가 이걸 앨리스에게 주도록 해보자.
요로케 붙여야지.
…
오늘의 깨달음. 폭발 후 어깨에 불이 계속 붙어있는 문제가 있어서 추적을 해보니 particle의 입자를 생성중인가의 조건식의 particle.IsAlive()가 문제였다. 이것은 파티클의 입자가 아직 살아있는가?를 조사하는 게 맞기는 한데, looping이 켜져있을 경우 여전히 살아있는 것으로 인식한다. 야이… Stop()으로 파티클을 껐으면 당연히 looping도 끄는거지! 결국 수동으로 라이프타임을 재계산해서 파괴하는 방식을 썼다. 뜻밖에 멍청한 구석이 있네. 내가 못찾은 건가…
세상에서 가장 뜨거운 포옹이다. 퍼엉이겠지
6.26
어제 작업을 건너뛴 건 아닌데, 소득이 없었다. 공중 잡기의 컨셉이 정말 어려웠는데, 팔이 너무 크다 보니 리치가 지나치게 길어져서 OP가 된다. 안그래도 상대하기 까다로운 게 잡기 캐릭인데, 공격범위까지 넓을 수는 없다보니 구상에 많은 시간이 걸렸다.
그래서 최종 구상은 파리잡기!
잡히면 요래 땅에 박힌다. 애니메이션은 아직 완성이 덜 됐다.
땅에 박히는 모션을 복사하기 위해 데미지 액션 중 DamageSlam의 전체 액션을 복사해야 했다. 그런데 잘 안된다. 원인을 찾아보니 다양하다.
다리의 본 애니메이션이 Euler로 만들어져 있다.
쿼터니온으로 변경해서 해결할 수 있다.
채널이 없다.
alt+r등으로 fcurve를 생성해 주어야 한다. 블렌더는 애니메이션을 붙일 때 fcurve가 없으면 붙이지 않는다.
그룹 외 커브이다.
이는 스크립트를 사용하다 생기는 오류인데, 몇몇 애니메이션은 본의 그룹을 벗어난다. 정상적인 상황이라면 커브는 모두 본의 이름을 그룹으로 갖는다. 하지만 이것이 바깥으로 빠져나와있는 경우가 있다. 이럴 경우, 복사가 되질 않는다. AutoRig Pro의 쿼터니온 변환이 이런 오류를 일으킨다. 그룹에서 벗어나 있어도 애니메이션은 잘 되기 때문에 큰 문제삼지 않았는데, 이런 문제가 있을 줄은.
키를 복사할 때 그룹이 선택되어 있다.
특정 채널이 선택되어 있을 경우, 전체 선택(A)를 눌러도 해당 채널만 복사되는 현상이 있다. 이건 버그가 아니고 블렌더에서 그렇게 설정되도록 한 것이다. 불편해!
이 때문에 오랫만에 스크립트를 업데이트하고, 정리하다 보니 타임오버. 쿼터니온 문제는 첫단추를 잘못 꿴 댓가이다. 첫 데이터가 말썽이면 개발 내내 고통받는다. 레퍼런스 모델은 필요한 관절은 모두 쿼터니온으로 변경해 놓았다. (다시 한 번 체크해보자.) 5번째 캐릭터부터는 이런 고통이 좀 줄어들 것이다.
공중잡기 완료. 그런데 이걸 테스트하면서 잡기 위치가 어긋나는 현상을 발견했다. 이건… 음. 과거에 프레임이 튈 때 위치가 어긋나는 문제가 있어 방어코드를 넣은 것이 오히려 버그를 내고 있었다. 이를 삭제하니 잘되는 것 같아 보이긴 하는데, 좀 더 정확한 건 테스트를 해보아야 알겠다.
화살에 이펙트를 붙이지 않으면 덩어리감이 없어 눈에 잘 띄지 않으므로 뭐라고 붙여야 한다. 그래서 생각해낸 것이 삐죽삐죽한 이펙트이다.
드래곤 플라이트를 만들 당시, 캐릭터 주변에 붙는 가시이펙트는 맥스를 이용해서 만들었었다. 당시는 자체엔진을 사용했기 때문에 파티클로 저걸 구현해낼 방법이 없어서 맥스로 만든 걸 익스포트해서 썼었는데, 유니티라면 되지 않을까
오.. 잘 된다.
화살은 완료
뜻밖에 매우 어려웠던 대각선 화살. 이게 왜 어려웠냐면 스케일때문이다. 현재는 파티클을 생성시킨 후, 세로스케일을 줄여서 사용하고 있는데, 이것이 월드 기준으로 계산된다. 따라서 이것을 로컬기준으로 변경하려면 몇가지 설정이 필요하다. 일단 렌더러 설정에서 렌더정렬을 Local로 바꿔주고
스케일링 모드를 하이라키로 바꿔준다.
그리고 스케일을 줄인 후, 로테이션 또한 하이라키에서 제어해야 한다.
처음엔 파티클의 기울기를 StartRotation에서 제어하고 있었는데 이게 오답이었다. 이것 때문에 저녁작업시간을 홀라당 날려버렸다. 흑흑
6.20
이펙트를 등록하려면 많은 과정을 거쳐야 하는데, 이것이 너무 번거롭게 느껴져서 리팩토링. 이제 데이터에 이펙트 정보가 없다면 빈 정보를 생성하고, 좌우 반전 이펙트의 경우 오른쪽 정보를 먼저 찾아보도록 변경했다. 코드가 한결 깔끔해졌다. 그럼 스테이트 정보도 이렇게 하면 더 깔끔하겠네! 싶어서 봤더니, 스테이트는 빈 데이터를 사용하는 경우가 거의 없어서 의미가 없었다.(비어있는 경우는 None과 Idle밖에 없었다!)
길게 맞기(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.12
닐리의 킥잡기는 캐릭터를 거꾸로 세운다. 당연히 이 땐 캐릭터의 앞머리가 뒤집어질 것 같다. 그런데… 이것이 앨리스를 앨리스답지 않게 보이게 한다는 의견이 있었다.
물리적인 관점에서 보면 앞머리가 뒤집어지는 것이 맞다. 하지만 이것이 앞머리 몇가닥에 의해 캐릭터가 달라지는 만화적 관점에서 본다면 유지되는 것도 괜찮은 것 같다. 그리고 무엇보다 중요한 건 머리카락이 아니다! 이러한 정책은 향후의 작업량에도 많은 영향을 준다. 따라서 앞머리를 고정해보자. 아무리 단단히 고정해도 유니티에선 조금씩은 움직인다. 다이나믹 본이 있으니까.
두번째로 많았던 의견은 ‘왜 팬티가 민트색이야?’라는 의견이었다. 그것은 개인적 취향이므로 안고칠 예정이다. (여담이지만 이건 일부러 좀 튀게 했다. 흰색은 너무 흔하고, 너무 어울리면 그냥 유니폼같아서.)
원래 닐리의 장풍모션은 원래는 서서 지팡이만 까딱이는 수준이었다. 하지만 실제로 게임에 적용해 보니 발사지점이 높아서 장풍을 앉아서 피할 수 있는 문제가 있었다. 그 때서야 왜 스파2 터보(..맞나?)의 춘리가 왜 그런 엉거주춤한 자세로 장풍을 쏘는 지 깨닫게 되었다. 서나 앉으나 장풍이 맞아야 하는 문제도 있지만, 낮게 날아가는 장풍은 점프로 피하기도 쉬운 것이다. 정말 많은 시행착오끝에 나온 게임이었겠구나. 싶었다.
6.13
야호. 다 했다. 대시는 추후 작업이다. 며칠 전에 지인사무실에서 간이테스트를 했던 적이 있었는데, 가장 개선되었면 좋을 것 같은 요소였다. 21세기 유저가 플레이하기엔 아무래도 답답한 모양. 그래서 추가하기로 결정했다.
이펙트가 루프되는 경우, 이펙트가 사라질 때 바로 active를 끄면 안된다. 갑자기 사라져 어색하기 때문이다. 난 코루틴을 매우 싫어하지만, 이런 걸 처리하기엔 또 코루틴만한 게 없다.
오늘의 깨달음. 파티클의 라이프타임은 3가지가 있는데 Constant, ConstantMin, ConstantMax가 그것이다. 이 중 Constant는 항상 ConstantMax값과 같은 값을 리턴한다. 따라서 이걸 계산해 Duration으로 맞추고 Looping을 끄면 … 의미없네…? 그냥 Duration을 짧게 맞춰두면 된다. 게다가 길어봐야 5초니까…
particle.Stop()은 생성을 멈추는 거고 IsAlive()는 잔여파티클이 완전히 사라졌는가 조사하는 것이다.
그른데 만들어놓고 보니 이거 찰 땐 불 안붙이는 게 자연스러워 보인다(…) 빼자.
파이어볼의 작은 파편 불꽃들은 이펙트가 명중한 후에도 남아야 한다. 하지만, 파이어볼 본체는 사라져야 어색하지 않다. 그렇기 때문에 2개의 처리는 다르다. 이걸 위해 발사체변수에 tailEffect를 넣었다.
아직 발사할 때와 맞을 때의 이펙트가 덜 됐지만 졸려서 여기까지.
6.9
‘마법을 사용하고 있다’라는 신호를 주기 위해 지팡이 끝에 이펙트를 달이야 한다. 이에 이펙트 탈부착 시스템이 필요했고, 이를 구현. 발사 이펙트 자체는 어려운 작업이 아니지만, 시스템을 잡느라 오래걸렸다. 그리고 알아낸 놀라운 사실. 지금까지 지팡이 본이 익스포트 안되고 있었다! 잘도 돌아갔군.
더불에 머티리얼 관리 문제도 새롭게 부상했다. 마법사라서 그런지, 생각보다 머티리얼이 많이 나온다.
6.10
이제 메테오를 만들자.
메테오- 두두두두
트레일도 달고,
이펙트는 끝나가지만 모션은 아직 더미이다. 일단 잡히는 모션에 이펙트를 추가하고, 애니메이션을 손보기로 하자.
닐리는 방어할 때 얼음을 사용할 예정이다. 본래는 애니메이션 작업을 해야 하지만, 얼음을 얹었을 때 모션을 정확히 보려면 셰이더가 우선구현되어야 한다. 때문에 얼음 셰이더가 필요한데, 이것은 곧 굴절셰이더이다. 이는 이미 빗방울을 구현할 때 해보았지만, 이는 셰이더 그래프를 통한 포스트프로세스로 구현한 것이고, 입체적인 모양은 다시해야 한다. 이건 모르니까 유튜브를 찾자.
굴절을 아주 정확하게 구현하려는 것은 아니니, 그 자체는 어렵지 않다. 하지만 SceneColor를 어찌가져오는지 몰랐다. 여기에 잘 설명이 되어 있는데, 문제는 GrabPass{}를 URP에선 못쓴다고 한다.
chatGPT에게 물어보니 URP에선 이것 대신 _CameraOpaqueTexture를 사용하면 된다고 한다. 이 텍스처는 반투명렌더 전의 오파쿠 상태를 텍스처로 사용할 수 있게 해준다. 때문에 Transparent큐에서만 사용할 수 있다. AlphaTest에서 사용해도 고장난다.
기본형은 다 만들었으니 이제 꾸며보자.
소품이 점점 늘어난다.
된 것 같음.
6.6
얼음 셰이더는 완성을 했으나 문제가 하나 있다. 타격효과까지 굴절되어 버리는 것이다. 이를 원하지 않으므로 ZTest를 Always로 설정해주고 싶다. 이를 위해선 ZTest부분을 열거형으로 설정해서 제어해주어야 한다.
확실하게 앞에 찍기 위해 큐도 하나 높여준다. 빌드 테스트도 완료. 잘 돌아간다. 내부적으로는 셰이더가 2개로 분리되었을 것이라 추정한다.
얼음 작업이 이어지는 가운데, 입이 유별나게 하얘써 살펴봤더니… 오.맙소사. Transparent큐에서는 그림자 정보를 받지 못한다!
별 수 없이 컷아웃을 써야 한다. 이걸 안쓰고 싶었던 이유는 립스틱 때문인데… 포기해야 할 듯.
얼음은 주변의 빛을 반사하기 때문에, 스테이지마다 색이 달라야 한다.
되게 번거롭다.으악!
6.7
닐리의 트레일을 처리하던 중 트레일 구동방식이 좀 잘못되어 있음을 깨달았다. 이대로 진행해도 괜찮지만, 별로 깔끔하지가 않아서 앨리스로 거슬러 올라가 다시 처리하기로 했다. 트레일 코드를 고치고, 익스포트를 하고, 유니티에서도 셰이더 코드를 수정하고…다시 닐리로 돌아온다. 분명 귀찮은 일이지만, 각잡고 하면 의외로 빨리 끝난다.
한 동작이지만, 컨트롤러가 없으니 또 허전해서 추가.
영락없는 가일.
하지만 하나 달라야 하는 것이… 불속성이어야 한다. = 맞은 상대는 불에 타야 한다. = 셰이더를 만들어야 한다.
이글이글… 기본적인 원리는 킹오파에서 파렛 오프셋(?)에서 아이디어를 얻었다. 하지만 이것만으로는 좀 모자라고…
불은 어차피 필요하니 미리 만들어 두자. 파티클 생성시에 SDF를 두껍게 썼더니 적절하게 볼륨감이 생겨서 예쁜 모양이 됐다.
모으기 기술의 특징은 사용이 어려운 대신 발동딜레이가 짧다는 것이다. 앨리스의 기술들이 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 로 안써도 된다. 원래 이랬나..?!
발사체를 맞았을 때의 밀림처리, 발사체가 화면 밖으로 나갔을 때의 처리등을 구현했다. 풀매니저는 필요없을 거라 생각했는데, 안만들었으면 큰일날 뻔했다.
이즈 본거지 