게임 계획 및 소프트웨어 디자인? UML이 편리하지 않다고 생각합니다

우리 대학에서는 항상 UML 디자인과 물건에 대해 강조하고 과장하여 게임 구조 디자인과 잘 어울리지 않을 것이라고 생각합니다. 이제 게임 디자인을 어떻게 시작해야하는지에 대한 전문적인 조언이 필요합니다. 이야기는 프로그래밍에 약간의 기술이 있으며 일부 2D 플랫 포머를 확장시키는 것과 같은 많은 사소한 게임을 해왔다는 것입니다. 내 프로그램에서 찾은 문제는 품질이 좋지 않은 디자인입니다. 잠시 동안 코딩 한 후 계획이 좋지 않아 문제가 발생하기 시작합니다 (새 기능을 추가하면 전체 프로그램을 다시 코딩해야하는 경향이 있습니다). 그러나 단일 설계 결함없이 모든 것을 계획하는 것은 약간 이상적입니다. 따라서 게임을 어떻게 계획해야하는지 조언이 있습니까? 저와 제 친구들이 디자인을 개관 할 수 있도록 어떻게 사진을 눈에 띄게 배치해야합니까?

친구와 게임을 코딩 할 계획이었습니다. 이것은 나의 첫 번째 팀워크가 될 것이므로 전문적인 조언은 즐거움이 될 것입니다. UML 이외의 다른 대안이 있습니까?

또 다른 질문은 "프로토 타이핑"은 일반적으로 어떻게 보이는가입니다.

게임 디자인을 어떻게 시작해야하는지에 대한 전문적인 조언이 필요합니다.

게임 디자인은 게임 플레이, 자산, 스코어링 시스템 등의 사양입니다. 소프트웨어별로 다릅니다. 따라서 UML은 해당 작업에 잘못된 도구입니다.

이러한 시스템을 구현하기위한 코드를 디자인 할 때 UML은이 작업을 수행하기에 좋은 도구이며 팀에이를 알려주고보다 일반적인 다이어그램 유형을 고수합니다. 일반적으로 기능을 디자인하려고 할 때 설명이나 다이어그램 중 어느 것을 사용해야하는지 알 수 있습니다. 다이어그램을 사용해야 할 경우 UML은 표준 드로잉 방법을 제공합니다.

잠시 동안 코딩 한 후 계획이 좋지 않아 문제가 발생하기 시작합니다 (새 기능을 추가하면 전체 프로그램을 다시 코딩해야하는 경향이 있습니다).

이는 일반적으로 계획 방식이 아니라 프로그래밍 방식에 문제가 있습니다. 좋은 소프트웨어는 일반적으로 확장하고 재사용하기 쉽습니다. 좋은 프로그래밍 방법을 고수하면이 문제가 줄어 듭니다. 그러나 더 나은 계획은 도움이 될 것이며 복잡한 다이어그램은 필요하지 않습니다. 기능 목록 만 있으면 한 가지를 코딩 할 때 다른 기능을 염두에두고 코딩 할 때 고려할 수 있습니다.

따라서 게임을 어떻게 계획해야하는지에 대한 조언이 있습니까? 저와 제 친구들이 디자인을 개관 할 수 있도록 어떻게 사진을 눈에 띄게 배치해야합니까?

게임 디자인과 코드 디자인이라는 두 가지 문제를 섞은 것처럼 들립니다.

먼저 필요한 기능, 필요한 그래픽 및 사운드, 게임의 승패 방법 등을 지정하는 기본 게임 디자인을 작성하는 것이 좋습니다. 도움이 필요하면 '디자인 문서'를 찾아보십시오.

여기에서 코드 작성에 필요한 기능에 대한 아이디어를 얻게됩니다. 각 기능을 차례로보고 구현 방법에 대해 생각할 수 있습니다. 다이어그램은 게임에서 다른 클래스와 객체 간의 관계를 표시하는 데 도움이 될 수 있지만 어떤 객체가 있어야하는지 아는 기술은 연습 및 / 또는 추가 독서를 통해 배워야하는 것입니다.

또한 규모가 작고 야심 찬 프로젝트를 수행하십시오. 이를 통해 광범위한 계획이나 재 작성 없이도 작업 코드를 작성하는 데 익숙해집니다.

무언가를 이해하지 못하면 쉽게 해산 할 수 있습니다. UML은 구조화 된 방식으로 아이디어를 전달하는 데 사용되는 엔지니어링 도구입니다. 게임은 다른 것과 마찬가지로 엔지니어링 될 수있는 시스템입니다. 어쨌든 게임의 복잡성과 역동 성은 게임의 일부와 상호 작용을 시각적으로 표현하여 귀중한 가치를 만듭니다.

