Unity 개발자가 저지르는 가장 일반적인 실수 10가지

Unity는 멀티 플랫폼 개발에 사용할 수 있는 훌륭하고 간단한 도구입니다. 원리는 이해하기 쉽고 직관적으로 제품을 만들 수 있습니다. 그러나 몇 가지 사항을 염두에 두지 않으면 초기 프로토타입 단계에서 이동하거나 최종 릴리스에 가까워지기 때문에 다음 단계로 작업을 진행할 때 진행 속도가 느려집니다. 이 기사는 가장 일반적인 문제를 극복하는 방법과 신규 또는 기존 프로젝트에서 근본적인 실수를 피하는 방법에 대한 조언을 제공합니다. 이 기사의 관점은 3D 응용 프로그램 개발에 더 초점을 맞추고 있지만 언급된 모든 내용은 2D 개발에도 적용할 수 있습니다.

일반적인 Unity 실수 #1: 프로젝트 계획 단계를 과소평가

모든 프로젝트에 대해 프로젝트의 애플리케이션 설계 및 프로그래밍 부분이 시작되기 전에 몇 가지 사항을 결정하는 것이 중요합니다. 제품 마케팅이 전체 프로세스의 중요한 부분인 요즘에는 구현된 애플리케이션의 비즈니스 모델이 무엇인지에 대한 명확한 아이디어를 갖는 것도 중요합니다. 제품을 출시할 플랫폼과 계획에 포함된 플랫폼을 확인해야 합니다. 또한 최소한의 지원 장치 사양(구형 저가형 장치를 지원할 것인지 아니면 최신 모델을 지원할 것인지)을 설정하여 감당할 수 있는 성능과 시각적 효과를 파악해야 합니다. 이 기사의 모든 주제는 이 사실의 영향을 받습니다.

보다 기술적인 관점에서 보면 자산과 모델을 생성하는 전체 워크플로를 미리 설정하는 동시에 프로그래머에게 제공하는 동시에 모델에 더 많은 변경과 개선이 필요할 때 반복 프로세스에 특히 주의해야 합니다. 원하는 프레임 속도와 정점 예산에 대한 명확한 아이디어가 있어야 3D 아티스트가 모델이 있어야 하는 최대 해상도와 그가 수행해야 하는 LOD 변형 수를 알 수 있습니다. 또한 일관된 규모를 갖도록 모든 측정을 통합하는 방법과 전체 응용 프로그램에 걸쳐 프로세스를 가져오는 방법을 지정해야 합니다.

레벨의 구분이 성능에 많은 영향을 미치기 때문에 레벨을 설계하는 방식은 향후 작업에 매우 중요합니다. 새로운 레벨을 설계할 때는 성능 문제를 항상 염두에 두어야 합니다. 비현실적인 비전을 가지지 마십시오. "그것이 합리적으로 달성될 수 있는가?"라는 질문을 스스로에게 하는 것이 항상 중요합니다. 그렇지 않다면 거의 달성할 수 없는 일에 귀중한 자원을 낭비해서는 안 됩니다(물론 이를 주요 경쟁 우위로 삼는 것이 비즈니스 전략의 일부가 아닌 경우).

일반적인 Unity 실수 #2: 최적화되지 않은 모델 작업

추가 수정 없이 장면에서 사용할 수 있도록 모든 모델을 잘 준비하는 것이 중요합니다. 좋은 모델이 충족해야 할 몇 가지 사항이 있습니다.

눈금을 올바르게 설정하는 것이 중요합니다. 때로는 이러한 응용 프로그램이 사용하는 다른 단위로 인해 3D 모델링 소프트웨어에서 이것을 올바르게 설정하는 것이 불가능합니다. 모든 것을 올바르게 하려면 모델 가져오기 설정에서 축척 비율을 설정하고(3dsMax 및 Modo의 경우 0.01, Maya의 경우 1.0으로 설정) 축척 설정을 변경한 후 개체를 다시 가져와야 하는 경우가 있습니다. 이러한 설정을 사용하면 장면에서 기본 스케일 1,1,1만 사용하여 일관된 동작을 얻고 물리적 문제가 없도록 할 수 있습니다. 동적 일괄 처리도 올바르게 작동할 가능성이 높습니다. 이 규칙은 기본 개체뿐만 아니라 모델의 모든 하위 개체에도 적용되어야 합니다. 개체 치수를 조정해야 하는 경우 Unity가 아닌 3D 모델링 응용 프로그램에서 다른 개체와 관련하여 수행하십시오. 그러나 Unity에서 스케일을 실험하여 적절한 값을 찾을 수 있지만 최종 애플리케이션과 일관된 워크플로를 위해서는 Unity로 가져오기 전에 모든 것을 잘 준비하는 것이 좋습니다.

