GUI ngay lập tức - yae hay nay? [đóng cửa]

Tôi đã làm việc về phát triển ứng dụng với rất nhiều hệ thống GUI "được giữ lại" (bên dưới là những gì tôi muốn nói) như MFC, QT, Forms, SWING và một số khung GUI web cách đây vài năm. Tôi luôn thấy các khái niệm của hầu hết các hệ thống GUI quá phức tạp và vụng về. Số lượng sự kiện gọi lại, người nghe, bản sao dữ liệu, thứ gì đó để xâu chuỗi thành thứ gì đó - chuyển đổi (v.v.) luôn là nguồn gốc của những sai lầm và đau đầu so với các phần khác trong ứng dụng. (Ngay cả với việc sử dụng "đúng" các ràng buộc / mô hình dữ liệu).

Bây giờ tôi đang viết trò chơi máy tính :). Tôi đã làm việc với một GUI cho đến nay: Miyagi (không nổi tiếng, nhưng về cơ bản là cùng một ý tưởng với tất cả các hệ thống khác.)

Thật là kinh khủng.

Đối với các môi trường kết xuất thời gian thực như Trò chơi, tôi có cảm giác rằng các hệ thống GUI "được giữ lại" thậm chí còn lỗi thời hơn. Giao diện người dùng thường không cần phải được bố trí tự động hoặc có cửa sổ thay đổi kích thước nhanh chóng. Thay vào đó, họ cần tương tác rất hiệu quả với dữ liệu luôn thay đổi (như vị trí 3d của các mô hình trên thế giới)

