Hệ thống thực thể / thành phần và giao diện người dùng

Tôi vẫn còn xanh cho các hệ thống thực thể / thành phần. Tôi thấy rằng vì tôi có các thành phần hữu ích để vẽ các họa tiết (hoặc spritesheets) và xử lý đầu vào (nhấp chuột / chạm), tôi tự nhiên muốn sử dụng lại các thành phần này để tạo các thành phần UI (như các nút, ví dụ như màn hình chọn cấp độ).

Điều này đánh tôi là rất kỳ quặc. Tôi luôn hiểu các thực thể là "mô hình trò chơi" những thứ như người chơi, kẻ thù, tăng sức mạnh, v.v. Mặt khác, từ góc độ tái sử dụng mã, việc sử dụng lại các công cụ cho UI có ý nghĩa hoàn hảo.

Làm thế nào (và ở đâu) các mối quan tâm UI / GUI phù hợp với một hệ thống thực thể / thành phần?

(Lưu ý: câu hỏi này là bất khả tri vì nó áp dụng cho nhiều nền tảng / ngôn ngữ)

2d component-based gui

— tro999
nguồn

Tôi nghĩ rằng nó có vẻ hợp lý cho bạn chỉ vì bạn đang làm game 2d. Hãy tưởng tượng bạn sẽ tạo trò chơi 3d (với 2d gui) gần như không có logic kết xuất nào có thể được sử dụng lại và các thành phần gui 2d trong thế giới 3d sẽ không có ý nghĩa nhiều. Bạn nên xây dựng GUI trên đầu hệ thống thành phần. Giống như GameplayScreen của bạn tạo thế giới thực thể với các thành phần và một trong các thành phần sẽ là máy ảnh có "canvas" mà trình kết xuất của bạn sẽ vẽ. Và bức tranh đó sẽ trở thành nền của màn hình đó.

— Kikaimaru

@Kikaimaru bạn có quan điểm về 2D. Có thể tôi quá thích MVC, nhưng có vẻ như là sự pha trộn giữa "model" (thực thể trò chơi) và view / control (các thành phần UI). Nó hoạt động, chắc chắn, nhưng đây có phải là cách nó nên hoạt động? Có cách nào tốt hơn không? Làm thế nào để người khác làm điều đó?

— tro999

@ tro999 bình luận và câu hỏi ban đầu của bạn là từ sâu thẳm trong trái tim tôi :)

— Narek

@Armen Tôi chưa bao giờ có được một câu trả lời thỏa đáng cho điều này.

— tro999

@ tro999 tôi đến. Mọi nơi mọi người nói rằng bạn không nên kết hợp MVC với ECS, nhưng tại sao? Nó không đẹp sao? Vũ khí khác nhau cho các nhiệm vụ khác nhau, bạn không đồng ý?

— Narek

Câu trả lời:

Sau khi sử dụng một số hệ thống thành phần thực thể, đặc biệt là CraftyJS, tôi ít nhiều đã có câu trả lời cho câu hỏi của mình: có, bạn có thể sử dụng lại các thành phần (đặc biệt là các họa tiết hoặc hình ảnh và trình xử lý nhấp chuột trong trò chơi 2D) cho GUI.

Phần lớn thời gian, bạn chỉ có quyền truy cập vào ECS chứ không phải các hệ thống cơ bản (ví dụ: hệ thống vẽ). Trong trường hợp này, sử dụng các thành phần là ổn, vì bạn không có lựa chọn nào khác.

Nếu bạn có quyền truy cập vào hệ thống cơ bản (ví dụ: Ruby roguelike với quyền truy cập trực tiếp vào Curses), bạn có thể thấy rằng vẽ / kết xuất trực tiếp trên hệ thống đó hiệu quả hơn (ít mã hơn, ít dễ vỡ hơn, tự nhiên hơn) so với sử dụng một bó thực thể và các thành phần.

— tro999
nguồn

Nơi nào bạn đặt logic của các yếu tố UI nâng cao? I E. một thanh sức khỏe cần biết khi nào người chơi bị đánh và giảm bao nhiêu thanh. Tôi không thể nhận ra nếu nó cần một hệ thống cụ thể, hoặc một kịch bản hay thứ gì khác ...

