[💬] "유니티에서 상속~"글의 댓글에서 이어옴

[ㅁㅁ(14.40)]

기분좋게 노래방에서 노래부르고있다가 댓글보고 빡쳐서 글씁니다.

일단 빡치니까 먼저 빡치는 부분부터 얘기해보겠습니다.

전 ㅁㅁ로만 댓글을 달았고 다운캐스팅 얘기는 하나도 안했으니까 자꾸 다운캐스팅으로 지랄하지마십쇼. 다운캐스팅이 뭔지 저도 압니다.

추가로 자꾸 책을 보라고 하시는데 제가 제 상황을 이용해서 설득력을 얻고싶지는 않습니다만 이미 책 많이 읽고 현업뛰고 있습니다.

원본 글은 제가 쓴게 아니지만서도 저는 글에 공감하는 입장입니다.

글에 나온 논지를 다시 정리하자면 "기반 클래스 하나에서 상속받은 클래스들을 풀링할 때

종류별로 다 만들어줘야 되니까 문제가 있다. 차라리 총알의 모든 기능을 담은 슈퍼클래스 하나를 풀링하는게 낫다." 입니다.

저 주장을 이해하려면 알아야 하는 내용을 정리해봅시다.

오브젝트 풀링의 목적

메모리 동적할당은 비싼 작업입니다. 어떤 객체를 동적으로 힙에 생성하기 위해서는 메모리(중 힙)에 접근해 객체 크기만큼의 공간이 있는곳을 

찾아서 할당하고, 생성자를 호출해서 이 메모리 공간을 초기화해야합니다.

오브젝트 풀링은 게임이 한창 돌아가는 시간(실행시간 이라고 하겠습니다)에 이 비싼 메모리 동적할당을 최대한 하지 않고자 사용하는 기법입니다.

게임이 시작하기 전에 미리 어떤 객체가 얼마나 사용될지를 예측해서 미리 할당해놓고, 재사용하는것이 오브젝트 풀링의 핵심입니다.

왜 상속을 하면 각각 n개씩 만들어줘야 하나요?

class Bullet {

public float speed;

}

class FallingBullet : Bullet {

public float gravity;

public float yVelocity;

}

이런 코드가 있다고 합시다.

Bullet이 실제로 차지하는 메모리는 float 하나만큼이고, FallingBullet이 실제로 차지하는 메모리는 float 세 개 만큼입니다.

여기서는 생략했지만 당연히 FallingBullet의 Update함수가 있다고 하면 정상적으로 동작하기 위해서는 저 세 개의 변수가 전부 필요하겠죠.

여기서 기반 클래스인 Bullet만 풀링, 즉 미리 생성해놓겠다고 하는건 말이 안되는것입니다. FallingBullet이 동작하기 위해서는 저 세 개의 변수가 전부 필요하기 때문이죠.

이게 알아야 하는 내용의 전부입니다만 자꾸 컴포지트 패턴이니 이해도가 부족하니 어쩌고 하시니까 그것도 한번 정리해봅시다.

1. 아래 문단에 데이터 설정에 따라 모든 총알들의 기능을 수행시켜보자 = 상속

상속 아닙니다. 상속받으면 기능에 따라서 클래스 따로 만들어서 넣어줘야하는데 그게 무슨 "데이터 설정에 따라" 일까요.

여기서는 하나의 클래스가 모든 기능을 다 갖고있고 데이터만 넣어줘서 돌아가게 하자는겁니다. 간단한 예를 들자면

bullet = //뭐 어떻게든 생성해서 갖고왔음

bullet.isGuided = true;

하면 따라가는거고 여기에다가

bullet.isExplosion = true;

bullet.explosionRadius = 3;

같은거 하고 날리면 따라가면서 터지는거죠. 필요한 코드들은 다 Bullet 클래스 안에만 있을거고요.

2. 팩토리 패턴 어쩌구

맥락에 안맞는 헛소리입니다. 넘어갑니다.

3. 상속을 쓰든 안 쓰든 간에 각 오브젝트별로 1000개씩 풀링한다는 접근이 나가리

나가리 아닙니다.유니티 풀링을 검색하면 많이 나오는것들이 GameObject 풀링입니다.

일반적으로 붙일 스크립트에 비해서 GameObject가 훨씬 무거워서 이 접근은 유효한 접근입니다만,

여기서 풀링의 효과를 제대로 보려면 즉, 실행시간에 동적 메모리 할당이 없게 하려면 당연히 모든 컴포넌트를 가진 객체를 생성해놔야 합니다.

그래야 그대로 갖다쓸 수 있으니까요.

