MVC (Model-View-Controller) 게임 엔진 아키텍처-예 또는 아니요? [닫은]


18

나는 위대한 책인 Game Coding Complete 을 읽고 있는데, 그 책 은 세 가지 핵심 계층으로 MVC (Model-View-Controller) 접근 방식을 사용할 것을 강력히 권장합니다 .

  1. 게임 애플리케이션 레이어
  2. 게임 로직
  3. 게임 뷰

나에게이 접근 방식은 모바일 컴퓨터 게임에있어 과잉 인 것처럼 보인다.

당신의 의견은 무엇입니까? 모듈간에 필요한 추가 통신을 추가하더라도이 아키텍처를 구현할 가치가 있습니까? 이 디자인이 너무 많은 CPU 전력을 소비하여 결과적으로 구현되지 않은 경우보다 결과가 상당히 느려질 수 있습니까?


5
-1하고 투표를 닫습니다. 게임에서 MVC에 대해 말할 가치가있는 모든 것은 gamedev.stackexchange.com/questions/3426/… 에서 언급되었으며 지금까지 우리가 가진 것은 쓰레기입니다.

@Joe Wreschnig 그것은 매우 가혹하지만 사실을 추측합니다 ...
Spooks

@chaos : 사실, 나는 당신의 대답에 투표를했지만, "도움이된다면 도움이되고 사용하지 않으면 사용하지 마십시오"라는 또 다른 대답은 필요하지 않았습니다. 아니면 우리가했을 수도 있지만 여전히 슬프다. 그래도 쓰레기 이외의 "상속과 같은 런타임 디자인"과 같은 표현을 참조하는 방법을 여전히 모른다.

2
@Joe : 오, 고마워. :) OOP가 비용이 들지 않는다는 주장은 마음을 다소 혼란스럽게한다. 나는 어떤 표준에 따르면 우리 되풀이 한 것과 같은 요점이 필요 없다고 생각 하지만 멍청한 일이 일어나므로 논쟁의 여지가있는 질문이 반복됩니다. 또한 활동이 크게 줄었음에도 불구하고 저와 같은 사이트의 후발 주자가 약간의 담당자를 긁어내는 기능도 제공합니다. :) 젠장, 나는 40K의 담당자가 있지만 태그 위키를 편집조차 할 수 없다.
혼돈

답변:


30

간단한 모바일 게임에서도 MVC 구조 사용을 다소 지원합니다. 다른 것이 없다면, 충분한 시간을 먹지 않은 개발자들에게 게임 로직에서 디스플레이 코드를 분리하는 문제를 해결하는 데 도움이됩니다.

그러나 모든 디자인 패턴과 마찬가지로 MVC 는 여러분의 삶을 더 쉽게 만들기 위해 존재한다는 것을 명심해야합니다 . 즉, MVC를 사용할 때해야 할 일과하지 말아야 할 일에 관한 규칙을 지키는 것이 인생을 더 힘들게 만든 다면 무시하십시오 . 두 가지 중 하나가 발생합니다. 1) 나중에 물린 다음 처음에 다르게 다르게하는 것이 실제로 인생을 더 편하게 만들었거나 2) 결과가 전혀없는 이유를 이해할 것입니다.

컴퓨터 프로그래밍은 본질적으로 실제로 어떤 것을 달성하는 것보다 우아한 원칙을 고수하는 많은 규칙을 따르는 사람들을 얻습니다. 그들이 당신을 그들 중 하나가되게하지 마십시오. 당신의 게임에 일어날 수있는 가장 중요한 것은 그것을 배송하는 것 입니다.


친애하는 혼돈, 나는 당신의 대답이 가장 마음에 듭니다. 그래서 나는 그것을 나의 질문에 대한 대답으로 표시하고 있습니다. MVC 접근 방식은 코드 디자인에 추상화를 추가합니다. 추상화는 일반적으로 더 많은 단계의 코드를 추가하는데, 이는보다 독창적 인 디자인으로 피할 수 있습니다. 올바르게 이해 했으므로 MVC 디자인의 결과로 추가 된 추상화로 인한 비용에 대해 걱정할 필요가 없습니다.
Bunkai.Satori

1
좋은 대답입니다. +1입니다. 이론은 모두 훌륭하지만 잘 수행하지 않으면 게임이 배송되지 않을 수 있습니다.
James

@ Bunkai.Satori : 추상화를 추가하고 IMO는 유용한 추상화입니다. 비용 있으며, 걱정할 필요가 없다는 설명과 함께 귀하의 마지막 진술에 동의 합니다.
혼돈

4

엄청나게 복잡한 컴파일러가 없다면 컴파일 타임 디자인은 CPU 전력을 소비하지 않습니다. 객체 지향 언어 또는 접근 방식은 성능 적 특성이 절차 적 언어와 다르지 않습니다. MVC 사용에 대한 추가 오버 헤드를 호출하지 않습니다. 모듈화는 런타임이 아닌 컴파일 타임에 존재하며 일단 코드가 인라인되고 최적화되면 아무런 차이가 없습니다.