개체의 기능 및 동적 부분과 관련하여 - 모델을 잘 분할하십시오. 하위 개체가 적을수록 좋습니다. 애니메이션 목적 또는 기타 상호 작용을 위해 동적으로 이동하거나 회전하는 경우와 같이 필요한 경우에 대비하여 개체의 부분을 분리합니다. 모든 개체와 해당 하위 개체의 피벗이 기본 기능과 관련하여 적절하게 정렬되고 회전되어야 합니다. 메인 오브젝트는 앞쪽을 가리키는 Z축이 있어야 하고 장면에 더 잘 배치되도록 피벗이 오브젝트의 맨 아래에 있어야 합니다. 물체에 가능한 한 적은 수의 재료를 사용하십시오(자세한 내용은 아래 참조).

모든 자산에는 유형과 기능을 쉽게 설명할 수 있는 고유한 이름이 있어야 합니다. 모든 프로젝트에서 이 일관성을 유지하십시오.

일반적인 Unity 실수 #3: 상호 의존적 코드 아키텍처 구축

Unity에서 기능의 프로토타이핑 및 구현은 매우 쉽습니다. 다른 개체에 대한 참조를 쉽게 끌어다 놓을 수 있고 장면의 모든 단일 개체에 주소를 지정하고 포함된 모든 구성 요소에 액세스할 수 있습니다. 그러나 이것은 잠재적으로 위험할 수도 있습니다. 눈에 띄는 성능 문제(계층 구조에서 개체를 찾고 구성 요소에 액세스하는 데 오버헤드가 있음) 외에도 코드의 일부를 서로 완전히 종속시키는 데는 큰 위험이 있습니다. 또는 응용 프로그램에 고유한 다른 시스템 및 스크립트 또는 현재 장면 또는 현재 시나리오에 종속됩니다. 보다 모듈화된 접근 방식을 취하고 애플리케이션의 다른 부분에서 사용하거나 전체 애플리케이션 포트폴리오에서 공유할 수 있는 재사용 가능한 부품을 만드십시오. 지식 기반을 구축하는 것과 동일한 방식으로 Unity API를 기반으로 프레임워크와 라이브러리를 구축하세요.

이를 보장하기 위한 다양한 접근 방식이 있습니다. 좋은 출발점은 Unity 구성 요소 시스템 자체입니다. 특정 구성 요소가 응용 프로그램의 다른 시스템과 통신해야 할 때 합병증이 나타날 수 있습니다. 이를 위해 인터페이스를 사용하여 시스템의 일부를 보다 추상적이고 재사용 가능하게 만들 수 있습니다. 또는 메시징 시스템을 생성하거나 다른 시스템의 일부에 리스너로 직접 등록하여 범위 외부의 특정 이벤트에 반응하는 이벤트 기반 접근 방식을 사용할 수 있습니다. 올바른 접근 방식은 위치 및 회전과 같은 변환 속성을 수정하는 개체를 식별하기 어렵기 때문에 프로그램 논리(적어도 모델 컨트롤러 원칙과 같은 것)에서 게임 개체 속성을 분리하려고 시도하는 것입니다. 이는 전적으로 해당 컨트롤러의 책임이어야 합니다.

모든 것을 잘 문서화하도록 노력하십시오. 오랜 시간이 지난 후 코드로 돌아가야 하는 것처럼 항상 처리하고 코드의 이 부분이 정확히 무엇을 하는지 빠르게 이해해야 합니다. 실제로 일정 시간이 지나면 응용 프로그램의 일부에 도달하는 경우가 매우 많으며 문제에 빠르게 뛰어드는 데 불필요한 장애물이 되기 때문입니다. 그러나 이것을 과용하지 마십시오. 때로는 적절한 클래스, 메서드 또는 속성 이름으로 충분합니다.

일반적인 Unity 실수 #4: 성능 낭비

