즉각적인 GUI-예 또는 아니오? [닫은]

몇 년 전 MFC, QT, Forms, SWING 및 몇 가지 웹 GUI 프레임 워크와 같은 많은 "보존 된"GUI 시스템 (내가 의미하는 바에 대한 자세한 내용)을 사용하여 응용 프로그램 개발을 진행하고 있습니다. 나는 항상 대부분의 GUI 시스템의 개념이 지나치게 복잡하고 어색하다는 것을 알았습니다. 콜백 이벤트, 리스너, 데이터 사본, 문자열에서 무언가로의 변환-변환 등은 항상 응용 프로그램의 다른 부분과 비교할 때 실수와 두통의 원인이었습니다. (데이터 바인딩 / 모델을 "적절하게"사용하는 경우에도).

지금 나는 컴퓨터 게임을 쓰고 있습니다 :). 나는 지금까지 하나의 GUI로 작업했습니다 : Miyagi (잘 알려진 것은 아니지만 기본적으로 다른 모든 시스템과 동일한 아이디어).

끔직했다.

게임과 같은 실시간 렌더링 환경에서는 "보존 된"GUI 시스템이 훨씬 더 오래되었다는 느낌을받습니다. 사용자 인터페이스는 일반적으로 자동 레이아웃되거나 크기 조정 가능한 창을 즉시 가질 필요가 없습니다. 대신 항상 변화하는 데이터 (세계의 3D 모델 위치)와 매우 효율적으로 상호 작용해야합니다.