많은 현대 게임은 실제로 별도의 스레드에서 모델과 뷰를 실행하고 대부분의 플랫폼에서 뛰어난 성능 이점을 얻습니다.

궁극적으로 MVC는 유지 보수를 늘리고 버그를 줄이면서도 무료로 사용할 있는 좋은 디자인입니다 . 그것을 사용 하지 않을 이유가 없습니다 . for손으로 쓰는 대신 루프를 사용해야하는 이유를 묻는 것과 같습니다 goto. 뛰어난 디자인을 염두에 두지 않으면 아무것도 아닌 것보다 훨씬 낫습니다.

편집 : 컴파일 타임 디자인은 CPU 전력을 소비하지 않습니다. 상속과 같은 런타임 디자인은 분명히 그렇습니다.


-1. MVC는 디자인 타임 결정입니다. 상속은 디자인 타임 결정입니다. 둘 다 컴파일 타임과 런타임 전에 발생합니다. 둘 다 성능에 큰 영향을 미칩니다. 인라인이 항상 코드를 더 빨리 만드는 것은 아닙니다. 스레딩 제안은 매우 순진합니다. 무료는 없습니다.

답변 해 주셔서 감사합니다 DeadMG. 기본적으로, 모든 추상화 레벨에서 점점 더 많은 중간 단계가 추가됨에 따라 코드가 중단됩니다. MVC는보다 추상적 인 디자인이므로 동일한 작업을 수행하기 위해 더 많은 단계를 수행 할 수 있습니다. 이것은 속도에 영향을 줄 것입니다.
Bunkai.Satori

4

코드의 명확성과 프로그램의 기술 요구 사항 (속도, 메모리 등) 사이에는 거의 항상 상충 관계가 있습니다. 객체 지향 언어는 절차 언어와 비교하여 오버 헤드가 있지만 특히 코드 (버그 등)를 장기간 유지 관리하고 개발 속도를 높이는 경우 절차 언어에 비해 많은 장점이있는 것으로 나타났습니다.

따라서 MVC는 게임 프로그래머로서 귀하를 위해 구현할 가치가 있다고 제안합니다 . 코드는 객체 지향 원칙, 특히 캡슐화 를 더 잘 따르며 버그를 수정하거나 새로운 기능을 추가하는 데 훨씬 쉬운 시간을 가질 수 있습니다.

다른 한편으로, 실제로 게임을 끝내고 결코 끝나지 않는 "엔진"에 대해 많은 시간을 소비하지 않도록하십시오.

자세한 정보 는 "게임 아키텍처에서 왜 MVC & TDD가 더 많이 사용되지 않습니까?"라는 질문을 읽으십시오. 정말 긴 답변입니다.


1
OO 언어는 절차 언어보다 전혀 느리지 않습니다. 비트 시프트를 수행하는 일부 코드를 C ++로 작성하면 C보다 느리게 진행되지 않습니다. 언어 또는 프로그램은 객체 지향이기 때문에 절차에 비해 전혀 느리지 않습니다. 프로그램은 제대로 작성되지 않았기 때문에 성능 저하 만 나타냅니다 . 결과적으로 귀하의 답변을 하향 조정해야 할 필요가 있다고 생각합니다.
DeadMG

안녕하세요 Ricket, yoru 설명 감사합니다. 매우 논리적으로 들립니다. DeadMG, 당신은 맞습니다. 다른 한편으로, OO 접근법은 절차 적 언어보다 컴파일 된 코드에 더 많은 정보를 추가한다고 생각합니다. OO 관련 코드의이 추가 비트는 결과 코드를 느리게 만듭니다. 동의하십니까?
Bunkai.Satori

3
우와 지금 ... 물론 C ++의 간단한 줄은 C와 a++똑같습니다 a++( a기본 유형 등). 그러나 내부 코드가 동일하더라도 가상 함수가 무언가를 수행하는 가상 함수가있는 간단한 C ++ 클래스를 고려하십시오. 객체 지향 언어에는 오버 헤드가 있습니다. "속도"를 명시 적으로 말하여 죄송합니다. 추가 메모리 할당으로 인해 프로그램 속도가 느려지지 않으면 완전히 맞습니다.
Ricket

2
함수가 가상 인 경우 프로그램이 런타임시 동일한 함수의 서로 다른 두 가지 버전 중에서 선택해야 함을 의미합니다. (그렇지 않으면 가상으로 만들 수 없습니다.)이 경우 어쨌든 조건부 또는 간접 수준이 추가되어 절차 언어로 자신을 구현해야합니다 (예 : 함수 포인터 또는 스위치 문을 통해) . 그것은 오버 헤드가 아니며 문제의 본질입니다.
Kylotan
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.