UML 다이어그램은 논의중인 시스템 모델의 다른보기입니다. 내 프로그램 앞에 앉아 시작하는 사람에 대한 사용 사례로 시작합니다. 게임의 경우 두 종류의 사용자가 있습니다 : 디자이너와 플레이어. 나는 그들이 볼 수있는 각각의 일에 유스 케이스를 씁니다. 그런 다음 어떤 서비스를 제공해야하는지 파악하기 위해 CRC 카드를 만듭니다. 그런 다음 이러한 서비스와 해당 관계를 제공 할 인터페이스에 대한 클래스 다이어그램을 작성합니다. 이것은 CRC 카드를 기반으로합니다. 다음은 계획 및 오케스트레이션이 필요한 초기화와 같은 이벤트에 대한 동적 다이어그램입니다. 그런 다음 인터페이스를 구현하는 클래스를 보여주는 더 자세한 정적 다이어그램.

나는 게임의 요구 사항을 충족시킬 수 있도록 서비스를 제공하는 방향으로 코드를 작성하고 프로토 타이핑하고 발전시키고 있습니다. 사용 사례를 통해 사용자를 지원하지 않는 빌드 된 것은 없습니다. 쓸모없는 다이어그램 요소를 작성하지만 인터페이스 코딩과 다이어그램 사이에 쓸모없는 코드는 거의 작성하지 않습니다. 다이어그램 작성은 제가 작성하는 수업이 전체 시스템에 적합한 방식을 이해하고 있다는 확신을줍니다.

내가하려고하는 요점은 사소한 프로그램을 계획없이 작성할 수 있지만 게임은 사소한 것입니다. 얼마 전, OOP가 처음 등장했을 때 많은 실험이 있었고 몇 가지 모범 사례가 앞당겨졌습니다. 소프트웨어 개발 커뮤니티는 소프트웨어 디자인에 대해 쓰고 분석 할 언어가 필요하다는 데 동의했습니다. UML은 우리가 개발 한 언어입니다. 우리는 모두 그것을 알고 이해하므로 문제에 대한 다른 사람들의 솔루션 (도서, 온라인 토론, 기사, 패턴 카탈로그 등)을 사용하고 표준 표기법을 읽는 법을 배워야하지 않는 경우. 보너스로, 다른 언어로 된 시스템에 대해 스스로 생각하게되면 예기치 않은 것을 배우게됩니다.

여러 가지 방법론이 존재하지만 모두 문제를 식별하고 하나의 솔루션을 체계적으로 설명합니다. 이것은 공학입니다. UML은 거대하고 복잡하지만 모든 모델을 사용하는 모델은 없습니다. 스위스 군용 칼과 같습니다. 이를 알고 엔지니어링 프로세스를 지원하기 위해이를 사용하는 방법을 찾아야합니다. 중요한 것은 어떤 프로세스 나 방법론이 아니라 당신이 가지고있는 것입니다. 그렇지 않으면 복잡해집니다.

또한 친구 (2 인 팀)와 함께 독립적 인 게임 프로젝트를 진행하고 있습니다. 귀하와 비슷한 상황에있는 사람으로서, 도움이 될만한 몇 가지 정보를 제공 할 수 있습니다.

1. 아이디어가 거칠다면 초소형 프로토 타이핑 프로젝트에서 한 번에 하나씩 구현해보십시오. 예를 들어, 나는 지금 2D 플랫폼 게임을 만들고 있으며, 플레이어의 점프를 바로 얻는 것이 나에게 매우 중요합니다. 그래서 나는 두 가지 일이 일어나는 새로운 프로젝트를 만들었습니다 : a) 화면에 플레이어를 그리고, b) 입력을 감지하고 점프를 다시 그립니다.
2. 어떤 사람들은이 조언에 눈살을 찌푸 릴 수도 있지만, 개념, 컨트롤, 목표를 설명하기 위해 먼저 게임 매뉴얼을 작성하는 것에 대해 생각하십시오. 이를 통해 두 가지 작업을 수행 할 수 있습니다. 필요한 문서를 많이 생성 할 수있을뿐만 아니라 게임의 하위 시스템과 플레이어에 필요한 세부 정보도 간략하게 설명합니다. 플레이어가 알아야 할 사항을 미리 알고 있다면해야 할 일을 미리 알고 있습니다.
3. 파스타 조각에서 중간 크기의 스파게티 조각을 모두 제거하려는 것처럼 느끼지 않으면 서 요소 조각을 움직일 수 있거나 작게 구성 할 수있을 정도로 작은 (일명 모듈화 된 ) 청크로 코드를 작성 하십시오.