몇 년 전, 나는 기본적으로 즉시 그래픽 모드와 비슷하지만 사용자 인터페이스를위한 "IMGUI"를 우연히 발견했습니다. 나는 여전히 응용 프로그램 개발에 있었고 IMGUI 장면 자체가 실제로 광범위하거나 성공적이지 않은 것처럼 보였으므로 너무주의를 기울이지 않았습니다. 여전히 그들이 접근하는 방식은 너무 섹시하고 우아해 보입니다. 그래서이 UI 방식을 사용하여 다음 프로젝트를 위해 무언가 를 쓰고 싶었습니다 (직장에서 누군가를 설득하지 못했습니다 : (...)

"보유"와 "즉시"의 의미를 요약하겠습니다.

유지되는 GUI : 별도의 초기화 단계에서 레이블, 단추, 텍스트 상자 등과 같은 "GUI 컨트롤"을 만들고 어떤 것이 렌더링되기 전에 화면에 배치하는 설명 적 (또는 프로그래밍 방식) 방법을 사용합니다. 컨트롤은 X, Y 위치, 크기, 테두리, 자식 컨트롤, 레이블 텍스트, 이미지 등과 같은 대부분의 상태를 메모리에 저장합니다. 콜백 및 리스너를 추가하여 이벤트에 대한 정보를 얻고 GUI 제어에서 데이터를 업데이트 할 수 있습니다.

즉각적인 GUI : GUI 라이브러리는 원샷 "RenderButton", "RenderLabel", "RenderTextBox"... 함수로 구성됩니다 (편집 : Render에 의해 혼동하지 마십시오)접두사. 이 함수는 또한 사용자 입력 폴링, 문자 삽입, 사용자가 키를 눌렀을 때 문자 반복 속도 처리 등과 같은 제어 뒤의 논리를 수행하여 컨트롤을 "즉시"렌더링하도록 할 수 있습니다. t는 GPU에 즉시 기록되어야하며, 일반적으로 현재 프레임을 기억하고 나중에 적절한 배치로 분류됩니다. 라이브러리는 이에 대한 "상태"를 보유하지 않습니다. 버튼을 숨기려면 RenderButton 함수를 호출하지 마십시오. 버튼 또는 확인란과 같은 사용자 상호 작용이있는 모든 RenderXXX 함수에는 사용자가 버튼을 클릭했는지 여부를 나타내는 반환 값이 있습니다. "RenderGUI" 함수는 게임 상태에 따라 RenderXXX 함수를 호출하거나 호출하지 않는 큰 if / else 함수처럼 보이며 모든 데이터 업데이트 논리 (버튼을 누를 때)가 흐름에 얽혀 있습니다. 모든 데이터 스토리지는 GUI 외부에 있으며 필요에 따라 렌더링 기능으로 전달됩니다. (물론, 큰 함수를 여러 함수로 나누거나 GUI의 일부를 그룹화하기 위해 클래스 추상화를 사용합니다. 우리는 1980 년과 같은 코드를 더 이상 작성하지 않습니다.;)

이제 Unity3D는 실제로 내장 GUI 시스템에 대해 동일한 기본 접근 방식을 사용한다는 것을 알았습니다. 아마도이 접근법을 가진 GUI가 몇 개 있습니까?

아직도 .. 둘러 볼 때, 유지되는 GUI 시스템에 대한 강한 편견이있는 것 같습니까? 적어도 Unity3D를 제외 하고는이 접근법을 찾지 못했으며 원래 IMGUI 커뮤니티는 오히려 .... .. 조용한 것으로 보입니다.

누구든지 두 가지 아이디어로 일하고 강한 의견이 있습니까?

편집 : 나는 실제 경험에서 비롯된 의견에 가장 관심이 있습니다. IMGUI 포럼에는 즉각적인 GUI 접근 방식의 "이론적 약점"에 대해 많은 논의가 있지만 실제 세계의 약점에 대해 아는 것이 항상 더 밝습니다 .

아니. 나는 끔찍한 '유지 모드'GUI와 끔찍한 '즉시 모드'GUI에서 유료 게임 개발 작업을 수행했으며 두 가지 모두 눈을 찢고 싶지만 유지 모드 접근 방식이 여전히 낫습니다.

즉시 모드의 단점은 다음과 같습니다.

• 아티스트와 디자이너가 레이아웃을 쉽게 구성 할 수는 없습니다.
• 그들은 논리와 프리젠 테이션을 혼합하게합니다.
• 그들은 하나의 일관된 입력 모델을 갖는 것을 어렵게 만듭니다.
• 동적 데이터의 복잡한 제어 (예 : 목록보기)를 권장하지 않습니다.
• 레이어링이 매우 어색해집니다 (예 : RenderComboBox를 호출하면 드롭 다운 상자가 나머지 창의 위로 올라 가야하기 때문에 아직 렌더링 할 수 없습니다. 도구 설명과 동일) l
• 렌더링 스타일 구성은 전역 (ick) 또는 추가 함수 인수 (ick)로 수행됩니다.
• 변경되거나 변경되지 않은 값을 쿼리하기 위해 이러한 모든 함수를 호출하면 많은 작은 개체가 생성되어 메모리 관리자에 스트레스를주기 때문에 성능이 저하 될 수 있습니다.
• ... 그리고 누군가 GUI를 드래그하여 순서를 바꾸는 것이 얼마나 고통 스러운지 상상조차 할 수 없습니다. 유지 모드 시스템을 직접 작성하는 것과 매우 유사한 모든 것을 렌더링 할 위치를 알려주는 데이터 구조를 유지해야합니다.

즉각적인 모드 GUI는 빠른 HUD 시스템을 원하는 고독한 프로그래머에게 유혹적이며 그 목적을 위해 훌륭합니다. 다른 건 ... 그냥 거절 해

데스크탑에서 IMGUI에 대해 5 년 또는 6 년의 실제 경험이있는 사람은이를 방어해야 할 의무가 있습니다. 모든 답변 (및 질문 자체)은 IMGUI의 매우 제한된 정의를 기반으로하며 많은 의심스러운 주장이 제기되는 것처럼 보입니다.

IMGUI 라이브러리가 데이터를 보관할 수 없다는 가정에서 비롯된 것입니다. 이것은 사실이 아닙니다. 정교한 IMGUI 라이브러리는 실제로 동등한 RMGUI 라이브러리만큼 많은 데이터를 보유합니다. 차이점은 IMGUI 라이브러리가 대부분 결과를 캐시 하는 반면 RMGUI 라이브러리는 신뢰할 수있는 상태를 유지한다는 것입니다. IMGUI에서 애플리케이션은 현재 모델 상태를 가져 와서 해당 상태에 대한 GUI를 생성하는 기능을 제공합니다. 이것은 GUI의 권위있는 정의입니다. 라이브러리는 온 스크린 GUI가 해당 기능의 결과와 일치하는지 확인합니다. 그렇다고 각 프레임마다 해당 기능을 완전히 평가하고 GUI를 완전히 재구성해야한다는 의미는 아닙니다. 그것이 캐싱의 요점입니다.

이러한 IMGUI보기를 사용하면 실제로 고급 레이아웃을 수행 할 수 있으며 성능이 상당히 합리적입니다. 인터페이스가 더 쉬워지면 실제 정식 상태를 유지할 수도 있습니다. IMGUI의 요점은 응용 프로그램이 모든 것을 유지하도록하는 것이 아닙니다. 응용 프로그램은 모든 스크롤 막대의 위치와 모든 트리 노드의 확장 / 축소 상태를 저장하지 않아도됩니다. 요점은 그 트리 노드의 내용과 그 존재를 절차 적으로 지정할 수 있다는 것입니다.

나는 모든 IMGUI 비판을 하나씩 살펴보고 응답 할 것이지만, 나는 그것들을 많이 이해하지 못한다. 그들 대부분은 IMGUI가 hackish이고 RMGUI가 잘 구조화되어 있다는 근본적인 신념에서 비롯된 것 같습니다. 위의 오해에서 비롯된 것 같습니다. IMGUI 라이브러리가 복잡성에 어려움을 겪거나 전역과 충돌하거나 논리를 프리젠 테이션과 혼합해야하는 고유 한 이유는 없습니다. 콘텐츠가 예술가 중심 일수록 IMGUI의 장점이 덜 중요해 진다고 말하지만 실제로 아티스트 중심 콘텐츠가 왜 더 나쁠 지 잘 모르겠습니다. (색상, 글꼴 / 테두리 크기 등과 같은 스타일 시트를 제외하고는 개인적으로 아티스트 중심의 콘텐츠를 사용하지 않지만 RMGUI보다 구현하기 어려운 이유는 알 수 없습니다.)

내 마음에, IMGUI는 의심 할 여지없이 좋은 것입니다. GUI에 대한 추론을위한 훨씬 더 나은 모델을 제공합니다. 훨씬 기능적이고 반응성이 좋으며 추론해야 할 가변 상태의 양을 최소화합니다. 반면에 정교한 IMGUI 라이브러리를 구현하는 것은 상당히 어려운 일이며 동등한 RMGUI 라이브러리를 구현하는 것보다 훨씬 어렵습니다. 라이브러리 복잡성과 응용 프로그램 복잡성 사이의 균형점입니다. 복잡한 앱 (또는 많은 간단한 앱)을 만들 계획이라면 균형이 매우 좋습니다. 하나의 단일 앱에 대해이 작업을 수행하는 경우 매우 간단하지만 RMGUI를 사용하면 목표를 더 빠르게 달성 할 수 있습니다.

어쨌든 행운을 빌어 요!

GUI 라이브러리는 원샷 "RenderButton", "RenderLabel", "RenderTextBox"...로 구성되어 컨트롤을 "즉시"렌더링하기 위해 호출 할 수 있습니다 (GPU에 즉시 쓸 필요는 없음). 현재 프레임의 경우 나중에 적절한 배치로 정렬).