여기서 GameObject를 풀링하니까 그정도 메모리할당은 감수할 수 있는거 아니냐 라고 하실 분들이 꽤 계시는거같은데,

중요한건 동적할당을 하느냐 안하느냐 입니다. 100% 할당하던걸 40%만 실행시간 할당한다고 해도,

할당 자체가 시간이 오래걸리는 작업이니까 피하는겁니다.

왜 각각 n개씩 만들어줘야 하는지는 위에 써놨습니다.

나머지는 한국어 구사능력 문제같은데 안타까우니까 하나 더 적습니다.

4. 애초에 컴포지트패턴을 쓴게 게임오브젝트당 컴포넌트를 쉽게 교체하려고 쓰는거기때문에 빈 오브젝트 1개만 있어도 총알 1000개는 동적로딩이 가능하고 안에 컴포넌트만 바꿔끼우면 여러클래스를 바꿔가지는 총알의 구현이 가능한데 컴포넌트의 이해가 부족한거야 저건

빈 오브젝트 하나만 있어도 컴포넌트만 갈아끼우면 동작이 달라지겠죠 네.. 총알 하나일때요.

한 화면에 총알 1000개 띄우고싶으면 어차피 오브젝트 1000개 있어야됩니다 헛소리하지마세요.

[asfshy(picaman)]

그럼 주장대로라면 상속받은 클래스 1개당 프리팹1개만 만들어뒀다가 오브젝트 자체를 교체해버리면 되는데 왜 프리팹당 1000개씩을 따로만들어야하는지?

[asfshy(picaman)]

아니 클래스당 1000개씩을 새로 만들어야되는지

[asfshy(picaman)]

원문에서 주장은 새로이 상속받은 클래스를 풀링하려면 100개가 추가된다고 적혀있고

[ㅁㅁ(14.40)]

ㄴ 프리팹을 1000개 만든다는 소리가 아니고 인스턴스를 1000개(동적할당을 1000번) 만들어놓는다는 소리입니다. 왜 1000개 만드는지는 자명하죠. 1000개 써야되니까요.

[asfshy(picaman)]

갑자기 풀링오브젝트가 수천개가 됐다 이지랄 하는데

[asfshy(picaman)]

인스턴스를 그럼 1000개 이상 만들 필요가 있냐 그말이야

[ㅁㅁ(14.40)]

그건 원문 글에 있는데, 어떤 총알이 한번에 1000개가 등장할지 알 수 없으니까 안전빵으로 만들어놔야됩니다.

[asfshy(picaman)]

현업인지 뭔지 그딴게 좆도 안된다는건 지금 회사 이직해왔을때 리드프로그래머 하던새끼가 프로잭트를 상속객체 하나 없이 좆같이 짜놨더라 그거 갈아엎는데 2달걸렸다 그새끼가 나보다 경력도 많고 월급도 많았었는데말이야

[asfshy(picaman)]

결론은 어떻게됐냐고? 2달걸려서 갈아엎어놨더니 그새끼가 반년간 만들던걸 3주만에 새로 만들었어 총 2달하고 3주걸린셈이지

[ㅁㅁ(14.40)]

네 그건 안타깝게 생각하고요, 이게 맞는지 안맞는지는 별개의 문제니까 내용만 봐주세요. 그걸로 설득력 얻고싶은 생각 없습니다.

[asfshy(picaman)]

그리고 원문에는 유니티 얘기를 하고있는데 우리가 유니티를 쓰는 이유에 대해서 설명을 하자면 유니티 풀링을 할때는 프리팹을 1개를 가져오건 1000개를 한번에 가져오건 속도차이가 거의 없다

[asfshy(picaman)]

배치라는 개념이고

[asfshy(picaman)]

1개만 소환을 해와서 구석에 쳐박아 두면 이후에 1000개를 한번에 불러도 메모리가 오버하지 않는한 같은곳에 접근해수 인스턴스 생성하기 때문에 연산속도는 지장이 없다는것

[ㅁㅁ(14.40)]

배치는 렌더링할때 나오는 개념이고요... 메모리 할당 코스트 얘기하고 있는데 게임루프 얘기로 넘어가지 맙시다

[asfshy(picaman)]

유니티가 3버전까지는 가비지콜랙터가 ㅂㅅ이라 동적할당을 하면 말그대로 하드웨어가 맛이 가버렸었는데 5버전부터는 성능이 많이 향상이 돼서 1000개를 부르건 1000만개를 부르건 메모리누수가 거의 없음 걍 지워버리면 될 일

[asfshy(picaman)]

