도메인 기반 디자인은 게임에 적합합니까?

방금 도메인 모델에 대해 읽었으며 데이터 만 보유하는 클래스가있는 게임을 개발 한 이래로 나에게 깨달았습니다 (몇 가지 행동 / 방법). 이 클래스를 처리하는 작업을 관리자에게 할당했습니다. 이제 관리자가 신의 대상처럼 보입니다. 논리를 처리해야하는 게임 오브젝트는 빈혈 도메인 모델 일뿐입니다.

내 현재 디자인 패턴은 Singleton 이며이 자료를 꺼내기 위해 코딩을하고 싶습니다. 나는 지금까지 게임에서 DDD를 본 적이 없지만 이것이 좋은 접근법입니까? 나는 초보자 프로그래머 (게임 개발자에게는 기울이지 않음)이므로 게임을 다시 디자인하기에 너무 부풀어 오르기 전에 좋은 아키텍처에 대해 더 배우고 싶습니다.

귀하의 게시물 전에 도메인 기반 디자인에 대해 들어 본 적이 없습니다. 여기 와 여기에 몇 가지 참고 문헌을 간략히 살펴보면 대학에서 가르친 전통적인 90 년대 객체 지향 프로그래밍 방법의 멋진 이름 일 것입니다. 각 명사에 대한 클래스를 작성하려고 시도합니다. 소프트웨어의 구조가 실제 개념의 구조를 따르는 것처럼 보이도록 소프트웨어를 사용하여 모델링하려는 경우.

따라서 이것에 대한 나의 대답은 그것이 "좋지 않다"는 것입니다. 일반적으로 합리적인 출발점이지만 진행에 따라 부적절합니다. 단일 도메인은 거의 없지만 하나의 소프트웨어에 여러 도메인이 있습니다. 예를 들어 게임 도메인 (세계, 캐릭터, 항목), 렌더러 도메인 (쉐이더, 메시, 자료), 입력 도메인 (파일 시스템, 네트워크, 키보드 및 마우스) 및 도메인이 서로 겹쳐서 영향을 미치는 문제가 발생합니다. 종종 2 개의 도메인을 결합하는 과정에서 실제로 변경이 필요한 종속성이 있다는 것을 알고 있습니다. 즉, 표현 중 하나가 도움말보다 부담이됩니다.

모호한 예는 콘솔의 게임 라이브러리와 게임 내 캐릭터 일 수 있습니다. 수학 라이브러리에는 큰 데이터 목록이 있고 그 목록에서 수행 할 명령 하나를 효율적으로 실행하려고합니다. 게임 내 캐릭터는 각각 렌더링 및 애니메이션 등을위한 고유 한 정점 데이터 세트를 갖게됩니다. 이제 각 문자에서 모든 정점 데이터의 긴 목록을 가져 와서 한 번에 처리 할 수 ​​있습니까? 느린 복사 작업을 수행하거나 대신 문자를 리팩터링하여 데이터가 수학 라이브러리에서 처리 될 수 있도록 할 수 있습니다. 그러나 도메인 중 하나가 다른 것을 선호하도록 분류됩니다.

개인적으로 나는 "무엇을 주도하는 디자인"과 비슷한 라벨에 대해 매우 조심합니다. 소프트웨어는 너무 광범위하고 복잡하기 때문에 하나의 크기에 맞는 모든 접근 방식이 있습니다. 대신, 내가 할 수있는 최고의 소프트웨어를 만들려고 할 때 저는 SOLID 원칙을 따르 려고 노력 합니다. 이것들은 코드가 얼마나 좋은지에 대한 좋은 아이디어를 제공합니다. 불행히도 이러한 방법론이 없다면 이러한 지침을 준수하는 방법을 배우기 전에 많은 경험이 필요합니다. 아마도 많은 사람들이 방법론을 좋아하는 이유 일 것입니다.

빈혈 클래스와 관리자 객체에 관한 문제와 관련하여 이것은 일반적으로 입문 객체 지향 수업에서 다루고 있으며 실제로 '고정'하기 위해 특별한 방법론을 따를 필요는 없습니다. 방금 시작한 경우 객체 지향 프로그래밍에 대한 책을 선택할 수도 있습니다. 클래스는 상태와 동작을 결합하여 동작이 해당 상태를 수정하는 것을 캡슐화라고합니다. 일반적으로 가능한 많이 시도하고 캡슐화합니다. 즉, 객체 자체 (및 해당 객체 만)로 상태를 조작해야합니다. 클래스 내에서 모델링 할 수없는 동작에 대해서만 관리자와 같은 외부 클래스에 위임하려고하므로 관리자 클래스의 존재는 종종 잘못 작성된 객체 지향 코드의 표시로 간주됩니다.

내 현재 디자인 패턴은 Singleton 이며이 자료를 꺼내기 위해 코딩을하고 싶습니다.

나는 당신이 그 선의 의미를 모른다. 디자인 패턴은 프로그램의 작은 부분을 작성하는 잘 알려진 방법입니다. '현재'디자인 패턴이 없거나 프로그램의 나머지 부분을 형성하지도 않습니다. 초보자에게는 이러한 패턴이 올바른 길을 찾는 데 유용하지만 전문가에게는 일반적인 코드 상황에 대해 의사 소통하는 방법이 더 많습니다. 그러나 중요한 것은 싱글 톤은 거의 항상 나쁜 생각이므로 가능할 때마다 피해야합니다. 이 사이트 및 스택 오버플로에서 싱글 톤에 대한 많은 의견을 찾을 수 있지만 여기에 필요하지 않은 답변이있는 실용적인 질문 이 있습니다.

