실제로 게임을 모델링하기 위해 다이어그램을 사용합니까? [닫은]

나는 주로 UML을 의미하지만 작동하는 모든 방법이 가능합니다. 따라서 실제로 UML / 기타 다이어그램 또는 다른 방법으로 게임을 모델링합니까? 나는 대학에서 UML을 사용한 모델링에 관한 주제를 가지고 있었고 실제 이점보다 더 많은 노력을 한 것처럼 보였지만 거대한 복잡한 IT 시스템을 만들지 않았기 때문에 그럴 수 있음을 깨달았습니다. 따라서 가치가있는 기간과 일반적으로 어떤 유형의 다이어그램 / 방법이 가장 좋은가?

* 물론 구체적인 문제를 해결하기 위해 구체적인 도구를 여러 번 선택해야하지만 패턴이있을 수 있습니다.

편집 : 나는 한 가지 중요한 일을 잊어 - 당신이 다이어그램을 생성 할 전 또는 후에 물건을 구현? 내가 의미하는 바는-하나의 디자인과 구현이 보통 마음이 바뀌거나 예상치 못한 것이 나타나고 때로는 큰 변화를 가져와야 할 때-이미 복잡한 다이어그램에서 변경하는 것은 코드 자체에서와 마찬가지로 절망적으로 보인다는 것입니다.

저는 다이어그램을 통해 우리 주변의 모든 것을 표현할 수 있다고 생각하고 싶습니다. 비록 시간이 지남에 따라 특정 개체의 상태 사이의 전환을 나타내는 선형 다이어그램 일지라도 (생존, 사망에서 여러 상태를 거치는 것처럼). 나는 실제 구현에 대한 생각과 아이디어를 제시하기 위해 다이어그램을 사용합니다. 나는 상당히 많은 것을 즉흥적으로한다.

따라서 내 다이어그램은 대부분 매우 높은 수준이며 마인드 맵 처럼 느껴집니다 .

몇 가지 예를 들기 위해, 이것은 실제로 Interactive Object가 기본 유형 인 게임에서 클래스 상속 맵 (잘려진 맵)입니다.

이것은 스파이크 트랩에 대한 FSM ( 유한 상태 머신 ) 다이어그램입니다 (스텝과 워시 스파이크가 바닥에 표시 되는 멋진 트랩 ).

이것은 내가 최근에 그린 핸드북 다이어그램입니다 (이 방법 은 종종 다이어그램으로 돌아 오기 위한 것이므로이 방법으로 명명되었습니다 ). 필요한 구성 요소와 필요하지 않은 구성 요소를 즉시 볼 수 있으므로 게임 구성 요소를 설명하고 필요한 자산을 수집하는 데 도움이됩니다. 나는 큰 프로젝트에서 꽤 커지기 때문에 작은 프로젝트에서 권장합니다. 그래도 더 넓어 질 수 있으므로 문제가 해결 될 수 있습니다.

하위 레벨로 갈 때 일반적으로 아키텍처의 가장 복잡한 측면을 계획해야하기 때문에 대개 UML을 처리합니다. 나는 절대적으로 깨끗하고 올바른 UML을 출력하는 데 집중하지 않습니다. UML 규칙에서 가장 마음에 드는 것을 채택하여 멋진 마인드 맵 UML로 바꿨습니다. 간단하고 나를 위해 일을하지만, 분명한 이유로 실제 UML이 예상되는 환경에서는 사용하지 않을 것입니다.

더 낮은 수준으로 가야 할 또 다른 상황은 실제 알고리즘을 설명해야 할 때입니다. 나는 흐름도 라고하는 것을 사용한다 . 화이트 박스 테스트에 사용 된 다이어그램에서 영감을 얻은 형식 입니다.

내가 지금 당긴 스파이크 트랩의 샘플은 다음과 같습니다.

이것은 일반적으로 다이어그램과 실제 알고리즘 구현 사이의 마지막 계층입니다. 필요한 경우 흐름도를 자세히 설명하고 (추가로 실행 된 명령 사용) 복잡성을 추론 또는 추정하고 정확한 테스트 사례를 작성합니다. 또한 의사 코드보다 다이어그램을 선호합니다.