휴대폰, 콘솔 또는 데스크톱 컴퓨터의 최신 제품 라인은 성능에 대해 신경 쓸 필요가 없을 정도로 발전되지 않을 것입니다. 성능 최적화는 항상 필요하며 시장에 나와 있는 다른 것과 비교하여 게임이나 애플리케이션이 어떻게 보이는지 차이를 만드는 토대를 제공합니다. 한 부분의 성능을 절약하면 응용 프로그램의 다른 부분을 다듬는 데 사용할 수 있기 때문입니다.

최적화를 위한 영역이 많이 있습니다. 이 주제에 대한 표면을 긁는 데에만 전체 기사가 필요할 것입니다. 적어도 이 영역을 몇 가지 핵심 영역으로 나누려고 노력할 것입니다.

루프 업데이트

업데이트 루프에서 성능 집약적인 것을 사용하지 말고 대신 캐싱을 사용하십시오. 일반적인 예는 장면의 구성 요소 또는 기타 개체에 대한 액세스 또는 스크립트의 집중적인 계산입니다. 가능하면 Awake() 메서드에서 모든 것을 캐시하거나 아키텍처를 이벤트 중심 접근 방식으로 변경하여 필요할 때 트리거합니다.

인스턴스화

꽤 자주 인스턴스화되는 개체(예: FPS 게임의 총알)의 경우 미리 초기화된 풀을 만들고 필요할 때 이미 초기화된 개체를 선택하여 활성화합니다. 그런 다음 더 이상 필요하지 않을 때 폐기하는 대신 비활성화하고 풀로 반환합니다.

표현

오클루전 컬링 또는 LOD 기술을 사용하여 장면의 렌더링된 부분을 제한합니다. 장면의 정점 수를 제어할 수 있도록 최적화된 모델을 사용하십시오. 정점 수는 모델 자체의 정점 수가 아니라 법선(단단한 가장자리), UV 좌표(UV 솔기) 및 정점 색상과 같은 다른 것들의 영향을 받습니다. 또한 장면의 여러 동적 조명이 전체 성능에 큰 영향을 미치므로 가능한 한 미리 모든 것을 굽도록 하십시오.

통화 그리기

드로우 콜 수를 줄이십시오. Unity에서는 정지된 개체에 대해 정적 일괄 처리를 사용하고 움직이는 개체에 대해 동적 일괄 처리를 사용하여 그리기 호출을 줄일 수 있습니다. 그러나 먼저 장면과 모델을 준비해야 하며(배치된 개체는 동일한 재료를 공유해야 함) 동적 개체의 일괄 처리는 저해상도 모델에서만 작동합니다. 또는 일괄 처리를 사용하는 대신 스크립트에 의해 메시를 하나로 결합할 수 있지만( Mesh.CombineMeshes ) 일부 플랫폼에서 보기 절두체 컬링을 활용할 수 없는 너무 큰 개체를 생성하지 않도록 주의해야 합니다. 일반적으로 핵심은 가능한 한 적은 재료를 사용하고 장면 전체에서 공유하는 것입니다. 별개의 개체 간에 하나의 재료를 공유할 수 있도록 텍스처에서 아틀라스를 만들어야 하는 경우가 있습니다. 좋은 팁은 더 큰 환경에서 라이트를 베이킹할 때 더 높은 해상도의 장면 라이트맵 텍스처(생성된 해상도가 아니라 텍스처 출력 해상도)를 사용하여 숫자를 낮추는 것입니다.

오버드로 문제

필 레이트 문제를 일으킬 수 있으므로 필요하지 않은 경우 투명 텍스처를 사용하지 마십시오. 나무나 덤불과 같이 복잡하고 더 먼 형상에 사용하는 것이 좋습니다. 사용해야 하는 경우 알파 테스트가 포함된 셰이더 또는 모바일 플랫폼용 컷아웃 셰이더 대신 알파 혼합 셰이더를 선호합니다. 일반적으로 이러한 문제를 식별하려면 응용 프로그램의 해상도를 낮추십시오. 도움이 된다면 이러한 필레이트 문제가 있거나 셰이더를 더 최적화해야 할 수 있습니다. 그렇지 않으면 더 많은 메모리 문제가 될 수 있습니다.

셰이더

더 나은 성능을 위해 셰이더를 최적화하십시오. 패스 수를 줄이고, 정밀도가 낮은 변수를 사용하고, 복잡한 수학 계산을 미리 생성된 조회 텍스처로 대체합니다.

