지혜공방(Wisdom Atelier)

요약: 이 페이지는 에셋의 내용물을 설명합니다.

에셋에 무엇이 들어 있나요?

에셋에는 6개의 주요 폴더가 포함되어 있습니다:

• FeelDemos는 각기 독립된 폴더와 하위 폴더에 포함된 여러 데모를 포함하는 폴더입니다. 이 데모들은 Feel의 다양한 기능을 보여줍니다. 자세한 내용은 문서의 데모 섹션에서 확인할 수 있습니다.
• FeelDemosHDRP는 고해상도 렌더 파이프라인(High Definition Render Pipeline)에 특화된 데모를 포함합니다. 이러한 데모를 실행하려면 HDRP 프로젝트에 Feel을 가져와야 합니다.
• FeelDemosURP는 범용 렌더 파이프라인(Universal Render Pipeline)에 특화된 데모를 포함합니다. 이러한 데모를 실행하려면 URP 프로젝트에 Feel을 가져와야 합니다.
• MMFeedbacks는 에셋의 주요 부분입니다. 피드백 시스템, 모든 피드백 및 데모 씬이 포함되어 있습니다. 피드백을 사용하려면 반드시 이 폴더를 유지해야 합니다. 내부의 데모 폴더는 안전하게 제거할 수 있습니다.
• MMTools: MMTools는 다양한 유용한 도구가 포함된 멋진 라이브러리로, 에셋에 포함시키면 좋을 것 같아서 추가했습니다. 주저하지 말고 살펴보세요. 놀라운 것들이 가득합니다!
• NiceVibrations: Feel에 포함된 선물로, Nice Vibrations는 iOS 또는 Android 게임에 햅틱 피드백을 추가하는 최고의 방법입니다. 전용 웹사이트에서 더 많은 정보를 확인할 수 있습니다.

물건을 제거하고 싶다면 어떻게 하나요?

빌드 로그에서 볼 수 있듯이(Feel 4.0.1의 PC 빌드, MMF Player가 포함된 빈 씬 기준), Feel은 이미 매우 낮은 영향을 미치며, 프로젝트에 추가해도 빌드 크기에 몇 KB의 스크립트만 추가됩니다. Unity는 기본적으로 빌드 크기 최적화에 매우 뛰어나며, 사용한 것만 빌드에 포함시킵니다. 따라서 Feel에서 항목을 제거해도 얻을 수 있는 이점은 많지 않습니다. 유일한 이점은 프로젝트의 크기를 줄이는 것이지만(빌드 크기가 아닌), 몇 MB의 데모로 저장소 용량이 최대치에 도달하지는 않을 것입니다. 또한 컴파일 시간이나 기타 다른 부분에도 큰 영향을 미치지 않습니다. Feel의 모든 항목은 어셈블리 정의에 깔끔하게 정리되어 있기 때문입니다. 그러나 원한다면 항목을 제거할 수도 있습니다. 삭제한 항목은 잃게 되겠지만, 이는 여러분의 프로젝트이며 여러분의 규칙입니다.

다시 말하지만, 권장하거나 필요한 것은 아니지만, 만약 그렇게 하기로 결정한다면:

데모:

• 전체 Feel/FeelDemos 폴더를 안전하게 제거할 수 있습니다 (데모에 대한 쉬운 접근을 잃게 됩니다).
• 전체 Feel/FeelDemosURP 폴더를 안전하게 제거할 수 있습니다 (URP 데모에 대한 쉬운 접근을 잃게 됩니다).
• 전체 Feel/FeelDemosHDRP 폴더를 안전하게 제거할 수 있습니다 (HDRP 데모에 대한 쉬운 접근을 잃게 됩니다).
• 전체 Feel/MMFeedbacks/Demos 폴더를 안전하게 제거할 수 있습니다 (MMFeedbacks 데모에 대한 접근을 잃게 됩니다).
• 전체 Feel/MMTools/Demos 폴더를 안전하게 제거할 수 있습니다 (MMTools 데모에 대한 접근을 잃게 됩니다).
• 중요: 대부분의 Feel 데모(URP/HDRP 데모 포함)는 FeelDemos/_Common/ 폴더에 의존하므로, 일부 데모를 삭제하되 예를 들어 URP 데모를 유지하려면 해당 폴더도 유지해야 합니다.
  
  

선택적 라이브러리:

• Feel/NiceVibrations 폴더를 제거할 수 있습니다. 이 경우 Project Settings > Player로 이동하여  MOREMOUNTAINS_NICEVIBRATIONS_INSTALLED 스크립팅 정의 심볼을 제거하고(변경 사항을 적용), Nice Vibrations 및 관련 피드백에 대한 접근을 잃게 됩니다.
• Feel/MMFeedbacks/MMFeedbacksForThirdParties 폴더(또는 그 일부)를 제거할 수 있습니다. 이 경우 해당 폴더에 포함된 피드백에 대한 접근을 잃게 됩니다.

MMTools:

MMTools 폴더 내에는 4개의 주요 폴더가 있습니다: Accessories, Core, Demos, Foundation.

• MMTools/Demos 폴더를 안전하게 제거할 수 있습니다. 이 경우 다양한 데모에 대한 접근을 잃게 되지만, 모두 선택 사항입니다.
• MMTools/Accessories 폴더를 안전하게 제거할 수 있습니다. 이 경우 많은 헬퍼 도구에 대한 접근을 잃게 되지만, 피드백에는 영향을 미치지 않습니다.
• MMTools/Foundation 폴더를 안전하게 제거할 수 있습니다. 이 경우 도구에 대한 접근을 잃게 되지만, 피드백에는 영향을 미치지 않습니다.
• 이론적으로 MMTools/Core 폴더를 제거할 수 있지만, 이는 오류를 발생시키지 않지만 피드백 시스템의 많은 핵심 기능을 잃게 됩니다.

요약: 이 페이지는 Feel에서 렌더 파이프라인이 어떻게 작동하는지 설명합니다.

소개

몇 년 전 Unity는 SRP(Scriptable Render Pipelines) 개념을 도입했습니다. 이를 좋아하는 사람도 있고 싫어하는 사람도 있지만, 이제는 SRP가 정착될 가능성이 큽니다. Feel은 모든 렌더 파이프라인에서 작동하며, URP나 HDRP 프로젝트에 Feel을 가져올 수 있습니다.

이 규칙의 두 가지 예외가 있습니다:

• 데모
• 포스트 프로세싱 피드백

데모와 렌더 파이프라인

Unity가 렌더 파이프라인을 분리하기로 결정하면서, 모든 렌더 파이프라인에서 작동하는 데모를 제공하는 것이 불가능해졌습니다. 기술적으로 모든 데모를 세 번씩 복제하는 것(하나는 Standard, 하나는 URP, 하나는 HDRP)은 가능하지만, 이는 자산의 크기를 세 배로 늘리고 유지보수를 매우 어렵게 만듭니다. 그래서 대부분의 데모는 Built-in RP를 사용합니다. Built-in RP는 여전히 가장 널리 사용되는 렌더 파이프라인이며, 2022년 기준으로 70% 이상의 프로젝트가 Built-in RP를 사용하여 제작되었습니다. URP/HDRP/CustomRP 프로젝트에서 대부분의 데모를 열면 많은 재질이 누락되거나 깨질 가능성이 큽니다. Unity가 표준 재질을 URP로 변환할 수 있지만, 이는 완벽하지 않아서 모든 재질이 제대로 작동하지는 않을 것입니다.

표준이 아닌 RP에서 Feel을 사용하려고 하지만 여전히 데모를 확인하고 싶다면, 가장 쉬운 해결책은 프로젝트에 Feel을 추가하고 데모를 확인하기 위해 표준 RP 프로젝트를 만드는 것입니다.

포스트 트로세싱

Feel의 대부분의 시스템은 사용 중인 렌더 파이프라인과 완전히 독립적이지만, 일부 피드백은 포스트 프로세싱을 타겟으로 하며, 이는 렌더 파이프라인마다 다릅니다. Unity에는 3가지 주요 포스트 프로세싱 시스템이 있습니다(깊은 한숨):

• 표준 RP용 포스트 프로세싱(패키지 매니저를 통해 설치해야 하는 별도 패키지)
• URP용 URP 볼륨
• HDRP용 HDRP 볼륨

버전 2.3부터는 HDRP와 URP 볼륨에 대한 특정 피드백을 보여주는 전용 HDRP 및 URP 데모가 제공됩니다(문서의 전용 섹션 참조). 물론 해당 데모는 각 렌더 파이프라인에 맞는 프로젝트에서 사용해야 합니다.

설치 지침

Optional Steps

참고로, 4, 5, 6, 7 단계는 선택 사항이지만, 포스트 프로세싱, TextMesh Pro 및 Cinemachine 피드백에 접근하려면 해당 패키지가 필요합니다. 또한 대부분의 Feel 데모는 가능한 많은 피드백을 사용하며, 이러한 종속성 대부분을 포함합니다. 해당 종속성을 설치하지 않으면 오류가 발생할 수 있습니다.