어형 변화표

이 답변이 작성된 시점에서 여기에 게시 된 다른 답변은 모두 잘못되었습니다.

도메인 기반 디자인이 게임에 적합한 지 묻지 않고 "도메인 모델링"이 게임에 적합한 지 묻습니다.

도메인 모델링은 게임에 적합합니까?

그 답은 : 때로는 정말 훌륭합니다. 그러나 플랫 포머 또는 FPS와 같은 실시간 게임을 만들거나 다른 많은 종류의 게임을 만드는 경우에는 아닙니다. 해당 시스템에 반드시 적합하지는 않습니다. 그러나 도메인 모델 패턴을 구현하는 게임 내에 시스템이있을 수 있습니다.

다른 사람들이 여기서 언급했듯이 구성 요소 엔터티 프레임 워크는 매우 인기가 있고 좋은 이유가 있습니다. 그러나 게임 개발 문화에서는 계층화 된 아키텍처가 뚜렷하게 부족한 것으로 보입니다. 다시 말하지만, 사람들이 개발하려고하는 대부분의 게임은 엔티티에 대한 상태를 변경하고 출현 한 결과를 게임으로 만들기 때문에 좋은 이유입니다.

모든 소프트웨어는 귀하가 작성하는 소프트웨어가 아닙니다. 일부는 다른 것과는 상당히 다릅니다.

도메인 모델링이 잘 작동하는 도메인의 예로는 카드 게임, 보드 게임 및 기타 이벤트 중심 시스템이 있습니다.

핵심 도메인 개념으로 타임 델타에 의해 결정되는 움직임 등으로 X 프레임 속도로 실행되는 게임은 아마도 적합하지 않습니다. 이 경우 "도메인"은 종종 너무 단순하여 도메인 모델링이 필요하지 않습니다. 충돌 감지, 새로운 개체의 생성, 기존 개체에 대한 힘의 영향 등은 대부분의 게임 플레이를 다루는 경향이 있습니다.

그러나 상황이 복잡 해짐에 따라 개발자가 특정 유형의 동작 및 계산을 처리하기 위해 엔터티 내에 도메인 모델을 구현하는 것을 보게됩니다.

게임 아키텍처의 도메인 모델 패턴

게임 엔진 (예 : Unity3D)은 종종 구성 요소 엔터티를 지향합니다. 플랫 포머에서는 캐릭터를위한 엔티티가있을 수 있으며 상태 등은 위치 등을 업데이트하기 위해 지속적으로 변경됩니다.

그러나 이벤트 중심의 게임에서는 구성 요소 엔터티 프레임 워크의 역할이 사용자 인터페이스로 존재할 가능성이 높습니다. 계층 구조로 끝납니다.

UI는 게임 상태를 사용자에게 렌더링합니다. 사용자는 UI와 상호 작용하여 서비스 계층에서 명령을 트리거합니다. 서비스 계층은 도메인 개체와 상호 작용합니다. 도메인 객체는 도메인 이벤트를 일으켰습니다. 이벤트 리스너는 이벤트를 듣고 UI에서 변경을 트리거합니다.

UI> 서비스 계층> 도메인 모델

요컨대, 서비스 계층 구현을 갖춘 모델 뷰 컨트롤러로 끝납니다.

이 아키텍처를 사용하면 이벤트 중심 인터페이스를 통해 완전히 단위 테스트 가능한 게임 코어 (게임 개발 문화의 희소성 및 보여짐)가 있습니다.

이제 DDD 란 무엇입니까?

Domain-Driven Design은 구체적으로 도메인에 대해 배우는 데 사용되는 분석 패턴에 중점을 둔 문화 / 운동입니다. 실제로 올바른 것을 구축 한 다음 구현 패턴을 나타내는 모델 레이어를 구현할 수있는 구현 패턴 언어 관용구를 사용하여 도메인 모델의 개념. DDD는 복잡한 도메인에서 작동하는 커뮤니티에서 나오며 항상 도메인 모델링에 중점을 두어 애플리케이션에서 높은 복잡성을 관리 할 수있는 방법을 찾고 있습니다.

DDD는 코딩을 시작하고 시스템을 가지고 놀면서 나중에 만들고 싶은 것을 알아내는 것이라면 목표가 좋지 않습니다. 도메인이 더 많거나 적다고 가정합니다. 따라서, 당신의 게임이 어떻게 될지 모른다면, 그것은 작동하지 않을 것입니다.

아니요, DDD 나 다른 "버즈 워드"아키텍처가 게임에 정말 좋은 것 같지는 않습니다. "컴포넌트 시스템"을 제외하고는 여기에서 정말 인기가있는 것 같습니다.

이와 같은 질문과 토론을들을 때이 사이트가 떠 오릅니다 . 다양한 아키텍처 유행어를 숙고하면 일반적으로 실제로 자신의 응용 프로그램을 디자인하고 코딩하는 것보다 덜 유용합니다.

예,하지만 적응해야합니다.

DDD를 사용하면 각 도메인마다 모듈 성과 단일 책임이 부여됩니다. 그러나 다른 것은 단지 일을 복잡하게 만듭니다.

여기에 내 대답을 참조하십시오