설계를 하는 이유는 품질을 향상하기 위해서이다.
품질을 향상하기 위해서는 새로운 기능을 추가하기 쉽고, 유지 보수가 편리해야한다.

시스템을 각 구성하는 요소를 모듈이라고 부르며,
모듈을 추가하거나 수정할 경우 파급효과를 최소화하는
모듈 독립성
이 기본으로 갖추어져야 한다.
비슷한 기능은 최대한 모아서 하나의 모듈의 응집도를 높이고,
다른 모듈과의 결합도를 줄이는 것이 핵심이다.

모듈과 모듈간의 결합은 이해도 높게 작성되어야 한다.
이해도를 높이기 위해서는 먼저 시스템을 여러개의 독립된 서브 시스템으로 나누어
규모를 줄여야 한다. 서브 시스템으로 나눈 이상 서브 시스템간 통신은 필수적이다.
최소한의 통신을 위해 결합도를 낮추고, 불필요한 정보는 감춘다.
코드 컨벤션과 문서은 시스템 이해가 큰 도움이 된다.

시스템의 환경은 계속적으로 변해 가기 때문에 적응도가 높아야 한다.
적응도는 환경 결합도가 낮고, 내부 응집도가 높다는 이야기이다.

외부 환경과 결합할 수 밖에 없는 부분은 최대한 작게 지역화해서
최소한의 수정으로 변화에 적응할 수 있어야 한다.



이올린에 북마크하기(0) 이올린에 추천하기(0)
2009/06/10 17:57 2009/06/10 17:57
요구 사항 분석과 개발(설계)의 가장 큰 차이점은 관점이다.

사용자 관점에서 바라보는 것이 요구 사항 분석이며
개발자 관점에서 바라보는 것이 개발 (설계) 이다.

요구 사항 분석는 프로그래머가 진행하는 경우가 많은데,
프로그래머의 관점, 다시 말해 "어떻게 만들까" 를 먼저 생각하기 때문에
문제가 생기는 경우가 많다.

요구 사항 분석을 잘 해내는 가장 쉬운 방법은
엄마에게 내가 만드는 프로그램에 대해 설명해보는 것이다,

"엄마, 내가 프로그램 만드는데..."

" 만드는데?"

그렇다. 사용자가 알고 싶은건 "무엇을 만드냐"라는 것이다.

엄마가 3D 프로그래머 출신이 아닌 이상
Direct3D 로 만들지 OpenGL 을 만들지는 중요하지 않다.

"MMORPG"

"MMORPG 가 냐-_-)?"

"캐릭터가 움직이면서 몬스터 잡으면서 레벨올리는거예요"

"캐릭터-_-)? 몬스터-_-)? 레벨-_-)? 그게 뭐여?"

... 아 orz;

엄마처럼 아무것도 모르는 경우는 용어 정립부터 필요하다는 사실을 깨닫게 되는군...

좀 더 픽션을 가미해서 엄마가 워우 광렙 유저라고 가정해보면 좀 더 편할 듯 하다.

"음.. 그래-_- 엄마가 MMORPG 는 알겠는데.. 게임의 목적니?"

이런 식으로 풀어나가는 과정이 요구 사항 분석이다.

이올린에 북마크하기(0) 이올린에 추천하기(0)
2009/06/10 17:00 2009/06/10 17:00
다음은 Window 시스템의 전형적인 모양이다.


class Window:
def __init__(parent):
"생성시 부모에 자신을 추가한다"
self.parentRef = ref(parent) # 부모-자식간 재귀 레퍼런스 방지
self.children = []

if parent:
parent._AppendChild(self) # 부모가 있다면 자식으로 추가한다.

def Close(self):
"닫기: 부모로부터 자신을 제거한다"
parent = self._GetParent()
if parent:
parent._RemoveChild(self)

def _AppendChild(self, child):
"자식을 추가한다"
self.children.append(child)

def _RemoveChild(self, child):
"자식을 제거한다"
self.children.remove(child)


복잡한 형태라도 윈도우 구조를 사용하면 간편하게 구현된다.

꽤나 복잡한 형태의 윈도우 조합 중 하나가
퀵 스킬 아이콘 슬롯였는데...

생각외로 의외로 복잡하다.

1) 일단 아이콘이 보여야 하고
2) 버튼처럼 선택이 되어야 하며
3) 쿨타임 애니메이션을 보여줄 수 있어야 하고
4) 쿨타임이 끝나면 번쩍하는 애니메이션이 나오며
5) 버프 스킬이라면 사용중이라는 애니메이션을 보여주어야 하고
6) 토글 스킬이라면 토글OFF 상태애니메이션과 토글ON 상태 애니메이션을 구분해서 보여주어야 한다.

실제로는 좀더 많은 기능이 있지만
비주얼적인 특성은 이러하다.

만드는 방법은 두가지이다.
1)  모든 기능을 포함한 새로운 컨트롤을 만든다.
2)  기존에 만든 컨트롤을 조합해서 만든다.
지금까지는 Window 구조를 사용해서 2번식으로 만들어왔다.


class QuickSkillSlot(Window):
def __init__(self, parent):
Window.__init__(self):
self.iconBox = IconBox(self)
self.button = Button(self)
self.coolTimeAniBox = AniBox(self)
self.usableAniBox = AniBox(self)
self.usingAniBox = AniBox(self)
self.toggleOnAniBox = AniBox(self)
self.toggleOffAniBox = AniBox(self)


아-_- 아름다워라...

지금까지는 윈도우 트리 구조를 사용해서 바로 렌더링했기 때문에
별 문제가 없었다.

문제는 최근 겜브료의 프레임 렌더링 시스템으로 포팅하면서 발생했다.
사실 게임에 있어 복잡한 부모-자식 구조는 그닥 필요한게 아니다. 맞는말이다.
렌더링 관점에서만 보면 하나의 화면 뷰에 화면 요소 목록만 있는 것이 렌더러 입장에서는
제일 단순하며 아름답다. 화면 뷰순서 바꾸는 정도면 충분한 배려라고 볼 수 있다.

그렇다면 어떻게 이 둘의 구조를 만족시킬 수 있을까?

물론 해답은 명백했다.
루트 윈도우 바로 아래에 있는 메인 윈도우들은 화면뷰로 만든다.
메인 윈도우는 아래 자식들을 탐색해 화면 요소 리스트를 뽑아내 등록하면 된다.

말은 쉬운데...
왜 막상 코딩에 들어가면 잘 안되는 것인지... orz;


그래서 머리속 생각을 정리해보기로 했다.

가장 무식한 구현은 간단하다.
매 프레임마다 모든뷰를 지우고 화면 뷰와 그에 따른 화면 요소 리스트를 구축하는 것이다.
하지만 모든 윈도우를 탐색하는건 매프레임하기에는 너무 부담된다.

두번째 방법-_- 흠...
루트 윈도우에 등록되는 녀석들은 화면 뷰를 만든다.
그 자식들에게 화면뷰를 모두 전달해 각자의 화면 요소들을 등록시킨다.
만약 자기가 제거된다면 화면뷰에서 자신이 갖고 있는 화면 요소들을 제거한다.

웃 -_-); 왠지 그럴싸한데...

일단 구조만 잡아본 프로토타입~~

more..



이올린에 북마크하기(0) 이올린에 추천하기(0)
2009/04/02 13:17 2009/04/02 13:17