버거덕 게임즈

이번 챕터에서는 컴포지트 패턴을 이터레이터 패턴에 이어서 같은 주제, monster info와 weapon info로 소개하겠습니다. 컴포지트 패턴의 정의 객체들을 트리구조로 구성하여 부분 - 전체 계층구조를 구현합니다. 컴포지트 패턴을 이용하면 개별객체와 복합객체를 똑같은 방법으로 다룰 수 있게 됩니다. 이전시간에 배운 이터레이터 패턴과 혼합하여 설명하자면 복합객체인 iterator와 개별객체인 item이 구분할 필요가 없어, item을 가진 iterator를 가진 그위에 iterator를 가지는 형태, 즉 트리구조로 복합객체를 만들어갈 수 있습니다. 복합객체와 개별객체가 상속받을 infoComponent를 만들었습니다. 복합객체와 개별객체의 구분을 없애줄 것입니다. public abstract cla..

이름은 생소하지만 알게모르게 사용하고있던 패턴 '템플릿 메소드 패턴'입니다! 템플릿 메소드 패턴 정의 어떤 작업 알고리즘의 골격을 정의합니다. 일부 단계는 서브클래스에서 구현하도록 할 수 있습니다. 템플릿 메소드를 이용하면 알고리즘의 구조는 그대로 유지하면서 특정 단계만 서브클래스에서 새로 정의하도록 할 수 있습니다. 적용되는 객체지향의 원칙 수퍼클래스에서 모든것을 관리하고 필요한 서브클래스를 불러서 써야합니다. 템플릿 메소드 패턴의 핵심 재활용성을 생각하면서!(밑줄쫙) 추상클래스를 사용해서 수퍼클래스에 중복되는 부분은 구현하고, 서브 클래스에 달라질 수 있는 부분(바뀌는 부분)을 구현해줍니다. * 수퍼클래스에서 알고리즘을 관리하는 템플릿 메소드가 하나 있어야 합니다. * 템플릿 메소드는 알고리즘만 관리..

이번 챕터에서는 두개의 패턴이 함께 있어서 같이 작성했습니다. 첫번째로 어댑터 패턴입니다. 어댑터 패턴 정의 한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환합니다. 어댑터를 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 쓸 수 있습니다. 유니티에서 예시로는 결제모듈을 예시로 들었습니다. 실제로는 문제 없지만 만약에 AOS와 IOS의 결제 함수명이 다를때를 가정하고 구현했습니다. // 결제 어댑터 인터페이스 public interface PurchaseAdapter { void Purchase(); } // AOS 결제 모듈 public class AndroidInApp : PurchaseAdapter { public void Purchase()..

오늘 유니티에서 적용해볼 패턴은 '옵저버 패턴'입니다. 옵저버 패턴의 정의는 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이가고 자동으로 갱신되는 방식으로 일대다 의존성을 가집니다. 위의 정의를 유의하면서 게임에서 전투를 통한 체력 표시를 구현해봅시다! 구현하기에 앞서 오늘 패턴의 또다른 중요한 원칙 '느슨한 결합'에 대해서 먼저 정리해봅시다. 옵저버 패턴에서는 주제(Subject)와 옵저버(Observer)가 느슨하게 결합되어있는 객체 디자인 원칙을 제공합니다. 특징 1. 주제가 옵저버에 대해서 아는것은 옵저버가 특정 인터페이스를 구현한다는 것뿐입니다. 2. 옵저버는 언제든지 새로 추가할수있습니다. 3. 새로운 형식의 옵저버를 추가하려고 할때도 주제를 전혀 변경할 필요가 없습니다. ..

유니티에서 객체를 생성하는 일이 많습니다. 몬스터, 장애물, 유저캐릭터 등등... 오늘 정리할 패턴은 위와같이 객체를 생성하는 것에 있어서 확장성이 높고 의존성을 줄일 수 있는 패턴 '팩토리 메소드 패턴'입니다. 팩토리 메소드 패턴의 가장 큰 핵심은 어떠한 객체를 생산하는 생산자(Creator)와 어떠한 객체를 생산할지 결정하는 구상 생산자(ConcreteCreator)의 분리 입니다. 게임으로 예를 들면 전체 몬스터를 스폰해주는 어떠한 클래스가 생산자(Creator)입니다. 모든 몬스터는 이 클래스에서 생산이 됩니다. 그리고 생산될 몬스터를 결정해주는 클래스가 구상 생산자(ConcreteCreator)입니다. 고블린을 생산할지, 해골을 생산할지를 정해주는 클래스입니다. 우선 생산자 입니다. 생산자의 특..

지난 수요일에 친구들과 디자인패턴에 대해 스터디를 하면서 제 스스로로 잘 알고 사용하고 있으면서도 잘 모르겠는 아리송한 싱글톤 패턴에 대해서 다시 한번 정리하고자 합니다. 저는 예전에 게임을 구현하면서 유니티에서 C#으로 싱글톤으로 어떻게 구현하는지 찾아보면 원하는 스크립트에 static 멤버변수 instance를 선언하여 초기화한 후 다른 씬으로 넘어갈때 계속 유지할수있게 어떤 처리를 해서 계속 사용하는 방법을 자주 볼 수 있었습니다. //// 구글링해서 나오는 대부분의 유니티 싱글톤 느낌 public class GameManager : MonoBehaviour { // instance 멤버변수는 private하게 선언 private static GameManager instance = null; pr..