병목 현상을 확인하려면 항상 프로파일러를 사용하십시오. 훌륭한 도구입니다. 렌더링을 위해 멋진 프레임 디버거를 사용할 수도 있습니다. 이는 렌더링 프로세스를 분해할 때 일반적으로 작동하는 방식에 대해 많은 것을 배우는 데 도움이 됩니다.

일반적인 Unity 실수 #5: 가비지 컬렉션 문제 무시

가비지 컬렉터(GC) 자체가 우리가 프로그래밍에서 정말 효율적이고 중요한 것에 집중하도록 도와준다는 사실에도 불구하고 명시적으로 알고 있어야 하는 몇 가지 사항이 있다는 사실을 깨달을 필요가 있습니다. GC 사용은 무료가 아닙니다. 일반적으로 GC가 너무 자주 실행되어 프레임 속도 급증으로 인해 성능이 저하되는 것을 방지하기 위해 불필요한 메모리 할당을 피해야 합니다. 이상적으로는 매 프레임마다 정기적으로 발생하는 새로운 메모리 할당이 전혀 없어야 합니다. 그러나 어떻게 이 목표를 달성할 수 있습니까? 실제로 애플리케이션 아키텍처에 의해 결정되지만 다음과 같은 도움이 되는 몇 가지 규칙을 따를 수 있습니다.

• 업데이트 루프에서 불필요한 할당을 피하십시오.
• 힙에 할당되지 않으므로 간단한 속성 컨테이너에 구조체를 사용합니다.
• 업데이트 루프 내에서 생성하는 대신 배열, 목록 또는 기타 객체 컬렉션을 미리 할당하십시오.
• Unity가 이상적으로 최적화되지 않은 이전 버전의 Mono를 사용하고 있기 때문에(예를 들어 LINQ 표현식 또는 foreach 루프와 같은) 문제가 있는 모노를 사용하지 마십시오(작성 당시 로드맵에서 업그레이드하여 버전 2.6으로 수정됨).
• Awake() 메서드 또는 이벤트에서 문자열을 캐시합니다.
• 업데이트 루프에서 문자열 속성의 업데이트가 필요한 경우 문자열 대신 StringBuilder 개체를 사용합니다.
• 프로파일러를 사용하여 잠재적인 문제를 식별합니다.

일반적인 Unity 실수 #6: 마지막으로 메모리 및 공간 사용 최적화

출시 전 단계를 위한 최적화를 떠날 때 하는 것이 더 복잡하기 때문에 프로젝트 초기부터 애플리케이션의 최소 메모리 및 공간 사용량에 주의를 기울일 필요가 있습니다. 모바일 장치에서는 리소스가 매우 부족하기 때문에 이것이 훨씬 더 중요합니다. 또한 설치 크기가 100MB를 초과하면 상당한 고객을 잃을 수 있습니다. 이것은 셀룰러 네트워크 다운로드에 대한 100MB 제한 때문이기도 하고 심리적인 이유 때문이기도 합니다. 애플리케이션이 고객의 소중한 전화 리소스를 낭비하지 않을 때 항상 더 좋고 크기가 더 작을 때 앱을 다운로드하거나 구매할 가능성이 더 높아집니다.

리소스 드레이너를 찾기 위해 오디오, 텍스처 및 DLL과 같은 별도의 범주로 나누어진 리소스 크기를 볼 수 있는 편집기 로그를 사용할 수 있습니다. 더 나은 방향성을 위해 Unity 에셋 스토어에 편집기 확장이 있으며, 이는 파일 시스템의 참조 리소스 및 파일에 대한 자세한 요약을 제공합니다. 실제 메모리 소비량은 프로파일러에서도 볼 수 있지만, 에디터나 타겟 플랫폼 이외의 다른 곳에서 테스트할 때 많은 불일치가 있기 때문에 타겟 플랫폼에서 빌드하기 위해 연결했을 때 테스트하는 것이 좋습니다.