결국 오브젝트를 불러올때 가장 연산시간이 많이 걸리는게 그래픽적 요소인데 배치를 빼놓고 이야기 하자고?

[ㅁㅁ(14.40)]

1000개를 게임루프에서 마구 동적생성하는게 실행속도에 지장을 준다는 내용입니다. 그게 지장을 주지 않는다면 풀링 왜합니까?

[ㅁㅁ(14.40)]

그래픽적 요소는 불러오고 나서 그릴때 얘기입니다. 지금 얘기와는 아무런 관계가 없습니다.

[asfshy(picaman)]

그럼 현업이라고 하셨는데 필드에 있는 몬스터를 죽이고나면 그 객체는 어디로갑니까

[ㅁㅁ(14.40)]

몬스터를 풀링했다면 객체는 메모리에 남아서 재사용 가능하게 대기하는 상태가 되겠죠..

[asfshy(picaman)]

아니다 좀 예를 잘못들었네요 몬스터는 집어치우고

[asfshy(picaman)]

철권같은 1v1격투게임을 만들어야 되는데 플레이어가 사용가능한 캐릭터가 21가지는 된다고 칩시다. 배틀씬에 돌입을 하면 1개의 캐릭터를 선택한 상황에서도 21개씩 총 42개의 캐릭터가 대기를 타야하나요?

[ㅁㅁ(14.40)]

지금 스무고개하시나요? 이해가 안돼서 질문을 하시는거면 괜찮은데 "내용판단은 못하겠고 니가 믿을만한 사람인지 검증해보자"면 사절입니다.

[ㅁㅁ(14.40)]

지금 철권같은거랑은 상황이 다릅니다. 한번에 총알이 많이 뿌려지는 탄막슈팅게임을 떠올리세요

[ㅁㅁ(14.40)]

철권은 당연히 전투씬으로 넘어갈때 그 캐릭터 하나만 생성하면 되는거죠...

[asfshy(picaman)]

아 예 적절지 못했습니다

[asfshy(picaman)]

그래서요

[asfshy(picaman)]

이해가 안가는건 왜 최대 인스턴스가 한 씬에 수천개가 필요한지입니다. 천개까지 로드하는게 메모리의 한계라하면 1000개를 띄워놓고 각 인스턴스의 주소값을 주무르면 되는걸 왜 굳이 수천개 띄워놓고 인덱싱도 힘든걸 제어하냐는거죠

[ㅁㅁ(14.40)]

따라가면서 폭발하는 총알을 마구 쏴대는 적군 기체가 있고 직진하는 화살을 마구 쏴대는 적군 기체가 있다고 합시다.

[asfshy(picaman)]

내가 지금 이해하질 못하는건 정말 여러가지 기능을 가진 상속된 프리팹이 5가지쯤 된다고 쳤을때 마스터 불렛을 만들어놓고 이걸 불렛1 불렛2 불렛3으로 스위칭하는게 정말로 불가능하다 생각하는건지요? 심지어 유니티에서?

[ㅁㅁ(14.40)]

각각의 총알을 풀링하고 있을 때, 얘네가 화면에 엄청 많이 나타나서 총알을 많이 쏴댄다고 하면 어떤게 얼마나 생길지 알수가 없겠죠. 전자를 한 10개만 생성해놓고 후자를 1000개 생성해놓는다는건 말이안됩니다.

[ㅁㅁ(14.40)]

아니 지금 스위칭에 코스트가 드니까 스위칭 안하려면 풀링을 다해놔야된다를 전제로 깔고 가고있는데

[ㅁㅁ(14.40)]

스위칭이 불가능하냐는걸 물어보시는겁니까 지금? 스위칭 당연히 가능하죠 글의 3번을 보세요..

[asfshy(picaman)]

따라가서 폭발을 하건 썰어대건 상속을 받았다면 모체가 되는 베이스 불릿 클래스가 있을텐데 이걸 화살불릿 폭발불릿으로 바꾸질 못한다구요?

[ㅁㅁ(14.40)]

상속관계에서 말씀하시는거면 새 인스턴스 할당하지 않는 한 불가능하고요, 컴포넌트 구조에서도 화살, 폭발 따로 컴포넌트로 구현했더라도 AddComponent할 때 추가적인 할당이 일어나기 때문에 할당을 안하려고 하면 불가능합니다.

[ㅁㅁ(14.40)]

저는 풀링의 목적이 뭔지 글에 적어놨고요, 풀링의 목적을 제대로 달성하려면을 전제로 깔고 가고있습니다.

[익명(183.100)]