게임 개발과 관련이있는 것이 아니라 멀티 스크린 앱의 화면, 사용자가 각 화면에서 트리거 할 수있는 기능 및 화면 간의 관계를 설명하는 형식도 있습니다. 나는 보통 실제 개발을 시작하기 전에 이것을 구축하고, 개발 프로세스 전체에서 맵처럼 행동합니다. 클라이언트의 경우 화면 다이어그램이 훨씬 유용합니다! 처음부터 시작하여 모든 프로젝트를 진행하는 데 도움이되고 필요한 모든 기능을 고려합니다. 따라서 정확한 비용 및 시간 추정치를 제공하는 것이 매우 중요합니다.

그래, 나는 모든 것을 확실히 도표화했다. 아이디어가 있다면, 그것에 대한 다이어그램을 그릴 수 있습니다. 어떻게 든 백업을 위해 최소한 매우 넓은 다이어그램없이 프로젝트를 시작하면 난처한 느낌이 듭니다.

나는 구조적, 행동 적 모두를 확실히한다. 내 경험상 다이어그램을 만드는 데 드는 비용이 한 달 후 내가 생각한 것을 기억하려고 노력하는 것보다 적거나 다이어그램을 명확하게 설명해야 할 때 다른 개발자

상속 계층이 충분히 복잡 할 때 클래스 다이어그램

객체의 인스턴스화와 같은 것이 이질적인 부분에서 Frankenstein 괴물을 만들 때 경계가되는 객체 다이어그램-특히 주방 싱크 정점 및 픽셀 쉐이더 사용자에게 유용하며 모든 필수 비트가 파이프를 통해 푸시되도록합니다.

일련의 객체들 사이의 상세한 상호 작용이 복잡해 졌을 때의 시퀀스 다이어그램-이것은 거의 관련이없는 다운 스트림 위치에서 이전에 계산 된 정보가 필요한 복잡한 렌더 플로우 모델링에 매우 유용합니다.

다이어그램은 디자인을 전달하고 문서화하고 도움을주는 훌륭한 방법 이며 디자인은 소프트웨어 개발에서 가장 중요한 부분입니다. UML에는 많은 기능이 있지만 동시에 모든 기능을 사용할 수는 없으며 유용한 기능 만 사용할 수 있습니다.

새로운 도시를 탐색 할 때 계속 표지판을 따라 가기보다는 실제로 멈추고지도를 보십니까? 그것이 디자인과 코딩에 관한 것입니다. 익숙하지 않은 경우, 문제가 복잡 할 때, 길을 잃었을 때, 디자인에 대해 생각하는 것이 가장 도움이되는 것입니다.구현하기 전에 디자인을 변경하는 것이 훨씬 쉽습니다 .

다이어그램 (어느 특히 시각적 인 사상가에 대한 문제를 시각화하고 설계를 도울 수있는 좋은 방법입니다 우리의 대부분 내가 상상하는 것 gamedev에). 다이어그램에 명확하게 매핑되면 많은 문제가 사소 해지며 결함이 분명해집니다. 다이어그램에서 찾을 수있는 몇 가지 문제 :

• 단일 구성 요소에 너무 많은 연결이 있습니까? 유지하기 어려운 신 물체 가있을 수 있습니다
• 상호 연결이 너무 많습니까? 아마 모듈화 아키텍처가 덜 취약하게 개선 할 수있다
• 두 구성 요소 사이에 너무 많은 경로가 있습니까? 아마도 당신은 단단한 커플 링이 있습니다
• 게임과 같은 고성능 응용 프로그램의 경우 핫 경로 또는 내부 루프에 너무 많은 구성 요소가 있습니까? 성능에 영향을 줄 수 있습니다
• 그러나 대부분의 경우 다이어그램에는 계획 한 디자인과 실제 구현 간의 불일치가 표시됩니다.

또한 다이어그램은 기술이 아닌 사람들이나 프로젝트를 처음 접하는 사람들에게 디자인을 전달하고 문서화하는 데 유용합니다. 6 개월 안에 프로젝트를 실제로 처음 접하는 사람들도 기억하십시오!