Cách đây vài năm, tôi tình cờ phát hiện ra "IMGUI" về cơ bản giống như chế độ Đồ họa tức thời, nhưng dành cho giao diện người dùng. Tôi đã không chú ý quá nhiều, vì tôi vẫn đang trong quá trình phát triển ứng dụng và bản thân cảnh quay IMGUI dường như không thực sự rộng cũng không thành công. Tuy nhiên, cách tiếp cận mà họ đưa ra dường như vô cùng gợi cảm và thanh lịch, đến nỗi nó khiến tôi muốn viết một cái gì đó cho dự án tiếp theo bằng cách sử dụng giao diện người dùng này (tôi đã thất bại trong việc thuyết phục bất cứ ai tại nơi làm việc: (...)

hãy để tôi tóm tắt những gì tôi có nghĩa là "giữ lại" và "ngay lập tức":

GUI được giữ lại: Trong giai đoạn khởi tạo riêng biệt, bạn tạo "điều khiển GUI" như Nhãn, Nút, TextBoxes, v.v. và sử dụng một số cách mô tả (hoặc lập trình) để đặt chúng trên màn hình - tất cả trước khi mọi thứ được hiển thị. Các điều khiển giữ hầu hết trạng thái của chúng trong bộ nhớ như vị trí X, Y, kích thước, đường viền, điều khiển con, văn bản nhãn, hình ảnh, v.v. Bạn có thể thêm các cuộc gọi lại và người nghe để được thông báo về các sự kiện và cập nhật dữ liệu trong điều khiển GUI.

GUI ngay lập tức: Thư viện GUI bao gồm các chức năng "RenderButton", "RenderLabel", "RenderTextBox" ... (chỉnh sửa: không bị nhầm lẫn bởi Rendertiếp đầu ngữ. Các chức năng này cũng thực hiện logic đằng sau các điều khiển như bỏ phiếu nhập của người dùng, chèn ký tự, xử lý tốc độ lặp lại ký tự khi người dùng giữ phím và vv ... mà bạn có thể gọi để "ngay lập tức" hiển thị điều khiển (không ' Phải được ghi ngay lập tức vào GPU. Thông thường, nó được ghi nhớ cho khung hiện tại và được sắp xếp thành các lô thích hợp sau này). Thư viện không giữ bất kỳ "trạng thái" nào cho những thứ này. Nếu bạn muốn ẩn một nút ... chỉ cần đừng gọi chức năng RenderButton. Tất cả các hàm RenderXXX có tương tác người dùng như nút hoặc hộp kiểm có giá trị trả về cho biết liệu người dùng có nhấp vào nút hay không. Vì vậy, "RenderGUI" của bạn Hàm trông giống như một hàm if / khác lớn trong đó bạn gọi hoặc không gọi các hàm RenderXXX tùy thuộc vào trạng thái trò chơi của bạn và tất cả logic cập nhật dữ liệu (khi nhấn nút) được xen kẽ vào luồng. Tất cả lưu trữ dữ liệu là "bên ngoài" gui và chuyển theo yêu cầu cho các chức năng Kết xuất. (Tất nhiên, bạn sẽ chia các hàm lớn thành nhiều hàm hoặc sử dụng một số tóm tắt lớp để nhóm các phần của gui. Chúng ta không viết mã như năm 1980 nữa, phải không?))

Bây giờ tôi thấy rằng Unity3D thực sự sử dụng cách tiếp cận cơ bản rất giống với các hệ thống GUI tích hợp của họ. Có lẽ có một vài GUI với cách tiếp cận này ngoài kia?

Tuy nhiên, khi nhìn xung quanh, dường như có sự thiên vị mạnh mẽ đối với các hệ thống GUI được giữ lại? Ít nhất tôi đã không tìm thấy cách tiếp cận này ngoại trừ trong Unity3D và cộng đồng IMGUI ban đầu dường như khá .... yên tĩnh.

Vì vậy, bất cứ ai làm việc với cả hai ý tưởng và có một số ý kiến ​​mạnh mẽ?

Chỉnh sửa: Tôi quan tâm nhất đến các ý kiến ​​xuất phát từ kinh nghiệm thực tế. Tôi nghĩ rằng có rất nhiều cuộc thảo luận sôi nổi trên diễn đàn IMGUI về bất kỳ "điểm yếu lý thuyết" nào của phương pháp GUI ngay lập tức, nhưng tôi luôn thấy rõ hơn khi biết về những điểm yếu trong thế giới thực .

Không. Tôi đã hoàn thành công việc gamedev trả tiền trên GUI 'chế độ giữ lại' khủng khiếp và trên GUI 'chế độ tức thời' khủng khiếp và mặc dù cả hai đều khiến tôi muốn rời mắt, cách tiếp cận chế độ giữ lại rõ ràng vẫn là phương pháp tốt hơn.

Nhược điểm của chế độ ngay lập tức là rất nhiều:

• họ không làm cho các nghệ sĩ và nhà thiết kế dễ dàng cấu hình bố cục;
• họ làm cho bạn trộn logic với cách trình bày;
• chúng làm cho khó có một mô hình đầu vào nhất quán duy nhất;
• họ không khuyến khích các điều khiển phức tạp của dữ liệu động (ví dụ: chế độ xem danh sách);
• layering trở nên rất khó xử (ví dụ: nếu tôi gọi RenderComboBox, hộp thả xuống có thể chưa thể kết xuất được vì nó cần phải vượt lên trên phần còn lại của cửa sổ - tương tự cho mẹo công cụ) l
• cấu hình kiểu kết xuất cuối cùng được thực hiện với toàn cục (ick) hoặc đối số hàm bổ sung (ick);
• hiệu suất có thể kém vì gọi tất cả các hàm này đến các giá trị truy vấn có thể thay đổi hoặc có thể không thay đổi có xu hướng tạo ra nhiều đối tượng nhỏ, nhấn mạnh trình quản lý bộ nhớ;
• ... và tôi thậm chí không thể tưởng tượng được sẽ đau đớn thế nào khi cho phép ai đó kéo các bit GUI xung quanh và sắp xếp lại chúng. Bạn sẽ phải duy trì cấu trúc dữ liệu cho bạn biết nơi hiển thị mọi thứ - giống như tự viết lại hệ thống chế độ được giữ lại.

GUI chế độ ngay lập tức đang hấp dẫn các lập trình viên đơn độc muốn có hệ thống HUD nhanh chóng và vì mục đích đó, chúng rất tuyệt. Đối với bất cứ điều gì khác ... chỉ cần nói không.

Là một người có năm hoặc sáu năm kinh nghiệm thực tế với IMGUI trên máy tính để bàn, tôi cảm thấy bắt buộc phải bảo vệ nó. Tất cả các câu trả lời (và chính câu hỏi) đều dựa trên định nghĩa rất hạn chế của IMGUI và dường như có rất nhiều yêu cầu đáng ngờ được đưa ra.

Rất nhiều trong số đó bắt nguồn từ giả định rằng một thư viện IMGUI không thể giữ lại bất kỳ dữ liệu nào. Điều này không đúng chút nào. Một thư viện IMGUI tinh vi trên thực tế sẽ giữ lại nhiều dữ liệu như một thư viện RMGUI tương đương. Sự khác biệt là một thư viện IMGUI chủ yếu lưu trữ kết quả, trong khi thư viện RMGUI duy trì trạng thái có thẩm quyền. Trong IMGUI, ứng dụng cung cấp một hàm lấy trạng thái mô hình hiện tại và tạo GUI cho trạng thái đó. Đây là định nghĩa có thẩm quyền của GUI. Thư viện chịu trách nhiệm đảm bảo rằng GUI trên màn hình khớp với kết quả của chức năng đó. Điều này không có nghĩa là nó cần đánh giá đầy đủ chức năng đó từng khung và xây dựng lại hoàn toàn GUI. Đó là điểm của bộ nhớ đệm.

Với quan điểm này của IMGUI, trên thực tế bạn có thể thực hiện bố cục nâng cao và hiệu suất khá hợp lý. Bạn cũng có thể giữ lại trạng thái có thẩm quyền thực tế nếu nó làm cho giao diện dễ dàng hơn. Quan điểm của IMGUI là không làm cho ứng dụng giữ lại mọi thứ. Ứng dụng có thể không muốn lưu trữ vị trí của mọi thanh cuộn và trạng thái mở rộng / thu gọn của mỗi nút cây. Vấn đề là có thể xác định thủ tục nội dung của các nút cây đó và chính sự tồn tại của chúng.

Tôi sẽ đi qua và trả lời tất cả những lời chỉ trích của IMGUI, nhưng tôi thực sự không hiểu nhiều về họ. Hầu hết trong số họ dường như xuất phát từ một số niềm tin cơ bản rằng IMGUI là hackish và RMGUI có cấu trúc tốt, mà tôi đoán bắt nguồn từ những hiểu lầm ở trên. Không có lý do cố hữu rằng các thư viện IMGUI sẽ gặp rắc rối với sự phức tạp hoặc phải bị vấy bẩn bởi toàn cầu hoặc trộn logic với trình bày. Tôi sẽ nói rằng những lợi thế của IMGUI trở nên ít quan trọng hơn khi nội dung của bạn được điều khiển bởi nghệ sĩ nhiều hơn, nhưng tôi không chắc tại sao nó thực sự tồi tệ hơn đối với nội dung do nghệ sĩ điều khiển. (Cá nhân tôi không sử dụng nội dung do nghệ sĩ điều khiển, ngoài các biểu định kiểu cho những thứ như màu sắc, kích thước phông chữ / đường viền, v.v., nhưng tôi không hiểu tại sao nó khó thực hiện hơn so với RMGUI.)

Trong tâm trí của tôi, IMGUI chắc chắn là một điều tốt. Nó cung cấp cho bạn một mô hình tốt hơn nhiều để lý luận về GUI của bạn. Nó trở nên nhiều chức năng và phản ứng hơn, và bạn giảm thiểu số lượng trạng thái có thể thay đổi mà bạn phải lý do. Mặt khác, việc thực hiện một thư viện IMGUI tinh vi là một thách thức và chắc chắn khó khăn hơn so với việc thực hiện một thư viện RMGUI tương đương. Đó là sự đánh đổi giữa độ phức tạp của thư viện và độ phức tạp của ứng dụng. Nếu bạn đang có kế hoạch xây dựng các ứng dụng phức tạp (hoặc thậm chí rất nhiều ứng dụng đơn giản), thì sự đánh đổi là rất tốt. Nếu bạn đang làm điều này cho một ứng dụng duy nhất và nó khá đơn giản, có lẽ bạn sẽ đạt được mục tiêu của mình nhanh hơn với RMGUI.

Dù thế nào đi nữa, chúc may mắn!

Thư viện GUI bao gồm các hàm "RenderButton", "RenderLabel", "RenderTextBox" ... mà bạn có thể gọi để "ngay lập tức" kết xuất một điều khiển (không phải ghi ngay lập tức vào GPU. cho khung hiện tại và sắp xếp thành các đợt thích hợp sau).

Tôi sẽ đi xa hơn để nói rằng điều này không tạo thành một thư viện GUI. Nó chỉ là một loạt các chức năng kết xuất.

Kết xuất GUI là phần dễ nhất để tạo GUI. Lấy một hộp văn bản chẳng hạn. Tôi sẽ giả sử trường hợp dễ nhất có thể: một hộp văn bản nhập một dòng đơn giản.

RenderTextBoxsẽ chỉ vẽ một hộp văn bản. Nó sẽ thực hiện một số phép đo văn bản đơn giản và vẽ các hình tượng trên màn hình. Nó sẽ không

• Phát hiện người dùng đã nhấp chuột trong điều khiển và di chuyển con trỏ đến vị trí thích hợp trong chuỗi.
• Phát hiện người dùng nhấp đúp chuột vào điều khiển và chọn một khối văn bản.
• Phát hiện người dùng nhấn phím "Home" và di chuyển con trỏ đến phía trước văn bản.
• Phát hiện người dùng nhấn một phím hợp lệ và sửa đổi chuỗi cho phù hợp. Nếu văn bản được chọn, phần được chọn sẽ được thay thế bằng văn bản được chèn.

Tôi có thể tiếp tục, nhưng tôi nghĩ quan điểm của tôi là rõ ràng. Nếu bạn muốn sử dụng RenderTextBoxđể vẽ một hộp văn bản, tất cả những gì bạn sẽ nhận được là một hộp văn bản tĩnh, không có chức năng. Bất kỳ chức năng thực tế phải được thực hiện bởi bạn.

Làm văn bản đo lường và vẽ glyphs? Đó là phần dễ dàng của công việc GUI. GUI là viết tắt của "Giao diện người dùng đồ họa". Hai từ cuối cùng, nơi bạn lấy đầu vào từ người dùng và làm một cái gì đó với nó, là phần khó.

Người chơi trò chơi mong muốn các điều khiển GUI hoạt động hợp lý. Trong môi trường kiểu PC (ví dụ: chuột và bàn phím), nếu người chơi nhìn thấy hộp văn bản, họ mong đợi nó hoạt động như một hộp văn bản thông thường. Họ hy vọng có thể di chuyển trong đó bằng các phím mũi tên, nhảy lên phía trước và kết thúc với nhà và xóa, chọn các chữ cái trong đó, v.v.

Điều đó có nghĩa là bạn sẽ phải thực hiện tất cả mã UI này. Bạn phải kiểm tra những gì kiểm soát đã được bấm. Sau đó, bạn phải làm một cái gì đó dựa trên điều khiển nào được nhấp. Bạn phải có khái niệm về điều khiển "hoạt động", điều khiển được nhập bằng bàn phím. Các điều khiển khác nhau phải đáp ứng khác nhau đối với các loại tương tác người dùng khác nhau.

Về cơ bản, bạn sẽ cần một TextBoxWindowlớp học.

Giả sử bạn đang thực hiện màn hình tùy chọn trò chơi. Vì vậy, bạn có các nhóm tùy chọn khác nhau: trò chơi, đồ họa, âm thanh, điều khiển, v.v ... Vì vậy, bạn có một danh sách các nhóm khác nhau ở bên trái màn hình. Mỗi nhóm đưa ra một loạt các điều khiển mà người dùng có thể thao tác. Điều gì xảy ra khi người dùng nhấn phím Tab?

Vâng, nó phụ thuộc vào những gì kiểm soát đang hoạt động. Nếu một trong các điều khiển nhóm được kích hoạt (được nhấp gần đây nhất), thì nó sẽ chuyển sang nhóm tiếp theo. Nếu thay vào đó, một trong các điều khiển trong nhóm được kích hoạt, thì nó sẽ chuyển sang điều khiển tiếp theo trong nhóm đó. Đó là cách hệ thống dự định hoạt động.

Vì vậy, không chỉ phải nhập một bàn phím quá trình điều khiển hoạt động, giờ đây nó còn phải nhập bất kỳ đầu vào chưa được xử lý nào vào điều khiển sở hữu nó. Hoặc là, hoặc các điều khiển phải nằm trong một số loại danh sách được liên kết, để nó có thể qua lại. Điều đó có nghĩa là cần phải có hành vi mặc định trong mỗi điều khiển.

Điều này nghe có vẻ giống như một GUI được giữ lại, phải không? Sự khác biệt duy nhất là ... bạn là người làm việc chăm chỉ. Sử dụng GUI của ai đó được cho là một cách để làm ít việc hơn. Nhưng nỗ lực cần có để làm cho GUI phản hồi như người dùng mong đợi là không tầm thường.

Hãy nhớ rằng: UI không dành cho bạn, nó dành cho người dùng của bạn . Nó dành cho người chơi. Nó nên cư xử như họ mong đợi. Và nếu không, thì bạn đã thất bại.

Giao diện người dùng thường không cần phải được bố trí tự động hoặc có cửa sổ thay đổi kích thước nhanh chóng.

Đó là một suy nghĩ hạn chế và hạn chế.

Tôi có thể cung cấp cho các bài diển văn về trò chơi khác nhau có nhu cầu giao diện người dùng khác nhau, mà một số trò chơi làm cần cửa sổ resizeable và vân vân. Nhưng có một vấn đề lớn hơn nhiều.

Kiểu suy nghĩ của bạn dẫn đến vấn đề Trận chiến không gian Gratuitous.

Nếu bạn chưa bao giờ chơi trò chơi đó, thì đó là một trò chơi rẻ tiền, độc lập và rất nặng về GUI. Tất cả các trò chơi thực tế đều được thực hiện trong GUI (đó là loại trò chơi "thiết lập các đơn vị và xem chúng chiến đấu"). Vấn đề?

GUI KHÔNG THỂ ĐƯỢC GIẢI QUYẾT!

Ồ, điều này tốt nếu bạn đang sử dụng màn hình bình thường hoặc có thị lực bình thường. Nhưng nếu bạn là tôi, ví dụ, người điều hành một màn hình khổng lồ lố bịch (một cái lớn đến mức bạn có Windows mở rộng kích thước của tất cả văn bản để bạn thực sự có thể đọc nó), điều này thật tồi tệ . Các văn bản là kính hiển vi. Không có cách nào để thay đổi kích thước phông chữ.

Cấp, GSB là một trò chơi dựa trên GUI, vì vậy nó hoàn toàn không thể sử dụng được cho họ. Một trò chơi GUI-lite có thể thoát khỏi nó.

Đừng bao giờ cho rằng người dùng của bạn đang nhìn vào trò chơi của họ chính xác như bạn. Làm như vậy là điên rồ.

Có một hệ thống GUI có thể tự điều chỉnh theo độ phân giải của người dùng, GUI thực sự độc lập với độ phân giải, đòi hỏi bố cục phải là một phần của chính hệ thống GUI. Nếu bạn không cung cấp điều đó, thì văn bản của bạn sẽ xuất hiện nhỏ trên màn hình khổng lồ của ai đó. Đây không phải là một điều tốt.

Vì vậy, tôi sẽ nói rằng suy nghĩ của bạn về chủ đề này là thiển cận. Bạn làm cần những thứ đó. Bạn cần những gì GUI giữ lại cung cấp. Ồ, bạn có thể không cần mọi thứ mà bất kỳ hệ thống GUI cụ thể nào cung cấp. Nhưng bạn cần một số của nó.

Công việc soạn sẵn mà bạn cần làm để lấy dữ liệu vào hệ thống là một cái giá nhỏ phải trả bên cạnh việc đảm bảo hợp lý rằng người dùng có thể tương tác với các điều khiển một cách chính xác và nó sẽ tự thay đổi kích thước để phù hợp với nhu cầu của người chơi.

Bạn có thể thoát khỏi GUI ở chế độ tức thời nếu bạn không lấy nhiều dữ liệu người dùng từ trình phát. Nhưng đó là về nó.

Cách đây một thời gian, IMGUI cũng thu hút sự chú ý của tôi, vì một bài kiểm tra tôi đã viết một vài hướng dẫn để làm quen với các kỹ thuật (bắt đầu ở đây nếu bạn quan tâm, nhưng nó không nhiều hơn C # / XNA + 'hướng dẫn' ban đầu ở đây ) .

Tôi thực sự thích IMGUI trong một thời gian ngắn vì thông tin họ hiển thị luôn cập nhật và chính xác (vì không có trạng thái bạn luôn cung cấp dữ liệu thực tế). Nhưng cuối cùng tôi đã mất hứng thú nên bình thường bây giờ tôi lại sử dụng GUI được giữ lại.

Cuối cùng, tôi nghĩ rằng tính mới của GUI khiến việc tách GUI khỏi dữ liệu trở nên khó khăn hơn và đôi khi tôi đã cố gắng tách rời mọi thứ nhiều hơn bằng cách giới thiệu một số trạng thái, phá vỡ sự thanh lịch của IMGUI. Tôi cũng không nghĩ rằng viết mã cho GUI giữ lại là công việc nhiều hơn viết mã cho IMGUI và tôi thích rằng GUI được giữ lại có thể bị hủy và quên, và tôi thực sự thích các sự kiện :).

Tuy nhiên, mỗi khi ai đó đề cập đến những điều gì đó trong tôi muốn thử lại, và cố gắng hơn để làm cho đúng, bởi vì thực sự có một sự tao nhã trong đó, tôi chỉ không chắc chắn 100% rằng nó sẽ luôn giúp công việc của bạn dễ dàng hơn. Tôi muốn nói hãy thử, có thể thử như tôi đã làm và viết một số hướng dẫn (tôi thấy cách tốt nhất để học các kỹ thuật mới là bằng cách giải thích chúng cho người khác).

Tôi đã làm việc rất nhiều với hệ thống GUI Unity3D, hoạt động đúng như bạn mô tả. Và tôi phải nói rằng, tôi ghét nó với một niềm đam mê.

Phương pháp "ngay lập tức" hoạt động thực sự tốt trong một số trường hợp. Đầu tiên, khi bạn chỉ cần một vài nút và nhãn - ví dụ như nghĩ về game bắn súng HUD. Tạo chúng theo phương pháp "giữ lại" không khó lắm, nhưng cực kỳ dễ với UnityGUI. Trường hợp thứ hai là khi bạn cần nhét nhiều điều khiển trên màn hình, nhưng không thực sự quan tâm đến bố cục. Đặc biệt là khi các điều khiển chính xác chỉ được biết đến trong thời gian chạy. Điều này thực sự không hữu ích trong bất kỳ trò chơi nào, nhưng thực sự hữu ích khi tạo các công cụ chạy bên trong trình soạn thảo Unity.

Tuy nhiên, bất kỳ GUI nửa phức tạp nào - ví dụ như cho một game nhập vai (MMO) hoặc trò chơi chiến lược - chắc chắn sẽ biến thành một mớ hỗn độn khủng khiếp của mã không thể giải mã, đầy những trường hợp đặc biệt và phá vỡ hàng tấn cách. Khi xây dựng một GUI như vậy, bạn thường có bố cục khá cụ thể phải hoạt động cho mọi độ phân giải và có thể hiển thị bất kỳ dữ liệu nào bạn gửi theo cách của mình. Bạn cần những thứ như, ví dụ, di chuyển một số nút thấp hơn để nhường chỗ cho văn bản dài hơn. Với GUI "được giữ lại", bạn có thể có một điều khiển tự động. Với chế độ "ngay lập tức", không có điều khiển, vì vậy bạn phải làm mọi thứ rõ ràng.

Một vấn đề khác với UnityGUI (không chắc nó có xảy ra với tất cả các GUI chế độ tức thời hay không) là, ví dụ, một Button()cuộc gọi hoạt động mà không xem xét bất kỳ cuộc gọi GUI nào khác. Vì vậy, nếu một nút nằm trên nút khác, một lần nhấp sẽ nhấn cả hai nút cùng một lúc. Đây chắc chắn không phải là những gì người dùng mong đợi, vì vậy điều này thêm một trường hợp đặc biệt khác để xử lý.

Để sống với tất cả những điều này, tôi đã luôn viết trình bao bọc của riêng mình xung quanh UnityGUI để biến nó thành một hệ thống chế độ "giữ lại": điều khiển lưu trữ trạng thái của riêng chúng và chỉ gọi các GUIchức năng cần thiết cho mọi khung hình cho tôi.

Tôi không thể nói rằng chế độ "ngay lập tức" chắc chắn tệ hơn chế độ "giữ lại", nhưng tôi chắc chắn cảm thấy làm việc tốt hơn nhiều trong chế độ "giữ lại".

Tôi sẽ bảo vệ IMGUI ở đây vì một số vấn đề được liệt kê trước đây có thể được giải quyết nếu bạn sẵn sàng viết mã cho nó. Ngoài ra, nếu bạn viết mã cho nó thì bạn có một thư viện mạnh mẽ có thể sử dụng lại được và chỉ rất hiếm khi yêu cầu sửa đổi.

• tải GUI từ lược đồ

có lẽ lúc đầu, dường như các nghệ sĩ không có nhiều sự linh hoạt với IMGUI, điều này đã được giải quyết hoặc cải thiện với việc tải bố cục GUI từ lược đồ xml hoặc JSON.

• lớp menu vẽ cuộc gọi

vấn đề này được giải quyết bằng cách sắp xếp, bạn nên tạo lớp UI Manager sắp xếp thứ tự vẽ, tôi đã giải quyết vấn đề này trong C # XNA bằng các bảng có thể di chuyển, có thể nhấp vào nhau. Tôi có thể gửi mã giả nếu được hỏi.

• hộp danh sách

bạn có thể vẽ chuỗi từ một mảng? bạn có thể xác định các khu vực hình chữ nhật từ chiều cao và chiều rộng của phông chữ của các chuỗi đó không? bạn có thể tạo tỷ lệ kích thước của nút cuộn theo chiều cao của tất cả các hình chữ nhật được cộng lại không? Sau đó, bạn đang đi được nửa đường để tạo một hộp danh sách với nút có thể cuộn để di chuyển lên hoặc xuống. Tôi nghĩ rằng nó sẽ khó khăn, nhưng hóa ra nó đơn giản hơn nhiều so với tôi nghĩ. không có bộ đệm, không có trạng thái, không có cuộc gọi lại liên quan.

• tách dữ liệu khỏi GUI

không để các bảng, nút, hộp riêng lẻ giữ dữ liệu. Tôi biết rằng trong nỗ lực đầu tiên của tôi về IMGUI là ngay lập tức nhưng chỉ trong ý nghĩa đồ họa. Tôi đã phạm sai lầm trong việc giữ lại dữ liệu trên UI. Nó gần như là một sự thay đổi triết học để suy nghĩ khác nhau về nơi đặt và sửa đổi dữ liệu thông qua các thay đổi UI.

• GUI từ SDK

đây là giới hạn và chức năng của mã SDK, không phải của bạn. Tôi thấy rằng SDK UI (Hammer, Unity, UDK) gần như là một ngôn ngữ mới để học. Trên thực tế, chúng tương tự như tôi như Windows.Forms, cả hai đều được thiết lập cho khả năng rộng nhất và do đó có một số trọng lượng tăng thêm về độ phức tạp.

và cuối cùng xem này> http://mollyrocket.com/861

Giao diện người dùng thường không cần phải được bố trí tự động hoặc có cửa sổ thay đổi kích thước nhanh chóng. Thay vào đó, họ cần tương tác rất hiệu quả với dữ liệu luôn thay đổi (như vị trí 3d của các mô hình trên thế giới)

Nó phụ thuộc vào thể loại và trò chơi trong câu hỏi. Một hệ thống quản lý hàng tồn kho tốt là điều tối quan trọng đối với hầu hết mọi game nhập vai. Bạn sẽ muốn một cái gì đó xử lý bố cục cho bạn, hỗ trợ các thanh cuộn, kéo thả, chú giải công cụ và các tính năng khác dễ dàng hơn nhiều để thực hiện bằng GUI Giữ lại.

Tôi không thể nghĩ ra cách kéo thả bằng một GUI ngay lập tức mà không mất nhiều công sức hoặc tiết kiệm trạng thái người dùng như thay đổi bộ đệm Z tạm thời và lưu trữ thông tin thời gian để loại trừ một nhấp chuột xảy ra để di chuyển bit

Nhưng từ góc độ thiết kế, tôi gặp khó khăn khi tưởng tượng một thế giới không có sự kiện GUI của tôi. Ngoài ra, GUI ngay lập tức không tương thích với OOP buộc bạn phải dùng đến lập trình thủ tục.

Sự đơn giản được cung cấp bởi GUI ngay lập tức phải trả giá bằng sự phức tạp bổ sung trong mã của bạn tăng nhanh khi độ phức tạp mà UI của bạn yêu cầu tăng lên; trong đó một GUI giữ lại tốt ban đầu phức tạp hơn nhưng tỷ lệ tốt hơn. Vì vậy, dưới một điểm phức tạp nhất định, GUI ngay lập tức là đủ nhưng đối với hầu hết các tình huống tôi muốn sử dụng GUI được giữ lại.