[💬] 클래스 관련 질문해도됨?

[익명(121.170)]

겜개발학원다니는중인데

클래스관련해서 동기랑 의견이 갈려서 그럼

NPC라는 클래스가 있을때

나는 NPC클래스를 부모로 상속받고 각각의 NPC마다 클래스를 만들어서 관리하자고 하는편인데

동기는 그냥 NPC클래스 하나로 관리하자고 하는중임

현재 포트폴리오만드는데 들어가는 NPC숫자가 5명정도밖에 안되서 지금은 가능한데 암만봐도 이렇게 관리하는건 아닌거같아서 궁금함

둘 다 이쪽에서 취직해본적이 없어서 잘 모르겟는데 정답까진 아니어도 바람직한 클래스 관리방법이 있을거같은데 어떻게 생각함?

[익명(175.193)]

상황에 따라 다르지 npc가 몇명이 들어가느냐에 따라서

[익명(175.193)]

하나를 부모로 두고서 상속받는것도 상관없음 fsm까지 적용하고 단점은 어떤 npc는 3가지 기능이 필요한데 부모는 5개의 기능이 있는데 전부 가져오게 되는데 npc 부모클래스에서 가상함수로 해주고 자식들에서 오버라이딩 해줄텐데 바로 거기서 문제가생김

[익명(121.170)]

아 그렇겠네..

[익명(175.193)]

니 얘기 들어보니까 친구가 짤려는 구조도 나중에가선 엄청 꼬이게 되있음 허나 상속도 부적절해 보임 누구는 a기능 필요하고 누구는 b기능 필요하고 상속은 최대한 같은것들끼리 묶여야됨 얘로 몬스터라고 치면 hp mp 공격력 방어력 이런건 상속으로 해둘 수 있고 나였으면 컴포넌트화 시켰음 너도 찾아봐 컴포넌트 패턴 기능별로 클래스로 찢어서 AddComponent

[익명(175.193)]

부모클래스를 두고서 행동함수 하나 만들고 enum으로 분리시킨 뒤 실행하게끔 딕셔너리도 잘 활용해보고

[익명(121.170)]

컴포넌트 패턴 찾아보고 왔는데 이렇게 클래스를 써먹는 방법도 있는지 몰랐음 ㄳㄳ

[익명(175.193)]

121 170아 한 가지 염두해야할건 뭐가 답이다 오답이다 이건 아냐 너의 친구가 하나로 퉁치는건 잘못됐어 근데 그걸 여러 cs파일로해서 컴포넌트화나 상속 안시키고 개별적으로 하기에 최선일 때가 있음. 프로그램 유형별로 나뉘어지니까 답을 찾아낼려 하지말고 한 개의 게임을 최소 두 가지

[익명(175.193)]

방법으로 짜서 나중에 비슷한 딜레마를 겪을 때 대충 어느게 최선일지 판가름이 생길텐데 프로그램엔 정답이 없음 무조건 하나 포기해야돼

[익명(175.193)]

밑에 누군가가 말한거처럼 컴포넌트화 시키면 구조가 엄격해져서 나중에가서 뭔가 수정한다거나 컴포넌트 설계랑 오차가 났을 때 그때 또 수정 해줘야할텐데 다 풀어헤쳐줘야됨 뭐가 좋다 나쁘다 이런건 없다

[익명(121.170)]

ㅇㅇ 나도 딱히 정답이 있을거라 생각은 안했지만 적어도 내가 생각한 관리방식이 더 정답에 가까울거라 생각은 했었는데 댓글들 보니 생각이 좀 많아졌음. 어쨌든 답변 ㄳㄳ

[익명(1.236)]

상속받는게 나중에 관리하기 편할걸

[익명(211.178)]

칭구가 컨텐츠 많이 안만들거니까 귀찮은거 손대지말자 이런건가 난 니 말이 맞다봄 ㅇㅇ

[익명(222.99)]

Composition Over Inheritance

[익명(125.132)]

이건 구체적인 스펙을 알기 전에는 답을 할 수 없음. NPC가 얼마나 복잡한 기능을 수행하는지, 각 NPC간에 차이가 얼마나 있는지, 최종적인 게임의 모습이 어떤건지, 뭐 이런거 알아야 추측이라도 해볼 수 있음.. 한가지 확실한 건 무조건 뭐가 뭐보다 좋다 이런건 없음