나는 이것이 이것이 GUI 라이브러리를 구성하지 않는다고 말할 때까지 갈 것입니다. 렌더링 함수의 무리 일뿐입니다.

GUI 렌더링은 GUI 를 만드는 가장 쉬운 부분입니다. 예를 들어 텍스트 상자를 보자. 가장 간단한 경우를 가정하겠습니다 : 간단한 한 줄 입력 텍스트 상자.

RenderTextBox그냥 텍스트 상자를 그립니다. 간단한 텍스트 측정을 수행하고 화면에 글리프를 그립니다. 그것은하지 않습니다

• 사용자가 컨트롤에서 마우스를 클릭했는지 감지하고 커서를 문자열의 적절한 위치로 이동하십시오.
• 사용자가 컨트롤에서 마우스를 두 번 클릭 한 것을 감지하고 텍스트 블록을 선택하십시오.
• 사용자가 "홈"키를 눌렀 음을 감지하고 커서를 텍스트 앞쪽으로 이동하십시오.
• 사용자가 유효한 키를 눌렀 음을 감지하고 이에 따라 문자열을 수정하십시오. 텍스트를 선택한 경우 선택한 부분이 삽입 된 텍스트로 바뀝니다.

계속 갈 수 있지만 요점은 분명하다고 생각합니다. RenderTextBox텍스트 상자를 그리는 데 사용하려는 경우 기능이없는 정적 텍스트 상자 만 있으면됩니다. 실제 기능 은 모두 구현해야합니다.

