생각 ¶
- DX의 CMyApp는 View가 될테고, Doc가 될 클래스를 하나 추가해주자.
- CArObject 에서 상속받은 CARHero와 CARMonster가 있다.
- CArHero에서 상속받은 검사, 창사 이런게 있을테다.
- CARMonster를 상속받는 CARColdMon, CARFireMon등등이 있다.
- 보스는 각각의 CAR~~~Monr를 상속받으면 될거같다.
- 정령을 상속받는 어쩌구 저쩌구 정령
- 아이템을 상속받는 착용가능한 아이템, 소모성 아이템 등등
- 착용가능한 아이템은 정령을 가지고 있다.
- 맵도 있다. 맵은 데이터를 읽어와서 맵의 정보를 저장한다.
Thread ¶
그런데 왜 저렇게 복잡하게 상속을 받아야 하는걸까, CARMonster클래스가 모든걸 갖고 있어도 충분히 처리가 가능할 것같은데 --선호
확장 가능성 때문이 아닐까. 몬스터 행동 패턴이 있다고 했을때 CARMonster가 모든걸 갖고 있다면 if(슬라임) ~ else if(박쥐) ~ 이런 코드가 나올거 아니냐. 저런 코드는 제거 대상 1호중의 하나랜다.
그러면 늘어나는 클래스의 관리는 어떻게 하면 쉽게 할 수 있을까..??그런건가.. -_-생각보다 꽤나 복잡하군... 에헤~
나중에 DLL로 바꾸면 가시적인 클래스 수는 많이 줄어들겠지
Behavior ¶
CARMonster ¶
- 이동 페턴을 가져야 한다. 예를 들어 주인공을 향해 이동을 하게끔 만들거나 이동을 하되, 맞으면 도망가는 형식, 또 보면 무조건 도망가는 방식 등이 있겠다. 여기서 많은 문제가 생길꺼라 생각한다.
- 떨어뜨리는 아이템 종류가 있어야 한다. 어떠한 확률로 어떤 아이템을 떨어뜨릴 것인지, 그리고 죽은 후 떨어뜨리는 것을 구현해야 한다.
- 주인공에게 능력치를 얼만큼 줄지 생각을 해야 한다. 이를 계산하여 넘겨주기 위해 몬스터도 경험치를 가져 그것을 계산하는 방법도 있다. 이런 방법을 구현할려면 오브젝트에서 경험치를 처리하는 수도 있다.
- CARMonster는 죽으면서 자신의 레벌과 경험치를 CARHero에게 넘겨준다. 그러면 CARHero는 자신의 레벨과 비교해서 경험치를 공식에 따라 올린다.
CARInstanceItem ¶
- CARItem을 상속은 받지만 장착은 불가능한 아이템이다.
- CARItem은 그것을 사용한 CARHero의 상태를 변화시켜 줄수 있다.
생각을 해 보니까요. 이스처럼 전투가 이루어진다면 물약이 있다면 굉장히 게임이 쉬워지고 또 재미가 반감될꺼 같아요. 실제 요즘에 나오는 게임들 중에서 물약이 없는 게임들이 많이 나왔거든요. 물약 노가다가 게임을 반감시킨다는 이유에서요 -상욱
그래서 이스에서는 물약을 하나로 제한해놨거든. 우리도 물약을 안 넣고, 그냥 정령으로 때워도 될거 같기도 하다. 또 컨트롤을 강요해서, 컨트롤만 잘하면 안 맞고도 플레이가 가능한 식으로 가도 될테고.. 그러면 이건 없애도 되는건가?