Patrick's Devlog

DirtyFlag PatternDirtyFlag 패턴은 메모리를 효과적으로 관리하기 위해 실시간으로 필요한 객체는 활성화하고, 필요하지 않을 때 비활성화 하는 패턴이다. 예를 들어 오픈 월드일 때 캐릭터가 이동 시 캐릭터 주변에 있는 사물 및 환경만 로딩이 되고 캐릭터가 벗어나면 로딩이 내려가는 것으로 생각하면 된다. 오픈 월드를 한번에 로딩하면 메모리 과부하가 일어나므로, 청크 개념 단위로 나눠 월드를 쪼개어 캐릭터의 시야정도까지만 로딩해야 한다. 패턴이긴 하나, 최적화 방법에 조금 더 가깝다. DirtyFlag는 비주얼적인 면, 데이터적인 면 등 여러 방면에서 광범위하게 사용한다. 구성이 복잡하고 비용이 많이드는 환경에 적합하며, 장면에서 많은 계산이나 업데이트가 발생할때 유용하다. 객체의 상태 변경..

Flyweight Pattern다른 패턴과 다르게 메모리 절약 등 성능 및 최적화에 초점을 맞춘 패턴이다. 여러 객체들이 리소스 공유를 통해 이들을 효율적으로 지원하는 패턴이다. 예를 들어 복제된 여러 GameObject가 씬에 존재할 때, 각 개별 필드는 상대적으로 작을 수 있으나 다양한 구성 요소와 저장된 데이터 필드(예 : 구조체, 배열 등 Value Type 유형)도 복사된다. 이러한 부분을 해결하기 위해 Scriptable Object를 사용하면 해결된다. 유니티에서 Flyweight Pattern을 사용한다고 하면 Scriptable Object를 사용한다고 생각하면 된다. Scriptable Object의 궁극적인 목표는 공유된 데이터는 데이터로서만 지니고 있고 여러 오브젝트가 참조한다. 이..

Strategy Pattern동일 계열의 알고리즘을 정의하고 각각의 알고리즘을 캡슐화하여 상호교환이 가능하도록 만드는 패턴이다. 쉽게 설명하면 객체 내에서 알고리즘이나 동작을 캡슐화 하고 이를 실질적으로 교환이 가능하게끔 만들어 준다는 것에 초점을 두면 된다. 각 객체는 동적으로 실행될 수 있는 고유한 동작을 캡슐화하고, 알고리즘을 사용하는 사용자와 상관없이 독립적으로 알고리즘을 다양하게 런타임시 변경할 수 있게 하는 것이다. 그림을 살펴보면 베이스 클래스인 Strategy가 존재하고, 이를 구체화해서 만든 파생 클래스가 ConcreteStrategy 클래스들이다. 실시간으로 Context에서 A나 B를 자유롭게 변경할 수 있도록 만들어준다.예시게임에서 어빌리티 시스템을 만든다고 예를 들어보자. publ..

개요MVC, MVP, MVVM 패턴은 UI와 로직의 분리가 목적인 패턴이다. 로직을 분리하여 불필요한 종속 관계를 줄인다. 오늘날의 UI는 과거보다 훨씬 정교해지고 수가 많아짐에 따라 혼자 작업할 수 없다. 여러명의 공동 작업을 진행할 때 구조를 얼마나 잘 짤 수 있을지가 관건이며, 구조의 짜임새가 중요하므로 다양한 패턴이 탄생하고 다양한 UI 프레임워크가 탄생했다. 기존의 디자인 패턴은 클래스 다이어그램으로 표현이 가능하나, 해당 패턴은 SoC(Separation Of Concerns, 관심사 분리) 측면이다. 즉, 하나 하나의 클래스가 아닌 어떤 로직 단위들의 관계를 나타내는 개념으로 생각하면 된다. 그러다보니 디자인 패턴보다는 아키텍쳐 패턴으로 분류된다. 유니티에서의 툴셋 기반으로 진행되는 도구는 ..