텍스트 측정 및 그림 문자를합니까? 그것은 GUI 작업 의 쉬운 부분입니다. GUI는 "그래픽 사용자 인터페이스"를 나타냅니다. 마지막 두 단어는 사용자가 입력 한 내용과 관련하여 어려운 부분입니다.

게임 플레이어는 GUI 컨트롤이 합리적으로 작동하기를 기대합니다. PC 스타일 환경 (예 : 마우스 및 키보드)에서 플레이어가 텍스트 상자를 보게되면 일반 텍스트 상자처럼 작동 할 것으로 기대합니다. 그들은 화살표 키를 사용하여 그 안에서 움직일 수 있고, 앞으로 건너 뛰고 집으로 끝나고 삭제하고, 문자를 선택하는 등을 할 수있을 것으로 기대합니다

즉,이 UI 코드를 모두 구현해야합니다. 어떤 컨트롤을 클릭했는지 테스트해야합니다. 그런 다음 어떤 컨트롤을 클릭했는지에 따라 무언가를 수행해야합니다. 키보드 입력을 얻는 "능동"컨트롤 개념이 있어야합니다. 다른 컨트롤은 다른 유형의 사용자 상호 작용에 다르게 응답해야합니다.

기본적으로 TextBoxWindow수업 이 필요합니다 .

게임 옵션 화면을 구현한다고 가정 해 봅시다. 따라서 게임 플레이, 그래픽, 사운드, 컨트롤 등 다양한 옵션 그룹이 있습니다. 따라서 화면 왼쪽에 다른 그룹 목록이 있습니다. 각 그룹은 사용자가 조작 할 수있는 일련의 컨트롤을 제공합니다. 사용자가 Tab 키를 누르면 어떻게됩니까?

글쎄, 그것은 어떤 컨트롤이 활성화되어 있는지에 달려 있습니다. 그룹 컨트롤 중 하나가 활성화 된 경우 (가장 최근에 클릭 한 경우) 다음 그룹으로 이동합니다. 대신 그룹 내의 컨트롤 중 하나 가 활성화되어 있으면 해당 그룹의 다음 컨트롤로 이동합니다. 이것이 시스템이 작동하는 방식입니다.

따라서 활성 제어 프로세스 키보드 입력뿐만 아니라 처리되지 않은 입력을 해당 제어를 소유 한 제어에 팜으로 보내야 합니다. 그 중 하나 또는 컨트롤이 일종의 연결된 목록에 있어야하므로 앞뒤로 이동할 수 있습니다. 즉, 각 컨트롤마다 기본 동작이 필요합니다.

