반응형

ECS란?

Entity, Component, System의 약자로써

Entity와 Component와 System에 대한 역할 분리를 철저히 한 설계 방식이다.

 

내가 이해한 바를 적어보자면,


Entity : 객체를 Entity의 id, key 등으로 분류하여 매핑시켜 Coponent와 System을 연결해주는 객체

Component : 역할에 필요한 "데이터, 즉 변수"만 가지고 있는 객체

System :  Component의 데이터를 기반으로 실제 역할에 필요한 행위를 하는 객체


라고 이해하였다.

하지만 이건 개념일 뿐이고, ECS를 사용하는 이유는 간단하다.

바로 선형적 데이터 구조를 통해 캐시친화율을 극단적으로 올려 성능 향상을 꾀하는 것이 목표다.

그러기 위해서 주의해야 할 점이 있다.

첫 번쨰.

간혹 ecs를 검색해보면, unordered_map을 사용하는데, 이것이 과연 캐시친화적 설계인가? 하는 의문이 든다. 매핑의 기본은 해시맵에서 시작한다지만 과연 캐시친화적 설계에 해시맵이 적절한지 고려해볼 필요가 있다. 최대한 선형적 데이터구조를 띄는 설계를 해야하지 않을까? 

두 번째,

 

 

내가 생각하는 최적화 기법

1. Entity의 컴포넌트 배열을 bit_set을 사용한다.

2. 

반응형
반응형

애니메이션

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

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

pose구성도

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

Pose Controller 구성도

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

Animator Component 구성

 

반응형
반응형

유피의 소원


소개

장르 2D 횡스크롤 액션 플랫포머
작업 기간 2주
작업 인원 4명
언어 C++
사용 라이브러리 WinAPI, GDI+, FMOD

게임인재원 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자료형을 출력하기가 어려워서 끙끙 싸매다가 버그가 줄줄이 터져서 그냥 포기했다.....

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

반응형

+ Recent posts