코딩시러

애니메이션

기본적으로 유니티의 애니메이션은 다음으로 구성되어 있다.

Pose : 각 한 모션에 대한 애니메이션의 키 값(각 프레임별로 메쉬가 어느 위치에 있는지)들로 구성된 확장자.

Pose Controller : 각 Pose들을 FSM식으로 구성하여 하나의 모델 애니메이션 사이클을 나타내는 정보. 

Animator Component : Pose Controller를 참조해 모션을 직접 컨트롤 하는 개체.

유피의 소원

소개

게임인재원 6기 1학기때 5월 중순부터 2주간 진행한 미니프로젝트 작품입니다. (그걸 왜 이제 올리는데)

WinAPI를 기반으로 GDI+ 그래픽 라이브러리를 사용해 개발했습니다.

기획 3명, 아트 2명, 프로그래밍 4명으로 진행되었습니다.

구현

총 4명의 프로그래밍 팀원이 작업했습니다.

엔진이라고 하긴 뭐하지만... 개발 당시에 어느정도 엔진 흉내는 내던 저의 엔진을 사용해 작업을 했습니다. 

플레이 사진

아쉬운 점

지금이야 과거형이라 상당수 고쳤지만 그때 느꼈던 아쉬운 점을 남겨본다....

1. 객체의 생성과 삭제 주기 : 객체의 생성과 삭제 주기에 대한 설정이 없이, 바로 생성되고 바로 삭제되서 런타임 중에 버그가 발생하거나 크래쉬가 났던 버그... 막바지에 고치기가 힘들어서 대충 하드코딩으로 땜빵했는데 정말 불편했다.

2. 데이터 접근 : 클래스의 멤버변수를 무지성으로 static과 public으로 남발했다. 구현할 때는 편하지만 정말 안좋은 습관인거 같다.

3. 그래픽 라이브러리에 대한 낮은 이해도 : GDI+는 GPU를 사용하지 않는 그래픽 라이브러리라 속도가 매우 느리다. 이 점을 간과하고 제작했던 점.(렉이 상당했다. 그나마 줄이고 줄인게 이 정도)

4. 스프라이트 리소스에 대한 아쉬운 처리 : 저 때 스프라이트 출력 방식은 스프라이트를 전부 컷팅해놓고 쓴게 아니라, 스프라이트 사진을 렌더링할때마다 일부 영역만 렌더링하게 만들었다. 일부 영역만 렌더링하는 것에 대한 부하가 많이 심하다는 것을 깨달은 것은 상당히 충격적이었다...

https://drive.google.com/file/d/1bMvEyE0OpJd5UDxcQ7aIpQMBeLpfFRVG/view?usp=drive_link

<조작법>

방향키 : 이동

스페이스 : 자리에 놓기

컨트롤 : 물리기 (되돌아가기)

이번엔 콘솔로 게임을 만들어보려고 많은 공부를 했다!!!!

첫 콘솔게임으로 오목게임을 만들어 보았다. 사실 미로게임도 만들긴 했는데 나중에 올려야겠다.

오목을 구현하는거 자체는 쉬웠는데 더블 버퍼링 기법이 너무 복잡하고 구현에 제약이 많았던게 힘들었다.

특히 원래 오른쪽 창에 턴 수와 플레이어가 어디에 뒀는지 좌표를 나타내 주려고 했는데, 더블 버퍼링은 int자료형을 출력하기가 어려워서 끙끙 싸매다가 버그가 줄줄이 터져서 그냥 포기했다.....

스택 자료구조를 클래스로 구현해볼 겸 오목을 만들어 봤는데(물리기를 구현하기 위해) 성공적으로 되서 좋은 경험이 되었다 

최근에 유니티공부를 시작하고 플래시는 이제 안만질 것 같아서 기록겸 추억겸 복습겸 만들던거 올림.

무려 5년 전에 만들었던 플래시 던파 모작이다..... 현생 살다 보니 플래시가 망했다 ㅠ

저 때 플래시로 던파 그대로 카피하는게 꿈이었는데 실력이 안돼서 포기했었다.

그러다 퇴사하고 프로그래밍 공부를 다시 해보려고 마음먹고 공부하다보니 다시금 이 모작이 생각났다.

예전에 막혔던 상당부분들의 파훼법이 막 생각이 나서 다시 만들어 보기로 했다.

2024.01.19 ~ 02.05 정도? 약 2주 정도 전력을 다해서 다시 빡세게 만들어보았다.