이것은 점점 더 유지되는 GUI처럼 들립니다. 그렇지 않습니까? 유일한 차이점은 ... 당신 은 열심히 일하는 사람입니다. GUI는 사람이다를 elses 사용 가정은 적은 작업을 할 수있는 방법이 될 수 있습니다. 그러나 사용자가 기대 하는대로 GUI 응답을 만드는 데 드는 노력 은 쉽지 않습니다.

기억하십시오 : UI는 사용자 를위한 것이 아니라 사용자를 위한 것 입니다. 플레이어를위한 것입니다. 예상대로 동작해야합니다. 그렇지 않은 경우, 그때 당신은 실패했다.

사용자 인터페이스는 일반적으로 자동 레이아웃되거나 크기 조정 가능한 창을 즉시 가질 필요가 없습니다.

그것은 제한적이고 제한적인 생각입니다.

UI 요구가 다른 여러 게임에 대해 이야기 할 수 있으며 일부 게임 에는 크기 조정 가능한 창 등 이 필요합니다. 그러나 훨씬 더 큰 문제가 있습니다.

당신의 생각은 Gratuitous Space Battles 문제로 이어집니다.

그 게임을 해본 적이 없다면 싸고, 인디이며 GUI가 많은 게임입니다. 실제 게임 플레이는 모두 GUI에서 수행됩니다 ( "유닛을 설정하고 그들이 싸우는 것을 지켜보십시오"). 문제?

GUI를 축소 할 수 없습니다!

오, 보통 모니터를 사용하거나 시력이 정상이라면 괜찮습니다. 그러나 예를 들어, 엄청나게 큰 모니터를 실행하는 사람 (Windows가 모든 텍스트의 크기를 확장하여 실제로 읽을 수 있도록 너무 큰 모니터)을 실행하는 사람이라면 이것은 끔찍 합니다. 텍스트는 미세합니다. 글꼴 크기를 변경할 방법이 없습니다.

물론 GSB는 GUI 기반 게임이므로 절대로 변명 할 수 없습니다. GUI-lite 게임은 아마도 그것을 벗어날 수 있습니다.

사용자가 자신의 게임을 정확하게 보고 있다고 가정하지 마십시오 . 그렇게하는 것은 어리석은 일입니다.

해상도에 독립적 인 GUI 인 사용자 해상도로 자체 크기를 조정할 수있는 GUI 시스템을 사용하려면 레이아웃이 GUI 시스템 자체의 일부 여야합니다. 당신이 그것을 제공하지 않으면, 당신의 텍스트는 누군가의 거대한 모니터에 아주 작게 나타날 것입니다. 이것은 좋지 않습니다 .

이 주제에 대한 당신의 생각은 근시안적이라고 말하고 싶습니다. 당신은 않는 그 물건이 필요합니다. 유지되는 GUI가 제공하는 것이 필요합니다. 아, 특정 GUI 시스템이 제공하는 모든 것이 필요하지 않을 수도 있습니다 . 그러나 당신은 그것의 일부가 필요합니다.

시스템에 데이터를 가져 오기 위해 수행해야하는 상용구 작업은 사용자가 컨트롤과 올바르게 상호 작용할 수 있고 플레이어의 요구에 맞게 크기가 조정될 것이라는 합리적인 확신을 얻는 것보다 적은 비용입니다.

플레이어로부터 많은 사용자 입력을받지 않으면 즉시 모드 GUI를 사용하지 못할 수도 있습니다. 그러나 그것은 그것에 관한 것입니다.

전 IMGUIs 또한 내 관심을 잡은 동안은, 테스트 나는이 기술로 자신을 익숙해 자습서의 몇 가지를 썼다 (시작 여기에 당신이 경우에있는 거 관심이 있지만, 훨씬 더 C #을 / XNA + 원본보다이 아니다 '튜토리얼' 여기 ) .

나는 그들이 표시하는 정보가 항상 최신이고 정확하기 때문에 IMGUI를 아주 좋아했습니다 (항상 실제 데이터에 피드하는 상태가 없기 때문에). 그러나 결국 나는 관심을 잃었으므로 이제 정상적으로 유지 된 GUI를 다시 사용합니다.

결국 GUI의 즉각적인 점으로 인해 GUI를 데이터와 분리하는 것이 더 어려워지고 때로는 IMGUI의 우아함을 깨는 상태를 도입하여 더 많은 것을 분리하려고 시도했습니다. 또한 유지 된 GUI 용 코드를 작성하는 것이 IMGUI 용 코드를 작성하는 것보다 더 효과적이라고 생각하지 않으며 유지 된 GUI를 실행하여 잊어 버릴 수 있으며 이벤트를 좋아합니다. :)

