[💬] 데이터 테이블과 스트레트지 패턴

[익명(1.234)]

스트레티지 패턴 반응이 핫해서 예제 만들어봄.

체제 요약:

유닛 테이블 - 스크립트에이블 오브젝트,이하 SO

행동 인터페이스 - SO, 유니티 상의 유닛테이블 안에 행동프로퍼티 변경 용이 위해서.함수사용위한 I인터페이스 다중 상속 및 Abstract

GameManager - 싱글턴 DataAssetManager 초기화 및 홀딩

DataAssetManager - 배열로 이루어진 데이터 테이블을 KeyPair 딕셔너리로 묶어 이름만으로 데이터 가져오기 제공.

Unit - 단한개만 존재하는 Unit 클래스,SetUnit(string className) 으로 작동.

물론 플레이어 캐릭터,특수한 NPC,패턴보스몹등을 만들기 위해선 Unit은 상속되고 확장될수 있음,,

단순 잡몹 따위는 모두 1개만 쓴다가 전제.

SOAttackBase,SOMoveBase가 상속패턴에서 오버라이드 하고 싶었던 가상함수의 기능을 따로 묶은 인터페이스 역할.

SO 스크립트에이블 오브젝트로 구현한 이유는 역시 SO로 만들어진 데이터 테이블에서 유니티 에디터상의 프로퍼티 조작기능을 사용하기 위해서.

SO~Base 들은 인터페이스 다중상속 및 Abstract처리 되어있음.

Unit을 만들때마다 배열 포문 돌릴수 없으니 이름과 데이터로 딕셔너리 세팅.

이 매니저는 게임매니저가 제일 처음에 초기화해줘야한다.

그냥 ExecutionOrder 올려버리셈.

유닛 클래스의 SetUnit,

SetUnit을 AwakeStart에서 안부르고 직접 객체 생성후 불러주면 된다.

맵,스테이지 데이터,UI입력 등에서 사용자에게 ClassName만 받아오면 되는 것임.

주석에도 있지만 게임에 따라 인터페이스 들에게 많음 파라미터를 넘겨주게됨.

아예 파라미터로 존나요약할수 있으면 SO를 추가 동적할당안하고 모든 유닛이 공통된 SO 1개만 쓰게 할수 있음.

여담으로 행동 인터페이스들 한테 DeltaTime 넘겨주면 FSM만들기 개꿀됨.

ScriptableObject 메뉴사용 모르는 사람 있을까봐

유닛테이블 사용,ClassName은 목숨걸고 지켜줘야하는 변수,향후 유닛프리팹 프로퍼티에 박아줄때, SetUnit할때 스펠링이랑 100% 일치해야한다.

이게 제약임. 하지만 다이렇게 함. 열거형으로 테이블 캐릭터를 부르게되면 배열이랑 1대1 매칭으로 불러오는 재미가 솔솔하겠지만

enum을 추가할때 비쥬얼스튜디오를 열어야한다는 점에서 데이터테이블 사용의 의미가 무색해짐.

그래서 오타가 날수있어도 string으로 약속만들고 틀린(기획자)새끼가 잘못한 체제로 가는거.

유닛 테이블에 비헤이비어 인터페이스랑 콘솔 로그를 보면 알겠지만

창병과 기사는 Move만 다르게 작동한다.

만일 이걸 전부 Unit 자체의 상속,가상함수 오버라이드로 구현한다면?

Attack*Move의 경우의 수만큼 만들어야 Attack과 Move가 다르게 작동하는 유닛들을 만들수있음

근데 데이터 테이블과 스트레티지 패턴을 사용하면

손가락 까딱으로, 그것도 기획자가 까딱까딱 하는걸로 조립을 하기 때문에

이런 경우의수를 전부 구현할 필요가 없음.

애초에 유닛상속 패턴은 늙은 교수들이 모르고 구세대 방식으로 가르치는거

유닛-오크-초록오크-노랑족장오크-빨간족장오크-초록족장오크

이딴식으로 구현계속해봐라 뭔가 졷됐다는게 안느껴지냐?

결국 프로퍼티만(색깔 등) 다른 케이스가 존재할것이고 여기서 상속으로 빼다보면

"아 뭔가 비효율적인데"

싶어지고 결국 if switch 쓰게됨. 근데 그순간 가상함수 override가 무슨 의미가 있냐?

거기에 자식클래스가 부모 그것도 조선시대 증조할아버지 클래스의 값을 변경하는 역류가 필연적으로 발생함.