URP 및 HDRP

Feel은 모든 렌더 파이프라인에서 작동하며, URP 또는 HDRP 프로젝트에 Feel을 가져올 수 있습니다. 다만, 대부분의 데모는 표준 렌더 파이프라인(Standard RP)을 사용하여 제작되었으므로 다른 파이프라인을 사용하는 프로젝트에서 열 때 올바르게 렌더링되지 않을 수 있습니다. 그리고 URP나 HDRP에서는 포스트 프로세싱 패키지를 설치할 필요가 없습니다. 이들은 자체 포스트 프로세싱 볼륨 시스템을 함께 제공합니다.

버전 2.3부터는 전용 HDRP 및 URP 데모가 제공됩니다(문서의 전용 섹션 참조). 물론 해당 파이프라인과 일치하는 프로젝트에 설치해야 합니다.

일부 제 재질이 모두 분홍색으로 표시됩니다! 엔진의 데모에서 사용되는 대부분의 재질은 모든 렌더 파이프라인(RP)에서 잘 표시되지만, NewCorgi3D와 같은 몇몇 데모는 커스텀 셰이더를 사용하며, 이 셰이더들은 HDRP 또는 URP에서 깨질 수 있습니다. 다행히도, 이를 비교적 쉽게 변환할 수 있습니다. 다음과 같이 진행하세요:

1. BiRP 셰이더를 사용하는 모든 재질을 선택합니다(보통 Demos/Corgi3D/Materials 폴더 아래에 있는 재질들).
2. 선택된 재질의 인스펙터에서 상단에 있는 셰이더를 Standard로 설정합니다.
3. 그런 다음, Edit > Rendering > Materials > Convert Selected Built-In Materials to URP로 이동합니다. 이 과정이 끝나면 BiRP에서와 똑같이 보이지는 않겠지만, 데모를 무리 없이 즐길 수 있습니다.

Editor pre-releases

URP 15 이상 버전을 사용하는 경우, "Light2D" 타입이나 네임스페이스 이름을 찾을 수 없다는 오류가 발생할 가능성이 큽니다. 이는 Unity가 Light 2D 클래스가 속한 어셈블리를 변경하여 이전 버전의 URP와의 호환성을 깨뜨렸기 때문입니다. 이 문제가 해결되거나 이전 버전의 지원이 중단될 때까지, 다음과 같은 방법으로 이 문제를 해결할 수 있습니다:

문제를 일으키는 두 클래스를 제거합니다(MMF_Light2D_URP 및 MMLight2DShaker - 오류를 클릭하면 프로젝트 패널에서 이 클래스들이 강조 표시됩니다). 또는 2D 패키지를 설치할 수도 있습니다. 2D 라이팅을 사용할 계획이 없다면, 이 두 클래스를 삭제하는 것이 가장 쉬운 방법입니다. 네, 이 문제는 성가실 수 있습니다.

Feel을 이전 버전에서 새 버전으로 업데이트하는 가장 좋은 방법은 무엇인가요?

무엇을 하든 문제가 발생할 경우 롤백할 수 있도록 커밋/백업을 만들어 두세요. 그런 다음 이전 Feel 폴더를 제거하고 새 폴더를 가져오세요. 그렇지 않으면 Asset Store 가져오기 방식 때문에 일부 스크립트가 중복되거나 제거되지 않을 수 있습니다. 업데이트하는 버전과 대상 버전에 따라 약간의 리팩토링이 필요할 수 있습니다. 릴리스 노트를 확인하여 변경된 사항과 코드에 영향을 미칠 수 있는 사항을 확인하세요.

입력

데모는 Unity의 입력 API를 사용하여 상호작용을 트리거합니다. 이는 대다수의 사용자가 여전히 "새로운" 입력 시스템으로 이동하지 않았기 때문에 "구" 입력 API를 사용합니다. 새로운 입력 시스템을 사용하는 경우 하이브리드 모드로 전환할 수 있습니다 (Player Settings > Active Input Handling > Both). 또는 URP/HDRP를 실행하고 공통 분모 데모를 확인하고 싶을 때처럼, 데모를 확인하기 위해 사이드 프로젝트를 생성할 수 있습니다. 데모일 뿐이며, 나머지는 모든 곳에서 잘 실행될 것입니다. 네, 성가실 수 있지만, 이것이 현재 Unity의 상태입니다.

Feel이란 무엇인가요?

Feel은 최소한의 마찰이나 설정으로 필요에 따라 Unity 게임에 게임 느낌을 제공하는 즉시 사용 가능한 솔루션입니다. 모듈식, 사용자 친화적이며 확장하기 쉬운 시스템으로, 이를 기반으로 구축할 수 있습니다.