UML을 사용하는 방법은 이러한 고려 사항에서 비롯되어야합니다. 자신을위한 다이어그램? 가장 편한 표기법을 사용하십시오. 다른 개발자들과 협력하고 있습니까? API 호출, 메시지 유형, 종속성 방향에 대한 세부 정보를 포함 시키십시오. 건축 논의? 블랙 박스 와 간단한 연결로 충분합니다. 어쨌든 전체 UML 기능 세트를 사용하는 사람은 없으며 , 많은 사람들이 이해하는 표준화 된 표기법 세트로 매우 유용합니다. 반면에 내 냅킨 낙서는 이해할 수 없으며 그 반대도 마찬가지입니다.

나 자신은 항상 개인 프로젝트를위한 간단한 메모장 그림, 직장에서 간단한 UML 다이어그램을 사용합니다. 이 UML 다이어그램 은 내가 너무 복잡하다고 생각하는 것으로, 생성 및 유지 관리 비용이 그 이점을 능가하지만 물론 YMMV보다 크기 때문에 결코 만들지 않을 것입니다.

두 가지 유형의 다이어그램이 있다고 말하고 싶습니다. 공식 다이어그램 및 낙서.

공식 다이어그램과 관련하여 다른 프로그래머와 함께 작업 할 때는 다이어그램을 작성하지만 프로그래밍 만 할 때는 거의 사용하지 않습니다.

그러나 이것이 내가 생각하고 떠오르는 것을 코딩한다는 의미는 아닙니다. 제 생각에는 프로그래밍 (또는 실제로 인생의 어떤 것)을 할 때 가장 중요한 것은 먼저 생각하고 나중에하는 것 입니다.

코딩은 매우 기계적인 작업입니다. 입력하고 단어가 화면에 나타납니다. 아이디어는 코딩을 시작할 때 문제를 이미 해결 했어야한다는 것입니다. 낙서를하는 것은 생각을 분류하고 코딩 부분을 올바르게 수행해야한다는 생각을 강요 할 수있는 좋은 방법입니다. 낙서는 나중에 참조 할 수 있도록 저장되어 있지 않으므로 생각 과정을 쉽게 이해할 수 있습니다.

생각하는 데 너무 많은 시간이 걸리더라도 걱정하지 마십시오. 생각하는 시간의 90 %와 코딩의 10 %를 바칠 때 균형이 잘 잡힌다고 생각합니다. 나는 "우리는 생각할 시간이없고 그냥 할 시간이 없다"고 사는 몇몇 "고급"프로그래머들을 만났다. 그러나 그들이하고있는 일에 대해 생각하는 데 시간을내는 사람들보다 먼저 코드를 "완료"라고하더라도, 그들은 (나중에 운이 좋지 않은 영혼들은) 올바르게 구축해야 할 것을 고치고 패치하는 데 많은 시간을 보냅니다. 처음부터.

가장 좋은 것은 사고가 자유 롭다는 것입니다! 생각하기 위해 컴퓨터에 앉아있을 필요는 없습니다. 식사, 통근, 운동을하는 동안 코드에 대해 생각할 수 있습니다 ... 사실, 가장 좋은 아이디어는 최소한 기대할 때만 나오므로 항상 마음을 열어두고 실제로 자신이 무엇을 알고있을 때만 코딩을 시작하십시오. 코딩하려고합니다.

여기 에 동의 하는 관련 기사 가 있습니다.

편집 : 다이어그램의 실제 형식 및 유형에 대해서는 프리 패키지 도구를 사용하는 대신 자유형으로 작성하고 실제로 필기하는 것이 좋습니다. 요점은 당신의 사고 과정에서 당신을 돕는 것이므로, 당신이 원하는 것을 자유롭게 그릴 수 있습니다. 시맨틱은 원하는대로이며 다이어그램마다, 심지어 다이어그램의 다른 부분에서도 다를 수 있습니다.

사전 패키징 된 도구에 비해 프리 스타일 / 필기 다이어그램의 세 가지 주요 이점이 있습니다.