처음부터 통Unit에 통 if Switch로 구현하지 그러면? 이거 보다 나은게 뭐냐?

조건문 안쓰려고 구조 잡는건데;

또 말한대로 해당 프로젝트에 유닛 프리팹은 단 1개다.

수십 수백개 프리팹 일일히 열어서 프로퍼티 바꾸는거랑 데이터 테이블만 건드리는거랑 비교해보셈 ㅇㅇ.

SO는 죽어도 안쓴다 하는 사람들도 있는데 그런건 알아서하고

언리얼에선 테이블&스트레티지 패턴을 쓰기가 엄청 용이해서(자료형 자체를 담는 변수,TSubClass 라는것이 존재)

유니티로 똑같은 방식 구현 할라하니 쓸수밖에 없었음.

https://github.com/Heretic-byte/Strategy2

풀프로젝트. 스프라이트는 오픈게임아트 리소스

[익명(175.194)]

미리 추천박고 내일 아침에 확인해야겠당

[익명(175.194)]

개쩐다;

[익명(175.194)]

특정 행동이 유닛 자기 자신에게 영향을 주는 행동이라면 매개변수로 유닛 자기 자신 넣어주면 되는거임? 아니면 다른 방법으로 처리하나

[익명(1.234)]

방법이야 여러가지겠지만 일단 인터페이스한테 매개변수로 유닛주는건 필수지, 내가 빼먹은거라 보면됨. 당장 저위에서 러쉬무브가 공격력을 추가로 주려면 원래 유닛의 공격력을 알아야하니깐 ㅋㅋ. 이제 여기서 인터페이스에게 초기화함수를 만들어서 처음에 필요한 변수들을 캐싱 시켜줄거면 지금 내방식대로 Instantiate하는게 맞고 전부다 매개변수로 넘겨줄거여서 SO인터페이스가 홀딩하는게 하나도 없다면 instantiate안쓰고 주석에 써놓은 방식대로하는게 맞고

[익명(183.103)]

아 SO로 저렇게 한번에넣어버리는구나 개신기하네 나는 기획자놈이 따로 유니티를 안만져서 SO하나하나 따로만들어서 리소스폴더에넣고 그때그때 불러왔었는데 이거보니까 존내 병신같은짓 했네... ㄳㄳ

[김메가(scw973108)]

추

[codeCat(223.38)]

유닛자체도 SO로 만들고 쓰는편이 더 편하지않나여?

[익명(1.234)]

그게 SO테이블 1개에 구조체로 모아놓고 쓰는것보다 이득인게 한개도 없음, 결국 스트레트지 인터페이스 SO + 유닛 SO 만큼 에셋만 늘어나버림 필요이상으로. SO 1개 테이블 쓰냐 유닛 SO 다 따로만들거냐 이거잔아? 결국 유닛 SO도 어떤 컨테이너에 저장되야하고 그시점에서 단점만 있지 장점은 하나도 없지

[커서(az6133)]

Item, 몬스터 매니저 묶어서 CSV 입출력으로 해봐야겠다 - dc App

[익명(58.122)]

공격방식 같은걸 유닛마다 다르게 처리하는거, 스크립터블 오브젝트에서 함수로 처리 안되길래 '스크립트' 오브젝트로 연결해다가 리플렉션으로 처리했었는데, 이거 보니까 그냥 인터페이스로 처리되네...아 나 뭐한거냐 ㅋㅋㅋㅋㅋㅋ

[익명(222.238)]

대박이네

[익명(222.238)]

유닛-오크-초록오크-노랑족장오크-빨간족장오크-초록족장오크 ㄹㅇ 이것때매 복잡한겜 못만들고 있었는데 ㅋㅋㅋㅋ

[익명(124.57)]

초록족장오크 씨바 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

[익명(211.41)]

게임 프로토타입 수준 때 하기 쉬운 실수를 범하는게 아닐런지... 어설픈 제네릭은 기획에 제약을 주는 덫이 되어 찾아오게 되어있음. 상태 머신의 기틀을 잡는거야 옛날부터 상속하곤 무관했음. 언제나 단단한 구조보다 말랑한 구조에 커스텀한 내용이 들어갈 "여지"를 만들어주는게 좋음... 새로운 환경을 팀원에게 "알려줘야"하는 것 자체가 리스크가 될 수 있음... 팀원 잘 못 만나면 유니티 키지도 않아서 결국 본인이 만지는데 "아 ㅅㅂ 이럴꺼면 걍 코드로했지" 상황도 나옮...ㅋ