02/29 본캠프 #46

guno park·2024년 2월 29일
0

본캠프

목록 보기
46/77

팀 프로젝트 - Fez OnlyUp 만들기

넉백 만들기

트러블 슈팅

문제 상황 : 일정 방향에서 넉백 방향이 이상하게 잡힘(밀리는게 아니라 딸려감)

문제 원인 : 넉백 벡터에 메인 카메라의 right를 받아 넣어줬는데, 이 방향이 -1일 때가 있어서 벡터가 뒤집어지는 현상이 발생했음. 그리고 X,Z축 이동을 Camera.right.x == 0일 때로 작성했는데, 실제 값이 0이 아니여서 축 보정이 제대로 되지 않았음.

문제 해결 :
1. 넉백 방향이 뒤집어지는 현상 수정
카메라의 right의 값은 사실 x축이동인지, z축 이동인지 분류하기 위해 사용할 뿐, 실제 넉백 방향은 이미 정해져있어서 절대값만 사용하면 된다고 판단.

Vector3 cameraRightabs = mainCamera.transform.right.Abs(); 
  1. 축 보정이 제대로 되지 않는 문제 수정
    1) Approximately 사용 - x가 0일 때를 생각해 근사치를 구해 보려고 하였으나, x값이 너무 작아지면 메서드에서 제대로 분류하지 못함.

2) x와 z의 값을 비교 - 축 이동을 할 때 해당하는 축은 1, 나머지는 0에 가까운 값이기 때문에 x>z라면 x축이동, 아니라면 z축 이동으로 판별하여 넉백을 규정했음.

if (cameraRightabs.x > cameraRightabs.z)
	{
    knockbackDir = ((knockback.x * cameraRightabs) + knockback.y * Vector3.up) * knockbackPower;
    }
    else
    {
    knockbackDir = ((knockback.z * cameraRightabs) + knockback.y * Vector3.up) * knockbackPower;
    }

프로젝트 설계 시 생각해볼 것

  1. 상수 사용 - 고정 문자열의 사용을 피하기 위해 상수를 이용. 상수들을 모아둔 클래스를 만들어두면 유용
    각 파트에 맞춰서 묶어두면 편함.

  2. 수동 Release - 씬 전환시에도 유지되는 인스턴스는 수동 릴리즈 기능을 만들어두면 활용도가 높다.
    리소스의 해제가 따로 필요한 것들을 할때 using /using은 한 스코프에서 사용
    스코프 : 이 메서드가 동작할 지점을 얘기하는 것 같음.
    그래서 using의 경우 한 스코프 내에서 이뤄진다. 라고 말할 수 있는데, Manager 같은 경우 어느 스코프에서 Release를 한다고 명확하게 정할 수 없기때문에 수동으로 Release 해주는 편

  3. Scene 관리 지금 씬 정보와 이전 씬 정보를 알고 있다면 작업에 편리하다.
    씬 기능에 Enter와 Exit를 관리하는 지점이 있으면 전환 시 흐름 제어가 용이하다.

  4. 로직에서 고정값 제거 - 실제 로직에서 고정된 값으로 설정하는 것보다 변수를 이용하여 구현하면 테스트에 용이하고, 특히 스피드, 타이밍 등의 데이터는 직접 확인을 해야 정이 쉬운 경우가 많다.

  5. UI 코드에 로직 X - UI 스크립트에서 로직이나 데이터를 저장하는 건 좋지 않음
    1) UI코드가 많아진다. 2) UI에 기능이 종속된다. 3)UI는 언제든 파괴될 수 있다.
    실제 로직이 동작할 컨트롤러/매니저/시스템 등을 만들어서 사용.

0 이외의 값을 기본값으로 할 때는 상수에 미리 정의한다.

  1. MVC 구조 - Model(데이터) View(UI) Controller(Manager/Controller/System)

  2. UI Manager - UI Manager에 각 Ui를 하나하나 변수로 들고 있는 ㅓㅅ은 X
    List / Dictionary 등 컬렉션을 이용한 구조를 고려하는게 좋다. UI를 닫을 때 비활성화 하는 방법과 파괴하는 방법에 대해 고민해 볼 수 있음
    UI 비활성화가 최적화에는 도움은 된다. 하지만 임시로 된건지 아예 닫기위해 비활성화 하는지 경계가 모호해진다.

UI 파괴의 경우 최적화에 좋지는 않지만 현대 기기의 스펙이 좋기때문에 영향이 많이 가지는 않는다.
다만 게임의 규모를 고려하여 사용해야한다.

  1. 프리팹 구조 - 프리팹 루트에 모델링/이미지 적용 X 빈 게임오브젝트를 권장, 모델링에 컴포넌트를 추가하여 만들면 모델링이 변경될 때 다시 수정해주어야하기때문.
    root는 빈 오브젝트를 기준으로 컴포넌트를 추가 (Collider / RigidBody / Character Controller 등 실질적으로 활용에 필요한 컴포넌트는 root에 넣는다.
    이렇게 하면 모델링과 데이터만 바꾸면 새로운 프리팹을 찍어낼수 있다.

  2. 동적 로딩 - Scene에 오브젝트를 미리 올려두는 경우
    1) 로딩하는데 오래 걸림.
    2) 필요없는 데이터도 우선 로딩
    3) 준비된 오브젝트간의 초기화 순서를 지정하는게 힘듬
    4) 여러 씬을 올릴 때 순간 메모리 부족 (웹을 생각한다면 메모리 부족 시 취약

씬 메모리 전략
1) 씬에 데이터를 올리지 않고 필요할 때 로드해서 활용
2) 로딩 씬을 활용

  1. 데이터 설정 - 데이터를 설정하는 것으로 초기화 할 수 있도록 설계
    국내 게임업계의 절대 다수는 모바일 게임 -> API를 이용한 서버 사용 -> 멀티플레이를 고려

1) 서버를 사용하는 외부에 있는 데이터를 불러와서 설정하는 경우가 많음
2) 멀티플레이의 경우 다른 유저의 정보를 넘겨서 아바타를 생성할때도 유리
3) DM의 데이터로 프리팹 세팅할 때도 편리

  1. 오브젝트 접근
    서로 다른 클래스에서 접근이 필요한 경우 직접 접근은 권장 X, 매니저를 통해 할당하면 편함.

  2. 변수 타입 - 변수를 선언 할 때 다 GameObject로 선언 X
    가장 주로 사용될 타입으로 설정

GameObject =>
1)활성화/비활성화가주 목적일 때
2)그 외에 특별한 기능을 활용하지 않을때는 기본값으로 좋음

Transform =>
1)위치/회전/크기 조정
2) 부모/자식 계층 관리

0개의 댓글