바라건대 적어도 하나의 유용한 정보와 행운을 찾았습니다!

나는 당신이 부인할 수없는 UML의 귀중한 테이크 아웃이 있다고 생각합니다. 다른 한편으로 UML은 비즈니스 프로세스를 위해 만들어 졌다는 것을 명심하십시오 . 많은 사람들 이 서로 다른 요구와 요구, 욕망 을 가지고 상호 작용 하는 시스템을 모델링합니다 . UML은 어떤 것도 빠뜨리거나 세부 사항에 압도되지 않도록 노력합니다.

UML은 "시스템 아키텍처를 시각화하는 표준 방법"입니다

UML 설명

• 활동
• 배우
• 비즈니스 프로세스
• 데이터베이스 스키마
• (논리적) 구성 요소
• 프로그래밍 언어 문장
• 재사용 가능한 소프트웨어 구성 요소

그러나 간단한 게임을 만드는 경우이 모든 것을 실제로 모델링해야합니까?

• 배우 : 플레이어.

그게 얼마나 도움이 되나요?

그래도 다른 것들을 모델링하는 것이 매우 도움이됩니다. 예를 들어 작은 MMO를 만드는 경우 잘 디자인 된 데이터베이스 스키마가 필요합니다.

따라서 UML을 탈취하는 데 탁월합니다 (필요한 사항을 알고 요구 사항을 적어두고 필요한 경우 플로우 차트 다이어그램을 스케치하십시오). 게임을위한 약간의 사각 페그 둥근 구멍.

UML은 그중 일부가 다른 것만 큼 가치가없는 것들의 모음입니다. 이전 스타일의 유스 케이스 (적어도 우리는 유스 케이스라고 함)

• 이름
• 요구 사항
• 전제 조건
• 트리거
• 행위
• 대체 조치
• 예외

매우 유용 할 수 있습니다. 웹 검색 (그림)을 사용하는 경우 "사용 사례"에서 찾은 것이 일반적인 소프트웨어에 대한 것입니다.

또한 클래스 다이어그램에 약간의 크레딧을 달았습니다. 이것은 모든 객체 간의 관계를 보여줄 수 있고 아키텍처의 레이아웃을 알고 있음을 보여줍니다.

핵심은 모델링 전에 기능 세트를 모두 계획하고 int (필요 / 원치 설정에서 임대)로 잠그고 다이어그램을 시작해야한다는 것입니다. 이것들은 모두 당신의 브리프 / 트리트먼트 / 스크립트 (피치, 피처 문서, 스토리라고도 함)에 있어야합니다. 그런 다음 모델과 다이어그램이 포함 된 기술 문서를 작성합니다.

UML을 사용하는 회사가 있지만 일반적으로 별도의 디자인 및 구현 팀이있는 회사입니다. 모든 문서를 만든 다음 프로토 타입 / 알파를 만들기 위해 코드 원숭이 팀에 제공 할 회사. 게임을 정확하게 모델링 할 수 있다면 완전히 다른 팀에 게임을 줄 수 있고 프로그램이 파이프 꿈이 아니라 정확도를 목표로 프로그래밍하도록 할 수 있어야합니다.

그들은 당신의 다른 팀원들에게 당신의 아이디어를 전달하고 당신이 기본적인 소프트웨어 엔지니어링 원리에 대해 잘 알고있는 강사들을 보여줄 수 있도록 대학에서 UML에 대해 가르쳐 줄 것입니다.

언어, 도구 또는 디자인에 대한 토론과 마찬가지로 일반적으로 사용 방법에 따라 다릅니다. 작업에 가장 적합한 도구 / 언어 / 디자인을 선택하고 강력한 근거로 선택한 사항을 백업하십시오. UML은 게임 제작에 유연하지 않다는 점을 인정하지만, 네트워크 통신 및 타이밍, 병렬 작업 관리 및 사용 사례와 같은 엔진 기능을 효과적으로 모델링하는 데 사용할 수 있다고 말할 수 있습니다. 5 명의 다른 팀원에게 10 가지 다른 시간을 똑같이 설명하는 것보다 더 나쁜 것은 없습니다. 여기에 설명서가 있습니다.

설계가 얼마나 견고하고 팀이 잘 훈련되어 있는지에 따라 아직 시작되지 않은 구성 요소를 중심으로 자신의 구성을 모델링 할 수 있지만 아직 선적 서류 비치.

그럼에도 불구하고, 당신은 아마도 이것들이 살아있는 문서라는 것을 듣고 (혹은 가혹하게), 그것들을 정기적으로 검토하고 업데이트하지 않으면, 그들은 쓸모없고 효과적으로 쓸모 없게 될 것입니다.