가장 큰 메모리 소비자는 종종 텍스처입니다. 공간과 메모리를 훨씬 적게 차지하므로 압축 텍스처를 사용하는 것이 좋습니다. 모든 텍스처를 제곱하고 이상적으로는 양쪽의 길이를 2의 거듭제곱(POT)으로 만들지만 Unity는 NPOT 텍스처를 자동으로 POT으로 확장할 수도 있습니다. 텍스처는 POT 형태일 때 압축될 수 있습니다. 아틀라스 텍스처를 함께 사용하여 전체 텍스처를 채웁니다. 때로는 추가 공간과 성능을 절약하기 위해 셰이더에 대한 몇 가지 추가 정보에 텍스처 알파 채널을 사용할 수도 있습니다. 물론 가능한 한 장면에 텍스처를 재사용하고 좋은 시각적 모양을 유지할 수 있을 때 반복되는 텍스처를 사용합니다. 저사양 기기의 경우 품질 설정에서 텍스처의 해상도를 낮출 수 있습니다. 배경 음악과 같은 더 긴 오디오 클립에는 압축된 오디오 형식을 사용합니다.

다른 플랫폼, 해상도 또는 현지화를 처리할 때 자산 번들을 사용하여 다른 장치 또는 사용자에 대해 다른 텍스처 세트를 사용할 수 있습니다. 이러한 자산 번들은 응용 프로그램이 설치된 후 인터넷에서 동적으로 로드할 수 있습니다. 이런 식으로 게임 중에 리소스를 다운로드하여 100MB 제한을 초과할 수 있습니다.

일반적인 Unity 실수 #7: 일반적인 물리학 실수

때때로 장면에서 개체를 이동할 때 개체에 충돌기가 있고 위치를 변경하면 엔진이 전체 물리적 세계를 다시 계산해야 한다는 사실을 인식하지 못합니다. 이 경우 Rigidbody 구성 요소를 추가해야 합니다(외부 힘이 포함되는 것을 원하지 않으면 비운동학으로 설정할 수 있습니다).

Rigidbody 가 있는 개체의 위치를 ​​수정하려면 새 위치가 이전 위치를 따르지 않을 때 항상 Rigidbody.position 을 설정하고 보간도 고려하는 연속 이동인 경우 Rigidbody.MovePosition 을 설정합니다. 수정할 때 Update 함수가 아닌 FixedUpdate 에서 작업을 항상 적용하십시오. 일관된 물리적 동작을 보장합니다.

가능하다면 메쉬 콜라이더가 아닌 구, 상자 또는 실린더와 같은 게임 오브젝트에 기본 콜라이더를 사용하십시오. 이러한 충돌기 중 하나 이상에서 최종 충돌기를 구성할 수 있습니다. 물리학은 CPU 오버헤드로 인해 애플리케이션의 성능 병목 현상이 될 수 있으며 기본 콜라이더 간의 충돌은 계산 속도가 훨씬 빠릅니다. 물리 상호 작용의 정확성이 그다지 필요하지 않을 때 물리 고정 업데이트의 빈도를 줄이기 위해 시간 관리자에서 고정 시간 단계 설정을 조정할 수도 있습니다.

일반적인 Unity 실수 #8: 모든 기능을 수동으로 테스트하기

때로는 플레이 모드가 매우 재미있고 모든 것을 직접 제어할 수 있기 때문에 플레이 모드에서 실험하여 기능을 수동으로 테스트하는 경향이 있을 수 있습니다. 그러나 이 멋진 요소는 매우 빠르게 감소할 수 있습니다. 응용 프로그램이 복잡해질수록 프로그래머는 응용 프로그램이 원래 의도한 대로 작동하는지 확인하기 위해 반복하고 생각해야 하는 지루한 작업이 늘어납니다. 반복적이고 수동적인 성격 때문에 전체 개발 과정에서 쉽게 최악의 부분이 될 수 있습니다. 또한 테스트 시나리오를 수동으로 반복하는 것은 그다지 재미가 없기 때문에 일부 버그가 전체 테스트 프로세스를 통과할 가능성이 더 높습니다.

Unity에는 이를 자동화할 수 있는 훌륭한 테스트 도구가 있습니다. 적절한 아키텍처 및 코드 디자인을 사용하면 격리된 기능을 테스트하기 위해 단위 테스트를 사용하거나 더 복잡한 시나리오를 테스트하기 위해 통합 테스트를 사용할 수도 있습니다. 실제 데이터를 기록하고 원하는 상태와 비교하는 시도 및 확인 방식을 크게 줄일 수 있습니다.