Singleton Pattern유일무이한 존재의 인스턴스, 즉 하나의 프로젝트에서 하나의 객체만 존재하는 것이다. 보통은 클래스를 생성할 때 인스턴스화한 후 여러 개 생성이 가능하나, 클래스가 자신의 인스턴스 하나만 인스턴스화할 수 있도록 보장하는 것이 싱글톤 패턴이다. 여러 곳에서 불러와야 하므로 해당 단일 인스턴스에 대한 손쉬운 전역 액세스를 제공하고 하나의 객체만 존재할 필요가 있을 때 사용된다. (example> 상태창, 게임 매니저, 오디오 매니저, 파일 관리자 UI Setting etc)그러나 모든 곳에서 접근해야 하다보니 안티 패턴(비효율적이거나 비생산적인 패턴)으로 취급되기도 하며, 커플링이 발생하기 쉬운구조이다. 생성 시점이 명확하지 않다보니 테스트나 디버깅이 불편하다는 점이다. 싱글톤 ..

Object Pool수많은 오브젝트를 다루는 개념이며, 오브젝트의 풀을 생성하고 필요할때 꺼내서 사용하면 된다. GoF의 디자인 패턴에서는 Object Pool을 따로 설명하지 않았다. 현대에서는 많이 쓰이는 개념이 되다보니 디자인 패턴으로 취급하는 경향이 있다. 전통적인 디자인 패턴하고는 컨셉이 다를 수 있으므로, 디자인 패턴보다는 최적화 기법으로 생각하면 된다.특징"Pool"에서 준비된 상태로 대기 중인 초기화된 오브젝트 세트를 사용한다. 그리고 오브젝트가 필요할 때 새로 인스턴스화하는 대신 풀에서 오브젝트를 활성화하여 사용한다. 해당 객체의 사용이 끝나면 Destroy 대신 비활성화하고 풀에 반환한다. 객체 생성 및 삭제로 인한 가비지 급증으로 발생할 수 있는 끊김 현상(Hiccup, GC spik..

Factory Pattern객체 생성을 위한 패턴이다. 아이템을 직접 생성하는 것이 아닌, 팩토리에서 호출하여 생성하는 것이 팩토리 패턴이다. 객체 생성에 대한 인터페이스와 구현의 분리가 가능하고, 객체 생성과 관련된 많은 세부 정보를 캡슐화할 수 있다. 또한 새로운 객체를 생성 방식에 대한 확장이 가능하다. Key-Value Dictionary를 이용한 탐색을 적용해, 아이템의 등급 등을 풀로 만들어 적용하는 경우가 많다. 또한 아이템을 많이 생성하다 보니 Object Pool과 병행해서 사용된다.  아이템 생성을 위한 아이템 매니저를 제작한다고 가정하고 코드를 예시로 들어보자. public class ItemManager : MonoBehaviour { ... public void Spaw..

Command Pattern커맨 패턴은 커맨드들을 패킹해서 택배처럼 나르는 것으로 비유할 수 있다. 하나의 명령을 객체에 직접 호출하는 것이 아닌, 패킹해 쏘는 방식이다. 해당 패턴은 각각의 요청을 객체의 형태로 캡슐화해 명령을 실행하는 객체(Receiver)와 명령을 내리는 객체(Invoker)로 분리되어 있다. 이러한 특성으로 인해 단일 책임 원칙을 따르게 된다. 새로운 명령을 추가할 때마다 기존 코드를 수정할 필요없이 새로운 ConcreteCommand 클래스를 추가하면 된다. 이 특성 또한 SOLID 원칙에서 개방 폐쇠 원칙을 따른다. 커맨드 패턴은 서로 다른 요청들을 큐에 저장하거나 로그로 기록하는 등의 처리가 가능하며, 결합도를 낮추고 명령을 추상화함으로써 코드의 유연성과 재사용성을 높인다. ..