그러나 누군가가 IMGUI를 언급 할 때마다 내 안의 무언가가 다시 시도하고 그것을 올바르게 얻기 위해 더 열심히 노력하고 있습니다. 실제로 우아함이 있기 때문에 항상 작업을 더 쉽게 할 수 있는지 100 % 확신 할 수 없습니다. 나는 그것을 시도하고, 아마도 내가했던 것처럼 시도하고 튜토리얼을 작성한다고 말하고 싶습니다 (새로운 기술을 배우는 가장 좋은 방법은 다른 사람들에게 설명하는 것입니다).

나는 당신이 설명한대로 작동하는 Unity3D GUI 시스템으로 많은 일을했습니다. 그리고 나는 열정으로 그것을 싫어합니다.

경우에 따라 "즉시"접근 방식이 실제로 효과적입니다. 먼저, 몇 개의 버튼과 라벨 만 필요한 경우, 예를 들어 shooter HUD를 생각하십시오. "보존 된"접근 방식으로 생성하는 것은 그리 어렵지 않지만 UnityGUI를 사용하면 매우 쉽습니다. 두 번째 경우는 화면에 많은 컨트롤을 채워야하지만 실제로는 레이아웃에 신경 쓰지 않는 경우입니다. 특히 정확한 컨트롤이 런타임에만 알려진 경우. 이것은 실제로 모든 게임에서 유용하지는 않지만 Unity 에디터 내에서 도구를 실행할 때 실제로 유용합니다.

그러나 (MMO) RPG 또는 전략 게임과 같은 반 복잡한 GUI는 필연적으로 특별한 경우로 가득 차고 수많은 방법으로 깨지기 쉬운 코드의 끔찍한 혼란으로 바뀝니다. 이러한 GUI를 빌드 할 때 일반적으로 모든 해상도에서 작동하고 전송하는 모든 데이터를 표시 할 수있는 매우 구체적인 레이아웃이 있습니다. 더 긴 텍스트를 만들기 위해 일부 버튼을 아래로 이동하는 것과 같은 것들이 필요합니다. "보유 된"GUI를 사용하면 자동으로 제어 할 수 있습니다. "즉시"모드에서는 컨트롤 이 없으므로 모든 것을 명시 적으로 수행해야합니다.

UnityGUI의 또 다른 문제점 (예 : 모든 즉각적인 모드 GUI에서 발생하는지 확실하지 않음)은 Button()다른 GUI 호출을 고려하지 않고 호출이 작동한다는 것입니다. 따라서 한 버튼이 다른 버튼 위에 있으면 클릭하면 두 버튼이 동시에 눌려 집니다. 이것은 분명히 사용자가 기대하는 것이 아니므로 처리해야 할 또 다른 특별한 경우가 추가됩니다.

이 모든 것을 살기 위해, 나는 항상 UnityGUI 주위에 자체 래퍼를 작성하여이를 "보존"모드 시스템으로 바 꾸었습니다. 자체 상태를 저장하고 GUI매 프레임마다 필요한 함수를 호출하는 컨트롤입니다 .

"즉시"모드가 "보유"보다 확실히 나쁘다고 말할 수는 없지만 "보유"모드에서 작업하는 것이 훨씬 더 좋습니다.

이전에 나열된 일부 문제는 기꺼이 코드를 작성하여 해결할 수 있기 때문에 IMGUI를 방어하려고합니다. 또한 코드를 작성하면 재사용 가능한 강력한 라이브러리가 있으며 수정이 거의 필요하지 않습니다.