내가 헛소리했다고 해서 나도 적어 본다 ㅋㅋㅋㅋ 일단 GameObject로 a b c e 만들어 여기에 스크립트를 똑같은 걸 붙여. 예로 create 스크립트를 붙인다. create 스크립 내부에는 Factory라는 클라스가 있어 Factory 클래스는 switch 문으로 name을 받아 그래서 name을 통해서 내가 만든 객체가 있어 이것도 써주지 iMonster가 있어 그걸 상속받은 a, b, c, e가 있어 a: iMonster, b:iMonster ㅇㅣ런식이지 그리고 create 스크립에는 iMonster라는 변수가 있어. Factory에서 나온걸 iMonster에 연결해주면 iMonster로 a,b,c,e 각자 따로 컨트롤되지 같은 스크립트를 썻는대도 말이야

[익명(183.100)]

이거 좋은점이 뭔지아냐, 레벨디자이너를 위한거야 레벨디자이너가 여러개 스크립트를 관리할필요없이 서로 다른 객체에 하나의 스크립트를 연결해서 쓸수잇다

[익명(183.100)]

개소리라니 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

[익명(183.100)]

본문에서 분명 상속을 받아서 유니티사용하는게 불편하다고 썻는데 본문처럼 쓰지말고 다른방식으로 쓰면 된다

[익명(183.100)]

개소리가 아니라 헛소리라고 써야겟네

[ㅁㅁ(14.40)]

상속 받든 안받든 팩토리 쓸 수 있고 그건 글의 요지가 아니라고 생각해서 그렇게 적었습니다. 풀링 얘기하고 있는데 왜 팩토리 얘기를 들고오시나요.

[익명(183.100)]

님이 위에 팩토리 헛소리라고 썻죠

[익명(183.100)]

아래 글의 요지는 유니티 자체가 상속에 불편하다는 건데

[익명(175.223)]

풀링을 하면서 new 를 쓰겟다는 댕청이이기때문이죠ㅋ

[익명(183.100)]

아 여기 본문에서 필요없는 글이라면 뭐 내가 사과함. 하지만 아래 글에서 필요없다고 생각하면 그건아님

[ㅁㅁ(14.40)]

183.100/ 요지는 글에 적어놨습니다.

[익명(183.100)]

기본적으로 풀만들때는 new를 쓰고 new에서 생성된 객체를 가져다 쓰는건데.. 그런데 풀링 new는 댕청은 뭐고 이건 뭐지

[ㅁㅁ(14.40)]

본문: 글에 나온 논지를 다시 정리하자면 "기반 클래스 하나에서 상속받은 클래스들을 풀링할 때 종류별로 다 만들어줘야 되니까 문제가 있다. 차라리 총알의 모든 기능을 담은 슈퍼클래스 하나를 풀링하는게 낫다." 입니다.

[ㅁㅁ(14.40)]

풀링 new 댕청 발언은 풀링 해보고 와주시면 감사하겠습니다.

[익명(183.100)]

다른건 모르겠고 이해하고 싶지도 않고 유니티에서 자꾸만 객체니 상속이니 쓸수없다 별로다 이러길래 써봤슴. 그거 아니면 내가 미안

[ㅁㅁ(14.40)]

저는 저 경우에 상속이 별로같다고 생각하는 사람이고 다른 풀링 안하는데선 상속 잘 쓰고있습니다.

[익명(183.100)]

난 반대의견이 있다고 이야기만 했을뿐 인데.. 국어 이해 능력(아래글)이 나오고 헛소리가 나오길래 좀 발끈했슴. 미안

[ㅊㅋㄴ(58.122)]

Instantiate 하나 소환해놓고 나중에 1000개를 한번에 Instantiate해도 연산속도가 지장이 없다고?

[익명(119.194)]

183.100은 국어이해능력에 문제있는거 맞음. 아래글 요지는 유니티 자체가 아니라 오브젝트풀링을 사용하려는 경우에는 상속 활용이 어렵다는거잖아. 그래서 뜬금없이 오브젝트풀링과 관계없는 팩토리 타령이나 하고 있는거겠지

[ㅊㅋㄴ(58.122)]

팩토리는 개소리 맞고

[ㅊㅋㄴ(58.122)]

asfshy는 상속관계에서의 폴링을 이해를 못하는것같음

[ㅊㅋㄴ(58.122)]

배치 이야기에서 이미 끝남 드로우콜 줄이는 배칭이야기를 여기서 왜꺼냄?

[익명(119.194)]

걔내들 이게 뭔소린지 이해를 못해서 딴소리만 하다가 지리멸렬개폭한듯

[익명(1.254)]

그새끼 설냥이애요 제가 밨서요