[익명(121.170)]

아 그렇구나.. 걔는 상인, 연애가능한 npc, 적대적인 몬스터 npc 싹다 NPC클래스 하나로 처리하려고 해서 골머리 썩는중임..

[익명(125.132)]

시스템 설계를 하려면 구체적인 스펙이 필요함. 그정도 정보로 명확하게 판단할수는 없어.. 그리고 그냥 듣기론 굳이 상속 받을 필요 없을 가능성도 크다고 느껴짐. 정확히 뭐때문에 상속이 필요하다고 생각했는지를 적어보셈. 그냥 다들 상속해서 만들라고 하니까 상속해야겠다 이런건 아닐거아냐

[익명(121.170)]

말했다시피 일반 npc인데 상인 npc가 가지고있는 기능인 구매 판매기능까지 가지고 있을 필요는 없다싶기도 하고 반대로 연애기능도 상인한테는 필요가 없으니 가지고 있을 필요가 없진 않잖아. 그래서 당연히 분리해서 관리해야된다고 생각했었음. 또 똑같은 상인이어도 취급하는 물품이 달라지거나 특정한 상인한테 특정한 기능을 넣고싶을때도 있고. 그래서 클래스 분리가 당연하다고 생각했었음

[익명(125.132)]

연애가능한데 상인이기도 한 경우. 적대적이지만 조건에 따라 연애도 할 수 있는 경우. 뭐 이런거 없음? 앞으로도 없다고 보장할수있음?

[익명(121.170)]

아 너가 뭔말하는지 이해간다. 그럼 연애가능 상인, 연애불가능 상인 적대적이지만 연애가능한 npc 등등 다양한 경우의 수를 두고 클래스를 만들어야되나?

[익명(125.132)]

아니 그걸 상속으로 설계하려고 하는건 아주 좋지 않은 설계임. 만일 그런거면 아예 상속을 안만들고 모든기능을 하는 커다란 NPC 클래스를 만들고 그냥 연애가능플래그 온오프 적대적 플래그 온오프 이런게 더 나을수도 있음. 이것도 구체적인 스펙을 알아야되는데..

[익명(125.132)]

만일 NPC가 아닌데 상인기능을 하는게 필요한경우 같은건 없음? 예를들면 자판기라던가.. 그냥 자판기 모양 NPC에요 라고 주장할수도 있긴한데 도저히 그렇게 안되는 경우도 생길가능성이 있을거임

[익명(125.132)]

아예 부모클래스를 상속받아 구현하는걸 배제하고 인터페이스로만 접근하는게 나을수도 있고.. 위에 누가 말한것처럼 컴포넌트 형식으로 기능을 추가하는게 나을수도 있고.. 그렇다고 무작정 최대한 유연한 구조를 쓰는것도 답이 아닌게 유연한 구조를 쓸수록 코드가 복잡해지고 보기도 유지보수하기도 불편해지니까 무조건 좋지만은 않음. 결국 아주 구체적인 스펙을 보고 알아서 잘 결정해야 되는부분임

[익명(121.170)]

위에 175 유동이 말한 컴포넌트 패턴 찾아서 잠깐 훑어보고왔는데 쟤가 말한것처럼 상인 연애기능 등등을 컴포넌트화 해서 써먹는게 좋을거같아보이네

[익명(121.170)]

아직 경험이 부족해서 너가 말한것들이 아직까진 크게 와닿지는 않는데 잘 기억해두겠음 무조건 유연한게 답이 아니긴하구나

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[익명(121.170)]

상인, 적대적 npc, 연애가능 npc 싹다 npc클래스 하나로 퉁치는중임

[익명(223.33)]

나는 제일크게 characer 부모 만들고 그 안에 npc있고 전투가 가능한 unit을 만들고 unit 안에 monster player boss가 있고 마지막으로 객체 하나를 자식으로 만들어서 관리함 이름이랑 아이디같은 다 있는 것들은 캐릭터 안에 있으니까 굳이 선언 안해줘도 펀함

[ㅇㅇㅇㅇ(14.4)]

기본적으로 npc들이 공통으로 가지고 있어야하는건 상속 나머지는 인터페이스로 구현하는건 어떰?

[익명(223.38)]

우리인붕이는 게임으로 연애하고싶노?