작업 환경_1

작업 환경_2

이건 몬스터 처치 시 아이템 드롭 액션(코드)중 일부

이건 몬스터 액션중 일부

어쨌든 3주간의 결과

던파를 5년 전부터 지금까지 모작해보면서 느낀 점이 참 많다. 던파가 옛날 게임인데도 불구하고 정말 심오한 부분이 많았음.

1. 일단 오브젝트보다 뒤에 있으면 캐릭터가 오브젝트보다 뒤로 가고, 앞에 있으면 다시 캐릭터가 오브젝트보다 앞으로 오고... 이걸 플래시로 구현하려면 "swapDepth"라는 심도를 조절해 주는 명령어를 써야 하는데, 인게임에 같은 심도 값을 가진 무비클립(객체)들이 하나라도 존재한다면 객체가 사라져 버리는 치명적인 약점이 있어서 충돌하지 않게 하려고 머리를 진짜 많이 썼다...

2. 그리고 2D게임인데 x(양 옆), y(점프하는 축), z(위 아래)축이 구현돼있어서Hit판정을 구현하는데 참 애먹었다. 공격할 때 HitBox에 몬스터가 닿더라도 캐릭터와 피격자의 Y축이 일정 범위 안에 닿았는지도 판정해야 하고... 몬스터가 다운 중에도 때릴 수 있는 공격이 있고, 아닌 공격이 있고.... 생각할게 참 많았다.

3. 플래시로 인벤토리같은 슬롯 시스템과 Drag&Drop을 처음 도전해 본 건데, 나름 문제없이 상상대로 잘 구현돼서 뿌듯했다. 특히 이거 덕분에 배열공부에 은근히 도움 된듯. (슬롯마다 [아이템 넘버, 강화 수치, 부가 효과 ... 등등])

4. 플래시로 공격속도를 완전하게 구현은 불가능한 줄 알았는데... 이것도 머리를 꽁꽁 싸매고 잔머리 막 굴리니까 어떻게든 구현이 됨...

 - 5년전에 만들던 공격속도 구현방식

공격모션의 프레임이 5틱마다 넘어간다고 할 때, 공격속도(1~4)의 변수 값만큼 틱을 뺌. 이 방식은 메이플처럼 공격속도를 단계식으로 구현하는 방식으론 채택할만은 한데 던파처럼 %값만큼 오르게는 못함.

 - 그래서 현재 채용한 공격속도 구현방식

공격모션의 프레임이 5틱마다 넘어간다고 할 때, 틱을 1에서 추가로 공격속도/100만큼을 더 뺀다. 공격속도가 70%라면 틱은 1이 아니라 1+0.7=1.7의 값만큼 계산된다. 초과된 틱은 다음 모션의 틱에서 추가로 뺀다. (예를들어 1.7씩 틱이 깎이다 보면 5.1이 되어서 잉여 값이 남아버리는데 다음 모션에서 이 값을 추가로 빼줘서 다음 모션은 4.9틱 후에 넘어가는 식으로) 이러면 공격속도를 %만큼 온전히 구현할 수 있다....

5. 그리고 은근 어려웠던 것 >> Hp, Mp_Bar와 같이 동그란 모양의 Bar는 Scale값을 조절하면 타원형이 돼서 평범한 사각형 모양의 Bar처럼 Scale로 날먹처리를 할 수가 없었다. 머리 꽁꽁 싸매다가 Layer Mask로 이미지를 덮는 방식을 채용했다. (이거 말곤 답이 없는듯?)

(네모칸에 닿은 이미지만 보임. 100 프레임으로 나눠서 Hp를 백분율로 나눴을 때, 해당 프레임으로 가도록 설정.)

5개만 말했지만 이 외에도 이것저것 공부가 정말 많이 되었다. 일단 안 쓰는 엔진으로 게임 만들었다고 시간낭비한 기분은 안 들었다.

아무리 플래시가 망했다곤 하지만 이런거 알아두면 나중에 다른 게임엔진에서도 잘 써먹을 수 있을듯. 

최근엔 유니티를 공부해 봤는데, 너무 쉬워서 좀 허무한 느낌도 받았다. 아니면 초반단계라 쉬운 건가?

당연한거지만 유니티가 기능면에서 압도적으로 좋다. 렉도 압도적으로 적다.

이제 플래시는 보내줄 때 인가보다...