저는 다이어그램을 통해 우리 주변의 모든 것을 표현할 수 있다고 생각하고 싶습니다. 비록 시간이 지남에 따라 특정 개체의 상태 사이의 전환을 나타내는 선형 다이어그램 일지라도 (생존, 사망에서 여러 상태를 거치는 것처럼). 나는 실제 구현에 대한 생각과 아이디어를 제시하기 위해 다이어그램을 사용합니다. 나는 상당히 많은 것을 즉흥적으로한다.
따라서 내 다이어그램은 대부분 매우 높은 수준이며 마인드 맵 처럼 느껴집니다 .
몇 가지 예를 들기 위해, 이것은 실제로 Interactive Object가 기본 유형 인 게임에서 클래스 상속 맵 (잘려진 맵)입니다.
![대화 형 객체는 기본 유형입니다](https://i.stack.imgur.com/1s2Re.jpg)
이것은 스파이크 트랩에 대한 FSM ( 유한 상태 머신 ) 다이어그램입니다 (스텝과 워시 스파이크가 바닥에 표시 되는 멋진 트랩 ).
![간단한 스파이크 트랩을위한 FSM 다이어그램](https://i.stack.imgur.com/YNWYK.jpg)
이것은 내가 최근에 그린 핸드북 다이어그램입니다 (이 방법 은 종종 다이어그램으로 돌아 오기 위한 것이므로이 방법으로 명명되었습니다 ). 필요한 구성 요소와 필요하지 않은 구성 요소를 즉시 볼 수 있으므로 게임 구성 요소를 설명하고 필요한 자산을 수집하는 데 도움이됩니다. 나는 큰 프로젝트에서 꽤 커지기 때문에 작은 프로젝트에서 권장합니다. 그래도 더 넓어 질 수 있으므로 문제가 해결 될 수 있습니다.
![게임 개요](https://i.stack.imgur.com/V8HqE.jpg)
하위 레벨로 갈 때 일반적으로 아키텍처의 가장 복잡한 측면을 계획해야하기 때문에 대개 UML을 처리합니다. 나는 절대적으로 깨끗하고 올바른 UML을 출력하는 데 집중하지 않습니다. UML 규칙에서 가장 마음에 드는 것을 채택하여 멋진 마인드 맵 UML로 바꿨습니다. 간단하고 나를 위해 일을하지만, 분명한 이유로 실제 UML이 예상되는 환경에서는 사용하지 않을 것입니다.
더 낮은 수준으로 가야 할 또 다른 상황은 실제 알고리즘을 설명해야 할 때입니다. 나는 흐름도 라고하는 것을 사용한다 . 화이트 박스 테스트에 사용 된 다이어그램에서 영감을 얻은 형식 입니다.
내가 지금 당긴 스파이크 트랩의 샘플은 다음과 같습니다.
![더 자세한 스파이크 트랩 순서도](https://i.stack.imgur.com/URUyU.jpg)
이것은 일반적으로 다이어그램과 실제 알고리즘 구현 사이의 마지막 계층입니다. 필요한 경우 흐름도를 자세히 설명하고 (추가로 실행 된 명령 사용) 복잡성을 추론 또는 추정하고 정확한 테스트 사례를 작성합니다. 또한 의사 코드보다 다이어그램을 선호합니다.
게임 개발과 관련이있는 것이 아니라 멀티 스크린 앱의 화면, 사용자가 각 화면에서 트리거 할 수있는 기능 및 화면 간의 관계를 설명하는 형식도 있습니다. 나는 보통 실제 개발을 시작하기 전에 이것을 구축하고, 개발 프로세스 전체에서 맵처럼 행동합니다. 클라이언트의 경우 화면 다이어그램이 훨씬 유용합니다! 처음부터 시작하여 모든 프로젝트를 진행하는 데 도움이되고 필요한 모든 기능을 고려합니다. 따라서 정확한 비용 및 시간 추정치를 제공하는 것이 매우 중요합니다.
그래, 나는 모든 것을 확실히 도표화했다. 아이디어가 있다면, 그것에 대한 다이어그램을 그릴 수 있습니다. 어떻게 든 백업을 위해 최소한 매우 넓은 다이어그램없이 프로젝트를 시작하면 난처한 느낌이 듭니다.