1. 📦 스크립터블 오브젝트의 개념과 이점
-
스크립터블 오브젝트는 데이터 컨테이너로서, 플라이웨이트 디자인 패턴을 활용해 메모리 공간을 효율적으로 관리한다.
-
이 객체는 게임 오브젝트 없이도 데이터를 저장할 수 있으며, 모노비헤이비 보다 가벼운 구조를 제공한다.
-
프로젝트 수준에서 여러 신이나 오브젝트에서 접근 가능한 데이터 저장을 가능하게 하며, 싱글턴을 대체할 수 있는 기능을 수행할 수 있다.
2. 🗂️ 스크립터블 오브젝트의 특징과 장점
-
스크립터블 오브젝트는 데이터와 로직을 분리할 수 있는 모듈성을 제공하여, 게임 데이터(예: NPC 구성 값, 캐릭터 통계)를 저장하고 테스트하기 편리하게 만든다.
-
이를 통해 게임 플레이 데이터와 로직의 관심사를 분리하고, 각각의 독립적인 부분에 대한 유지 관리가 수월해진다.
-
스크립터블 오브젝트는 런타임에서의 데이터 유지가 가능하여, 플레이 모드 종료 후에도 데이터가 유지된다. 이는 시네머신 및 포스트 프로세싱과 같은 기능에서 활용된다.
-
스크립터블 오브젝트는 기본적으로 파일로 저장되어, 게임 오브젝트에 직접 붙일 수 없으며, 모노비를 통해 참조하여 사용할 수 있다.
-
이러한 구조 덕분에 스크립터블 오브젝트는 메모리 효율성을 높이고, 기획자와 프로그래머 간의 협업을 향상시키는 데 유용하다.
-
스크립터블 오브젝트는 단순한 데이터 컨테이너이상의 기능으로, 모듈성을 지니고 있으며 데이터와 로직을 분리할 수 있다.
-
데이터와 로직을 분리함으로써 관심사 분리를 실현할 수 있으며, 독립적인 부분의 테스트와 유지 관리가 수월해진다.
-
스크립터블 오브젝트는 런타임에 동적으로 변경될 수 있는 데이터를 정적 구성으로 저장할 수 있어, 플레이 모드에서 조작한 데이터도 유지된다.
-
시네머신 및 포스트 프로세싱 같은 유니티의 다양한 기능이 스크립터블 오브젝트를 사용하여, 플레이 모드에서 설정한 값들을 유지할 수 있도록 지원한다.
-
모노비헤이비어에서는 구현이 불가능한 기능들이 스크립터블 오브젝트를 사용함으로써 플레이 모드와 에디터 모드 간의 데이터 유지가 가능하다.
-
스크립터블 오브젝트는 생성하기 어렵지 않으며, 기본적으로 모노 비헤이비어를 상속받아 구현된다.
-
생성한 스크립터블 오브젝트는 Create S 메뉴를 통해 프로젝트 뷰에서 쉽게 만들 수 있다.
-
스크립터블 오브젝트를 인스펙터에 노출시켜서 사용할 수 있으며, 셋 형태로 저장된다.
-
데이터 컨테이너의 역할을 하며, 여러 개의 동일한 오브젝트가 존재할 때 중복된 데이터를 모든 인스턴스가 소유하게 된다.
-
다양한 데이터 타입(예: 정수, 문자열)을 설정할 수 있어 유연한 데이터 구성이 가능하다.
-
스크립터블 오브젝트를 사용하면 모든 모노비 인스턴스가 데이터를 참조하게 되어 데이터 메모리를 절약할 수 있다.
-
이는 플라이 웨이트 패턴의 기본 개념으로, 복제된 게임 오브젝트가 다수 존재할 경우 메모리에 불필요한 데이터가 쌓이는 것을 방지하는 방법이다.
-
RTS, RPG 게임에서 유닛의 공통 데이터를 스크립터블 오브젝트로 생성해 공유함으로써 개별 유닛의 상태 정보만 인스턴스에서 관리할 수 있다.
-
각 인스턴스는 현재 상태, 체력 등의 정보를 따로 유지하므로, 스크립터블 오브젝트를 통해 속성을 효율적으로 관리할 수 있어 메모리 절약효과가 있다.
-
스크립터블 오브젝트는 데이터 컨테이너역할을 하므로, 이를 활용하는 것이 유리하다.
-
스크립터블 오브젝트와 모노비는 유니티 엔진 오브젝트를 상속받으며, 사용될 때의 차이는 있다.
-
모노비는 여러 라이프사이클 관련 함수(예: 어웨이크, 업데이트 등)를 가지며, 복잡한 구조를 가진다.
-
반면, 스크립터블 오브젝트는 간단한 메서드(예: 리셋, 에이블 등)만 갖고 있으며, 런타임동안 작업할 것이 많지 않다.
-
스크립터블 오브젝트는 파일로 저장되기 때문에, 게임 오브젝트에 직접 붙일 수 없고, 모노비 클래스에 의해 참조되어야 사용된다.
-
스크립터블 오브젝트는 모든 항목의 런타임변경 불필요한 경우에 유용하며, 팀 협업에 도움이 되는 구조이다.
-
게임 디자이너, 특히 기획자와 아티스트는 스크립터블 오브젝트의 기능을 유용하게 활용할 수 있다.
-
프로그래머는 모노비에서 개발하고, 기획자 및 아티스트는 스크립터블 오브젝트를 에셋 단계에서 조율하는 구조가 형성된다.
-
이로 인해 협업이 원활하게 이루어질 수 있는 환경이 조성된다.
3. 🎮 스크립터블 오브젝트의 장점과 활용
-
스크립터블 오브젝트는 효율적인 협업과 메모리 사용을 개선하는 여러 가지 장점을 제공하며, 이를 통해 모노비헤이비어와의 섞어 쓰기를 결정할 수 있다.
-
직렬화된 데이터 형식 덕분에 인스펙터에서 쉽게 표시되고 수정될 수 있으며, 외부 툴을 통해 JSON이나 XML 파일로도 데이터를 주고받을 수 있다.
-
스크립터블 오브젝트는 데이터 저장소뿐만 아니라 로직 구현도 가능하여, 예를 들어 가위바위보 게임처럼 상호 관계를 설정할 수 있다.
-
디자이너와 프로그래머 간의 작업 분담이 가능하며, 팀 협업시 스크립터블 오브젝트가 유리한 측면을 제공한다.
-
스크립터블 오브젝트는 싱글톤과 같은 안티 패턴을 피할 수 있는 장점이 있으며, 상태 관리와 이벤트 핸들러 등 다양한 디자인 패턴에서 활용될 수 있다.
-
스크립터블 오브젝트는 모노보다 많은 장점을 제공하며, 효율적인 협업과 메모리 사용 개선에 기여한다.
-
유니티의 스크립터블 오브젝트는 직렬화된 데이터로 인스펙터에 직접 표시되고, 내용 수정이 용이하다.
-
XML이나 제이슨과 같은 공용 포맷은 범용성이 있지만, 스크립터블 오브젝트는 유니티외부에서 수정이 어렵기 때문에 각 포맷의 장단점이 있다.
-
스크립터블 오브젝트와 XML, 제이슨은 혼합하여 사용할 수 있으며, 이를 통해 협업에서 유리한 측면이 있다.
-
유니티에서의 필요에 따라 스크립터블 오브젝트를 제이슨 형태로 익스포트하거나 임포트할 수 있으며, 이는 1인 개발보다는 팀 작업에 더욱 적합하다.
-
이넘 데이터를 사용하면 유지보수가 용이해져, 텍스트로 표시하는 것이 사람에게 더 수월하다.
-
스크립터블 오브젝트는 속성을 포함하여 여러 형태로 확장할 수 있어, 예를 들어 가위바위보의 경우 상대의 약점 관계를 정의할 수 있다.
-
스크립터블 오브젝트에서 함수는 정적 함수로 사용해야 하며, 인스턴스가 아니기 때문에 외부 호출이 가능하다.
-
스크립터블 오브젝트를 이용하면 게임 아이템과 게임 컨트롤러의 연결이 가능해지고, 이는 게임 개발에서 협업을 용이하게 만든다.
-
이 객체는 프로그래머뿐만 아니라 디자이너와의 협업도구로도 효과적으로 사용되며, 코드 작성의 부담을 줄이는 데 기여한다.
-
델리게이트 오브젝트는 스트래티지 패턴의 일종으로, 함수를 담는 변수라는 개념이다.
-
이를 통해 여러 개의 함수를 담고 호출할 수 있으며, 멀티 캐스트가 가능하다.
-
스크립터블 오브젝트를 통해 다양한 상태(NPC의 패트롤, 도망 상태 등)를 런타임에서 동적으로 관리할 수 있다.
-
모노비로도 구현이 가능하지만, 스크립터블 오브젝트를 사용하면 더 가벼우며 싱글톤 우회가 가능하다.
-
기획자와 프로그래머 간의 협업을 촉진하여 상태 추가 작업을 용이하게 할 수 있는 장점이 있다.
-
옵저버 패턴은 이벤트 핸들링을 위해 주로 싱글톤을 생성하는 경우가 많다.
-
스크립터블 오브젝트를 사용하면 싱글톤을 피할 수 있는 기회가 늘어난다.
-
싱글톤은 클래스의 인스턴스를 하나만 만들도록 보장하는 디자인 패턴이지만, 안티 패턴으로 간주되기도 한다.
-
여러 시스템(예: 상태창, 게임 매니저, 오디오 매니저 등)은 스크립터블 오브젝트로 대체 가능하다.
-
싱글톤은 커플링과 테스트의 불편함 같은 단점을 가지고 있으며, 최소한으로 사용하라고 권장된다.
4. 🎮 스크립터블 오브젝트의 필요성과 장점
-
스크립터블 오브젝트는 복잡한 인스턴스 관리 없이 유일 존재로 구현할 수 있어 효과적이다. 즉, 싱글톤 패턴을 대체하는 것이 가능하다.
-
옵저버 패턴을 통해 서로의 의존성을 낮추면서 하나의 주체가 여러 청취자에게 신호를 보낼 수 있다. 이를 통해 객체 간의 의존 관계를 더욱 느슨하게 할 수 있다.
-
스크립터블 오브젝트는 데이터 저장소가 아닌 이벤트 채널 역할을 하여 의존 관계를 더욱 끊을 수 있다. 이는 디자이너와 프로그래머 간의 협업을 원활하게 한다.
-
런타임 셋을 통해 NPC나 아이템 목록과 같은 데이터를 스크립터블 오브젝트로 관리할 수 있다. 이를 통해 관리 책임을 분리하고 유지보수가 용이해진다.
-
제네릭을 이용하면 다양한 목록을 유연하게 관리할 수 있어 개발 작업이 수월해진다. 이는 공통 기능을 한 번 구현하고 여러 상황에 재사용할 수 있는 장점이 있다.
-
싱글톤 클래스의 경우, 정적 멤버로 자신을 참조하며 인스턴스를 생성하고 관리해야 한다.
-
만약 인스턴스가 존재하면 기존 인스턴스는 파괴되고, 새로 생성된 인스턴스를 자신으로 설정해야 하므로 구조가 복잡해진다.
-
스크립터블 오브젝트는 이러한 복잡한 구조가 필요 없으며, 애초에 유일무이한 존재로 설계되어 단순하게 사용할 수 있다.
-
스크립터블 오브젝트가 싱글턴을 대체할 수 있는 점이 장점으로 부각된다.
-
옵저버 패턴은 하나의 주체가 여러 청취자에게 신호를 보내는 방식으로, 상태 변경이나 이벤트 발생 시 모든 종속 오브젝트에 정보를 전달한다.
-
옵저버는 서브젝트와의 종속 관계를 갖지만, 서로간의 의존 관계를 약하게 할 수 있어 서로의 행동에 영향을 받지 않는다.
-
스크립터블 오브젝트를 사용할 경우, 이벤트 채널의 역할만 수행하며, 서로의 관계를 더욱 느슨하게 만들어 의존성을 줄인다.
-
스크립터블 오브젝트는 기획자나 아티스트가 직접 이벤트를 등록할 수 있도록 해 프로그래머와 디자이너 간의 협업을 수월하게 만든다.
-
사용자는 스크립터블 오브젝트를 상속받아 이벤트 채널을 만들고, 이를 통해 간단하게 이벤트를 호출할 수 있다.
-
커맨드 패턴은 객체를 캡슐화하여 명령을 전달하는 방식으로, 기존 코드를 수정하지 않고 새로운 커맨드 클래스를 추가할 수 있게 해준다.
-
이 패턴을 활용하면 언두와 리두 기능 구현이 가능하며, 다양한 액션 게임의 커맨드 콤보를 만들 수 있다.
-
커맨드 패턴은 인풋 매니저를 통해 여러 명령을 위임하여 플레이어의 입력을 처리하는 구조로 구성된다.
-
스크립터블 오브젝트를 사용하면 커맨드를 더욱 유연하게 구현할 수 있으며, 이벤트 채널을 통해 커맨드 패턴을 확장할 수 있다.
-
스크립터블 오브젝트를 사용하더라도 아이 커맨드 인터페이스는 동일하게 활용할 수 있으며, 큰 차이는 없으나 이벤트 채널을 통해 기능을 확장하는 장점이 있다.
-
런타임 셋은 게임 개발시 NPC 목록, 아이템 목록 등을 관리하는 새로운 패턴이다.
-
스크립터블 오브젝트를 통해 목록 관리를 분리함으로써 의존성을 줄일 수 있다.
-
게임 매니저가 아닌 스크립터블 오브젝트에 직접 접근하여 목록을 관리하면, 보다 쉽게 유지보수를 할 수 있다.
-
스크립터블 오브젝트사용 시, 다수의 매니저 클래스가 존재하더라도 목록 접근이 용이해지고 싱글턴의 필요성이 줄어든다.
-
이러한 접근 방식은 유닛 테스트와 같은 여러 이점으로 이어지게 된다.
-
런타임 셋을 활용하여 스크립터블 오브젝트는 단순한 목록을 가지고 있으며, 목록 추가와 삭제에 필요한 함수만 구현되어 있다.
-
스크립터블 오브젝트는 아이템 목록이나 NPC 목록 등 다양한 용도로 사용될 수 있다.
-
제네릭을 사용하면 공통적인 기능을 한 번만 구현함으로써 유연한 처리가 가능하다.
-
제네 클래스는 스크립터블 오브젝트를 가져와 사용하고, 추가적인 부분만 구현하면 되어 관리가 수월하다.
-
스크립터블 오브젝트는 제네릭과 결합할 경우, 더 효과적으로 유지보수할 수 있는 장점이 있다.
5. 🌀 스크립터블 오브젝트의 장점과 활용
-
스크립터블 오브젝트는 모노비헤이비어로 구현 가능한 내용들이지만, 여러 가지 장점을 제공한다.
-
스크립터블 오브젝트와 모노비헤이비어 각각의 장단점이 있으며, 이들을 적절히 섞어 사용하는 것이 최선이다.
-
특정 상황에서 꼭 스크립터블 오브젝트를 사용해야 하는 정답은 없으며, 모든 상황에 완벽한 솔루션은 존재하지 않는다.
-
개인의 프로젝트 상황에 따라 결정이 달라질 것이므로, 주의 깊게 고려해야 한다.
-
스크립터블 오브젝트의 다양한 가능성을 이해하고 실무에 적절히 적용하는 것이 중요하다.