— Tiểu vương quốc Lima

@EmirLima cho một cái gì đó tương tự, tôi sẽ đặt hầu hết logic UI vào thanh sức khỏe (thay đổi kích thước thanh sức khỏe) và khiến người chơi tạo ra một sự kiện khi anh ta nhấn, cho biết giá trị sức khỏe mới / thay đổi là gì. (Thanh sức khỏe có thể ghi lại sự kiện này và phản ứng thích hợp.)

— tro999

Nhưng đối tượng thanh sức khỏe trong kiến trúc đó là gì? Đây có phải là một thực thể có thành phần "thanh sức khỏe" không? Một lớp kế thừa từ Thực thể? Một đối tượng bình thường với các cuộc gọi cập nhật được mã hóa cứng?

— Tiểu vương quốc Lima

@EmirLima Tôi sẽ mô hình thanh sức khỏe như một thực thể và người chơi là một thực thể. Bạn có thể làm bất cứ điều gì có ý nghĩa với bạn.

— tro999

Trong 2D hoặc 3D, ít nhất một hệ thống thành phần thực thể (ECS) có quyền truy cập vào hệ thống GUI, nếu đó không phải là một phần của cùng một ECS.

Cá nhân, tôi sẽ không trộn lẫn hai. Khả năng sử dụng lại mã cho GUI chỉ thực sự xảy ra ở cấp cao nhất. Đáp ứng với chuột / bàn phím, kết xuất, v.v. Các chức năng mà các nút khác nhau thực hiện hoặc thông tin mà một số danh sách nhất định hiển thị không thực sự là một cái gì đó đủ chung chung để sử dụng lại.

Ví dụ, tôi sẽ tưởng tượng các thành phần cho các thực thể GUI sẽ giống như thế position, rendervà gui. Trong đó thành phần GUI sẽ xác định loại hành động mà thực thể GUI thực hiện. Tuy nhiên, hành động đó sẽ khá độc đáo và bối cảnh cụ thể. Điều này dẫn đến hệ thống xử lý các thành phần GUI rất lớn và được thiết kế cơ bản để xử lý từng chức năng GUI (tải trò chơi, lưu trò chơi, tìm máy chủ, v.v.). Âm thanh lộn xộn.

Tôi muốn làm một tệp lớp tiêu chuẩn cho mỗi "màn hình" GUI. Có tất cả các chức năng cho màn hình đó ở một nơi (có tham chiếu đến một lớp chức năng chung). Nó gọn gàng hơn và dễ quản lý hơn.

Tuy nhiên, như tôi đã nói, ECS nên có quyền truy cập vào hệ thống GUI. Nó cần có khả năng cung cấp thông tin cho GUI dựa trên các thực thể trong hệ thống của nó. Ví dụ: di chuột qua một đơn vị đồng minh sẽ bật lên một cửa sổ GUI với tất cả thông tin về đơn vị đó. Khi di chuột qua sự thống nhất của kẻ thù sẽ bật lên một cửa sổ GUI với thông tin hạn chế. Bạn có thể không muốn lập trình GUI để biết sự khác biệt giữa hai loại này, bạn muốn yêu cầu thực thể hiển thị thông tin của nó.

Vì vậy, các thực thể vẫn có thể có một số loại thành phần GUI, nhưng chúng sẽ là các thực thể "trong trò chơi", không phải là các thực thể GUI. Thành phần này sẽ sử dụng hệ thống GUI bên ngoài để tạo giao diện GUI của họ.

— MichaelHouse
nguồn

Âm thanh như hệ thống tôi có khá khác so với hệ thống bạn mô tả. Tôi có các lớp thực thể giống như TouchButtonđược tạo thành từ một spritesheet và một trình nghe cảm ứng nhấp chuột. Đối với cửa sổ bật lên đơn vị, tôi có thể sẽ thực hiện đó là sự kết hợp của thành phần sprite + thành phần nghe chuột. Hừm.

— tro999