아무리 생각해도 몬스터 하나하나 클래스 파서 만드는건 아니라고 보는데 문제는 기준점을 모르겠다는거
등급? 공격 타입? 종류? 뭔가 하나로 나누어 떨어지지 않음
종류로 크게 나누고, if문으로 타입, 등급별 공격 방식이나 드랍 아이템 떨구거나 그렇게 만들고 보스는 별도로 해야하나
이미 겪어보신 분들의 조언이 필요함...
- dc official App
댓글 6
제 방식이 맞는지는 모르겠지만은..
몬스터컨트롤러 - 주로 이벤트 담당
하위 객체 몬스터컨텍스트 - 허브 역할
컨텍스트 밑으로 데이터(스탯 등), 애니메이션, AI(NavMesh + FSM), 이펙트(피격 효과나 셰이더 등) 이렇게 있고..
AI에 들어갈 컨픽에 따라 몬스터 패턴이 바뀜
여기서 상속 구조는 없음
211214(tomatoss)2025-03-01 00:05:00
나같은 경우에는 루아 스크립트 사용해서 몬스터 하나 당 스크립트 하나를 만들었음
익명(210.204)2025-03-01 00:07:00
답글
필요한 변수는 싹 다 몬스터 클래스가 가지고 있을거 아님
스테이트 머신이 스크립트를 읽어서 각 스테이트 시작/진행/끝/전환을 처리하면 됨
익명(210.204)2025-03-01 00:08:00
나라면 (유니티 기준으로) 컨포넌트처럼 몬스터 행동을 만들었을 것 같아. 상속을 사용하겠다면 class MoveBase를 만들어서 class MoveType1, MoveType2..에 상속시키는거야.
몬스터에게 MoveBase move; 변수 걸고 move = new MoveType1();로 정의하면 몬스터마다 다르게 이동 방법을 설정할 수 있어.
ㅇㅇ 1(219.240)2025-03-01 00:34:00
답글
실제로 몬스터를 이동시키고 싶다면 매개변수로 몬스터 정보를 넘겨서 move(this.monster); 식으로 처리하면 되지 않을까? 공격, 아이템 드롭 등등도 분류 가능하고. 필요하면 몬스터에 MoveBase[] moves; 만들어서 조건따라 다른 이동 방식도 호출할 수 있을 듯?
ㅇㅇ 1(219.240)2025-03-01 00:36:00
의외로 몬스터 하나하나 다 따로 만드는 게 정답일 수도 있어.
대신 공용 메서드들은 인터페이스로 정의해서 적어도 그건 상속시켠놔야지.
몬스터가 추가돼도 기존 코드를 수정할 필요가 없어지는 장점이 있음.
다만 거의 완벽한 코드를 쓰는 몬스터들이 나올 수 있는데, 그것들에 대한 처리는 나중에 리팩토링하면서 코드를 합칠 수는 있지
제 방식이 맞는지는 모르겠지만은.. 몬스터컨트롤러 - 주로 이벤트 담당 하위 객체 몬스터컨텍스트 - 허브 역할 컨텍스트 밑으로 데이터(스탯 등), 애니메이션, AI(NavMesh + FSM), 이펙트(피격 효과나 셰이더 등) 이렇게 있고.. AI에 들어갈 컨픽에 따라 몬스터 패턴이 바뀜 여기서 상속 구조는 없음
나같은 경우에는 루아 스크립트 사용해서 몬스터 하나 당 스크립트 하나를 만들었음
필요한 변수는 싹 다 몬스터 클래스가 가지고 있을거 아님 스테이트 머신이 스크립트를 읽어서 각 스테이트 시작/진행/끝/전환을 처리하면 됨
나라면 (유니티 기준으로) 컨포넌트처럼 몬스터 행동을 만들었을 것 같아. 상속을 사용하겠다면 class MoveBase를 만들어서 class MoveType1, MoveType2..에 상속시키는거야. 몬스터에게 MoveBase move; 변수 걸고 move = new MoveType1();로 정의하면 몬스터마다 다르게 이동 방법을 설정할 수 있어.
실제로 몬스터를 이동시키고 싶다면 매개변수로 몬스터 정보를 넘겨서 move(this.monster); 식으로 처리하면 되지 않을까? 공격, 아이템 드롭 등등도 분류 가능하고. 필요하면 몬스터에 MoveBase[] moves; 만들어서 조건따라 다른 이동 방식도 호출할 수 있을 듯?
의외로 몬스터 하나하나 다 따로 만드는 게 정답일 수도 있어. 대신 공용 메서드들은 인터페이스로 정의해서 적어도 그건 상속시켠놔야지. 몬스터가 추가돼도 기존 코드를 수정할 필요가 없어지는 장점이 있음. 다만 거의 완벽한 코드를 쓰는 몬스터들이 나올 수 있는데, 그것들에 대한 처리는 나중에 리팩토링하면서 코드를 합칠 수는 있지