1. 선택한 도구가 지원하는 다이어그램 유형을 따르지 않아도됩니다. 때때로 맵 마인드가 작동하고 때로는 UML과 같은 것이 좋으며 다른 경우에는 논리 다이어그램이 작동합니다. 다른 경우에는 완전한 사용자 정의 다이어그램이 효과가 있으며, 어떤 도구도 자유형 다이어그램의 모든 유연성을 제공 할 수 없습니다 (종이에 구멍을 뚫고 용지의 반대쪽에서 좋아하는 패키지로 계속 시도하여 어떤 일이 발생하는지 확인)

2. 도구를 사용하는 대신 실제로 다이어그램을 작성하는 데 더 많은 시간이 소요됩니다. 도구에 관계없이 펜과 종이는 키보드를 사용하고 메뉴를 마우스로 이동하여 원하는 특정 요소를 찾는 것보다 항상 다이어그램 작업이 더 빠릅니다.

3. 필기를하기 위해 컴퓨터가 필요하지 않습니다. 복잡한 디자인을하는 대부분의 경우, 도서관, 카페 또는 비행기 안에서도합니다. 또한 좋은 아이디어는 항상 가장 적절한 순간에 표시되므로 항상 쓸 내용과 쓸 내용을 항상 지니고 있어야합니다.

2013 년 게임 개발자 컨퍼런스 (Game Developers Conference 2013)에서 몇 가지 디자인 다이어그램 대화를 언급 할 가치가 있습니다. 이것은 매우 실용적이고 도로 테스트를 거친 몇 가지 예입니다.

(다른 답변은 설계 중심 다이어그램이 코드베이스 계획, 구축, 성장 및 유지 관리에 큰 도움이 될 수있는 이유와 방법을 보여주는 훌륭한 작업을 수행 했으므로 이러한 측면 만 남겨두고 이러한 리소스가 도움이 될 것입니다 질문을하는 사람에게.)

Joris Dormans와 Ernest Adams는 Machinations 게임 디자인 / 밸런스 다이어그램 시스템에 대해 논의했습니다 . ( GDC EU 2012 의 유료 월페이퍼 GDC Vault 비디오 는 Dormans 위키의 GDC 2013 샘플 입니다.) 다음은 위키에서 시스템을 설명하는 방법입니다.

Machinations는 게임을 동적 시스템으로 설명하고 닫힌 피드백 루프에 초점을 맞추는 이론적 인 프레임 워크 및 대화식의 동적 그래픽 표현입니다. 의도는 게임 구조를 방법 론적으로 표현하고 조사하는 방법을 찾는 것입니다. Machinations는 직관적이고 섬세한 게임 디자인 및 밸런싱 연습에 새로운 렌즈를 제공합니다.

Noah Falstein은 "The Arcane Art of Puzzle Dependency Diagrams"( GDC Vault 비디오 지불)라는 강연을했습니다 . 나는 유료 벽이없는 링크를 찾을 수 없지만 다양한 사람들이 온라인으로 메모를 토론하거나 게시했습니다.

두 강연은 그들이 언제 만들어 졌는지 그리고 어떻게이 다이어그램들을 어떻게 유지했는지에 대해 논의했습니다.

게임 플레이 루프를 설명하기 위해 간단한 추상 문법을 사용하는 방법, 디자인 문제를 식별하는 데 도움이되는 방법 및 해당 수준에서 반복하는 것이 얼마나 쉬운 지에 대해이 기사를 확인해야합니다.

http://www.gamasutra.com/blogs/JoshuaStarner/20130205/186060/Applying_Abstract_Models_to_Game_Design.php

또한 기회, 행운 또는 준비와 같은 것들을 추적하기 위해 추상 리소스를 사용하여 게임 플레이 루프의 경제학을 기반으로 주제에 대한 내 자신의 작업을 지시 할 수 있습니다.

http://www.stephanebura.com/diagrams/

이 접근 방식이 유용하다고 생각되면 이러한 다이어그램을 만들고 시뮬레이션을 실행하는 도구 인 Joris Dormans 'Machinations를 살펴보십시오.

http://www.jorisdormans.nl/machinations/

그의 모든 과정은 그의 책에서 설명됩니다 :

http://www.amazon.com/Game-Mechanics-Advanced-Design-Voices/dp/0321820274/