Feel이 왜 좋은가요?

게임의 느낌(또는 주스, 마이크로 인터랙션, 피드백)은 게임 디자인에서 가장 중요한 부분 중 하나라고 굳게 믿습니다.

플레이어가 자신의 행동의 결과를 이해하게 하는 것은 상호작용이 보람 있고 몰입되게 만드는 가장 좋은 방법입니다. 플레이어가 행동을 취했을 때 또는 게임에서 중요한 일이 일어났을 때 적절한 피드백을 제공하는 것은 필수적입니다. 화면 흔들림, 플래시, 객체의 크기 증가 또는 이 모든 것을 한 번에 제공하는 것은 경험을 더욱 만족스럽게 만듭니다.

피드백에 대해 더 알고 싶다면 Martin Jonasson과 Petri Purho의 "Juice it or lose it" 강연, Jan Willem Nijman의 "Art of screenshake" 강연, 또는 2018년 Unite Los Angeles에서의 저의 게임 느낌과 빠른 프로토타이핑에 대한 강연, 그리고 2019년 코펜하겐에서의 강연을 참고하세요.

이러한 종류의 피드백을 구현하는 것은 로켓 과학이 아닙니다. 카메라를 흔드는 것은 꽤 쉬운 작업입니다. 그러나 많은 게임과 프로토타입을 작업하면서 종종 동일한 게임 느낌 레시피로 돌아가게 되었고, 피드백에 대한 아이디어와 게임 내 구현 사이의 마찰을 최대한 줄이고 싶었습니다. 처음에는 TopDown Engine과 Corgi Engine에 내장된 Feel 시스템을 공개하기로 결정하여 사람들이 게임의 느낌을 개선하는 데 도움이 되기를 바랍니다.

Feel을 이전 버전에서 새 버전으로 업데이트하는 가장 좋은 방법은 무엇인가요?

무엇을 하든 문제가 발생할 경우 롤백할 수 있도록 커밋/백업을 만들어 두세요. 그런 다음 이전 Feel 폴더를 제거하고 새 폴더를 가져오세요. 그렇지 않으면 Asset Store 가져오기 방식 때문에 일부 스크립트가 중복되거나 제거되지 않을 수 있습니다. 업데이트하는 버전과 대상 버전에 따라 약간의 리팩토링이 필요할 수 있습니다. 릴리스 노트를 확인하여 변경된 사항과 코드에 영향을 미칠 수 있는 사항을 확인하세요.

모든 곳에서 작동하나요?

짧은 대답은 예입니다. Feel은 Unity가 지원하는 모든 플랫폼에서 작동합니다. Feel의 스크립트는 최적화가 잘 되어 있으며 가능한 한 낮은 비용으로 제공됩니다. 다만, Feel은 Unity의 기본 API 및 시스템을 대상으로 하며 그 비용을 변경하지 않습니다. 따라서 일반적으로 포스트 프로세싱 효과는 Feel을 사용하든 사용하지 않든 모바일에서 비용이 많이 들 것입니다. Feel은 수많은 파티클 시스템을 인스턴스화하는 피드백을 사용하는 것을 막지 않지만, 이는 Switch에서 잘 작동하지 않을 것입니다. 따라서 중요한 질문은 Feel을 무엇과 함께 사용할 계획인지입니다. 프레임 예산을 확인하고 Feel이 작동하는 요소들이 그 예산 내에 맞는지 확인하세요.  

다른 MoreMountains 자산에 Feel을 가져올 수 있나요?

Corgi Engine, Infinite Runner Engine, Nice Touch 또는 TopDown Engine을 사용 중이라면, 이들은 이미 MMFeedbacks와 MMTools(또는 그 일부)를 포함하고 있으므로 FEEL을 추가로 가져올 필요가 없습니다. 만약 그렇다면 일부 공통 라이브러리가 동기화되지 않을 수 있습니다. 항상 가장 오래된 것을 제거하고 새 것을 가져오며, 몇 가지 리팩토링을 준비하세요. 가져올 때 공통 라이브러리 폴더를 선택 해제할 수도 있습니다. 또는 다음 엔진 업데이트를 기다리세요.

Highroad Engine과 함께 사용할 계획이라면, 일부 리팩토링이 필요할 수 있으며, C#에 익숙하지 않은 경우 권장하지 않습니다. 이들은 몇 가지 공통 라이브러리를 가지고 있으며 현재 동기화되지 않습니다. 이는 곧 업데이트에서 수정될 예정입니다.