• 스키마에서 GUI로드

아마도 처음에는 아티스트가 IMGUI에 대한 유연성이 많지 않은 것 같습니다. 이는 XML 또는 JSON 스키마에서 GUI 레이아웃을로드하여 해결되거나 향상됩니다.

• 메뉴 레이어 그리기 호출

이 문제는 정렬로 해결되며 그리기 순서를 정렬하는 UI 관리자 클래스를 만들어야합니다 .C # XNA 에서이 문제를 서로 움직일 수있는 클릭 가능한 패널로 해결했습니다. 요청하면 의사 코드를 게시 할 수 있습니다.

• 리스트 박스

배열에서 문자열을 그릴 수 있습니까? 해당 문자열의 글꼴 높이와 너비에서 직사각형 영역을 정의 할 수 있습니까? 함께 추가 된 모든 사각형의 높이로 스크롤 버튼 크기의 비율을 만들 수 있습니까? 그런 다음 스크롤 가능한 버튼을 사용하여 위 또는 아래로 이동하는 목록 상자를 만드는 중반입니다. 나는 그것이 어려울 것이라고 생각했지만 생각보다 훨씬 더 간단하다는 것이 밝혀졌습니다. 버퍼, 상태, 콜백이 없습니다.

• GUI에서 데이터 분리

개별 패널, 버튼, 상자에 데이터를 보관하지 마십시오. 나는 IMGUI를 처음 시도했을 때 즉각적인 것이었지만 그래픽적인 의미 만 있음을 알고 있습니다. 나는 UI에 데이터를 유지하는 실수를했다. UI 변경을 통해 데이터를 배치하고 수정하는 위치를 다르게 생각하는 것은 거의 철학적으로 바뀌 었습니다.

• SDK의 GUI

이것은 귀하의 코드가 아닌 SDK 코드의 한계와 기능입니다. SDK UI (Hammer, Unity, UDK)는 어쨌든 배울 새로운 언어입니다. 사실 그들은 Windows와 비슷합니다. 양식은 모두 가장 넓은 가능성을 위해 설정되어 있으며 그로 인해 복잡성이 추가됩니다.

마지막으로 이것을보십시오> http://mollyrocket.com/861

사용자 인터페이스는 일반적으로 자동 레이아웃되거나 크기 조정 가능한 창을 즉시 가질 필요가 없습니다. 대신 항상 변화하는 데이터 (세계의 3D 모델 위치)와 매우 효율적으로 상호 작용해야합니다.

장르와 게임에 따라 다릅니다. 좋은 재고 관리 시스템은 대부분의 RPG에 필수적입니다. Retained GUI를 사용하여 레이아웃을 처리하고 스크롤 막대, 드래그 앤 드롭, 툴팁 및 기타 기능을 훨씬 쉽게 구현할 수있는 기능을 원할 것입니다.

Z 버퍼를 일시적으로 변경하고 시간 정보를 저장하여 이동하는 동안 발생하는 클릭을 배제하는 등 많은 저글링이나 사용자 상태 저장을 필요로하지 않는 즉각적인 GUI로 n'drop을 드래그하는 방법을 생각할 수 없습니다. 비트.

그러나 디자인 관점에서 GUI 이벤트가없는 세상을 상상하는 데 어려움이 있습니다. 또한 즉시 GUI는 OOP와 호환되지 않으므로 절차 적 프로그래밍에 의존해야합니다.

즉각적인 GUI가 제공하는 단순성은 UI에 필요한 복잡성이 증가함에 따라 코드의 추가 복잡성으로 인해 증가합니다. 잘 유지되는 GUI는 원래 더 복잡하지만 확장 성이 좋습니다. 따라서 특정 복잡성 아래에서 즉각적인 GUI가 적합하지만 대부분의 경우 GUI를 유지하는 것이 좋습니다.