수동 테스트는 의심할 여지 없이 개발의 중요한 부분입니다. 그러나 그 양을 줄일 수 있으며 전체 프로세스가 더 강력하고 빠를 수 있습니다. 자동화할 수 있는 방법이 없는 경우 최대한 빨리 해결하려는 문제에 들어갈 수 있도록 테스트 장면을 준비하세요. 이상적으로는 재생 버튼을 누른 후 몇 프레임입니다. 테스트를 위해 원하는 상태를 설정하기 위해 바로 가기 또는 치트를 구현하십시오. 또한 테스트 상황을 격리하여 문제의 원인을 확인하십시오. 테스트할 때 플레이 모드에서 불필요한 모든 시간이 누적되고 문제 테스트의 초기 편향이 클수록 문제를 전혀 테스트하지 않을 가능성이 높아지고 모든 것이 잘 작동하기를 바랍니다. 하지만 아마 그렇지 않을 것입니다.

일반적인 Unity 실수 #9: Unity 에셋 스토어 플러그인이 모든 문제를 해결할 것이라고 생각

날 믿어; 그들은하지 않습니다. 일부 클라이언트와 작업할 때 작은 모든 것에 에셋 스토어 플러그인을 사용하는 경향이나 과거의 유물에 가끔 직면했습니다. Unity 에셋 스토어에 유용한 Unity 확장이 없다는 의미는 아닙니다. 그들 중 많은 수가 있으며 때로는 어떤 것을 선택해야 할지 결정하기조차 어렵습니다. 그러나 모든 프로젝트에 대해 일관성을 유지하는 것이 중요합니다. 서로 잘 맞지 않는 다른 부분을 현명하지 않게 사용하면 파괴될 수 있습니다.

반면에 구현하는 데 시간이 오래 걸리는 기능의 경우 Unity 에셋 스토어에서 테스트를 거친 제품을 사용하는 것이 항상 유용하므로 개발 시간을 크게 절약할 수 있습니다. 그러나 신중하게 선택하고 최종 제품에 제어할 수 없고 이상한 버그를 많이 가져오지 않는 입증된 것을 사용하십시오. 별점 5개 리뷰는 시작하기에 좋은 척도입니다.

원하는 기능을 구현하는 것이 어렵지 않은 경우 지속적으로 증가하는 개인(또는 회사) 라이브러리에 추가하면 나중에 모든 프로젝트에서 다시 사용할 수 있습니다. 그렇게 하면 지식과 도구 세트를 동시에 향상시킬 수 있습니다.

일반적인 Unity 실수 #10: Unity 기본 기능을 확장할 필요가 없음

때로는 Unity 에디터 환경이 기본적인 게임 테스팅과 레벨 디자인에 충분해 보이고 확장하는 것은 시간낭비인 것처럼 보일 수 있습니다. 그러나 저를 믿으십시오. 그렇지 않습니다. Unity의 뛰어난 확장 가능성은 다양한 프로젝트에서 해결해야 하는 특정 문제에 Unity를 적용할 수 있다는 점에서 나옵니다. 이를 통해 Unity에서 작업할 때 사용자 경험을 개선하거나 전체 개발 및 레벨 디자인 워크플로의 속도를 크게 높일 수 있습니다. 빌트인 또는 커스텀 프로퍼티 드로어, 데코레이터 드로어, 커스텀 컴포넌트 인스펙터 설정과 같은 빌트인 기능을 사용하지 않거나 자체 에디터 윈도우로 전체 플러그인을 빌드하지 않는 것은 불행한 일입니다.

결론

Unity 프로젝트를 진행하는 데 이 주제가 유용하기를 바랍니다. 프로젝트에 특정한 것들이 많아서 적용할 수 없지만 더 어렵고 구체적인 문제를 풀려고 할 때 몇 가지 기본 규칙을 염두에 두는 것이 항상 유용합니다. 프로젝트에서 이러한 문제를 해결하는 방법에 대해 다른 의견이나 절차가 있을 수 있습니다. 가장 중요한 것은 프로젝트 전체에서 관용구를 일관되게 유지하여 팀의 모든 사람이 특정 도메인이 올바르게 해결되어야 하는 방법을 명확하게 이해할 수 있도록 하는 것입니다.

Toptal 엔지니어링 블로그에 대한 추가 정보:

• Unity AI 개발: 유한 상태 머신 튜토리얼