Đăng ký thành phần đối tượng trò chơi trong hệ thống con trò chơi? (Thiết kế đối tượng trò chơi dựa trên thành phần)

Tôi đang tạo một hệ thống đối tượng trò chơi dựa trên thành phần . Một số lời khuyên:

1. GameObjectchỉ đơn giản là một danh sách Components.
2. Có GameSubsystems. Ví dụ, kết xuất, vật lý, vv Mỗi cái đều GameSubsystemchứa con trỏ đến một số Components. GameSubsystemlà một sự trừu tượng rất mạnh mẽ và linh hoạt: nó đại diện cho bất kỳ lát cắt (hoặc khía cạnh) nào của thế giới trò chơi.

Có một nhu cầu trong một cơ chế đăng ký Componentstrong GameSubsystems(khi GameObjectđược tạo ra và sáng tác). Có 4 cách tiếp cận :

• 1: Chuỗi mô hình trách nhiệm . Mỗi Componentđược cung cấp cho mọi GameSubsystem. GameSubsystemđưa ra quyết định Componentsđăng ký (và cách tổ chức chúng). Ví dụ: GameSubystemRender có thể đăng ký Thành phần kết xuất.

chuyên nghiệp Componentskhông biết gì về cách chúng được sử dụng. Khớp nối thấp. A. Chúng ta có thể thêm mới GameSubsystem. Ví dụ: hãy thêm GameSubystemTitle đăng ký tất cả Thành phần và đảm bảo rằng mọi tiêu đề là duy nhất và cung cấp giao diện để truy vấn các đối tượng theo tiêu đề. Tất nhiên, ElementTitle không nên được viết lại hoặc kế thừa trong trường hợp này. B. Chúng ta có thể tổ chức lại hiện có GameSubsystems. Ví dụ: GameSubystemAudio, GameSubystemRender, GameSubystemParticleEmmiter có thể được hợp nhất vào GameSubystemSpatial (để đặt tất cả âm thanh, trình giả lập, hiển thị Componentstrong cùng phân cấp và sử dụng các biến đổi tương đối cha mẹ).

con. Kiểm tra mọi thứ. Rất không hiệu quả.

con. Subsystemsbiết về Components.

• 2: Mỗi Subsystemtìm kiếm cho Componentscác loại cụ thể.

chuyên nghiệp Hiệu suất tốt hơn trong Approach 1.

con. Subsystemsvẫn biết về Components.

• 3: Componentđăng ký chính nó trong GameSubsystem(s). Chúng tôi biết tại thời điểm biên dịch rằng có GameSubystemRenderer, vì vậy, hãy để ElementImageRender sẽ gọi một cái gì đó giống như GameSubystemRenderer :: register (ElementRenderBase *).

chuyên nghiệp Hiệu suất. Không kiểm tra không cần thiết như trong Approach 1.

con. Componentsđược kết hợp xấu với GameSubsystems.

• 4: Mẫu người hòa giải . GameState(có chứa GameSubsystems) có thể thực hiện registerComponent (Thành phần *).

chuyên nghiệp Componentsvà GameSubystemskhông biết gì về nhau.

con. Trong C ++, nó trông giống như kiểu chuyển đổi xấu xí và chậm chạp.

Câu hỏi: Cách tiếp cận nào tốt hơn và chủ yếu được sử dụng trong thiết kế dựa trên thành phần? Thực hành nói gì? Bất kỳ đề xuất về việc thực hiện Approach 4?

Cảm ơn bạn.

Cửa số 3 ... Thành phần tự đăng ký trong (các) GameSubystem

Thành phần này được sử dụng để giữ cho khớp nối được trừu tượng hóa từ chính GameObject. Bằng cách nào đó, một nơi nào đó trong thực tế cần phải tương tác với các hệ thống con và đây là thành phần và mục đích của nó.

Khớp nối không thực sự là một điều xấu trong trường hợp này.

Hiệu suất về cơ bản là bắt buộc trong trường hợp này nếu bạn muốn có bất kỳ sự phức tạp nào trong hệ thống của mình, bạn không thể đủ khả năng tiếp cận kiểu tìm kiếm của các tùy chọn khác.

Cuối cùng, nếu một hệ thống con cần phản ứng với một hệ thống khác (trình kết xuất, vật lý, âm thanh, tất cả đều cần thực hiện khi có sự cố), các thành phần có thể tạo điều kiện thuận lợi cho nhau thông qua đối tượng trò chơi và giữ cho loại khớp nối chéo đặc biệt này có thể quản lý được thông qua các thành phần.