Giới thiệu
Các hệ thống thành phần Entity vào là một kỹ thuật kiến trúc hướng đối tượng.
Không có sự đồng thuận phổ quát về ý nghĩa của thuật ngữ này, giống như lập trình hướng đối tượng. Tuy nhiên, rõ ràng là hệ thống tổ chức thành phần nhằm mục đích cụ thể như một sự thay thế kiến trúc để thừa kế . Hệ thống phân cấp kế thừa là tự nhiên để thể hiện đối tượng là gì , nhưng trong một số loại phần mềm nhất định (như trò chơi), bạn muốn thể hiện những gì đối tượng làm .
Đó là một mô hình đối tượng khác với các lớp và kế thừa, một mô hình mà bạn rất quen thuộc khi làm việc trong C ++ hoặc Java. Các thực thể có tính biểu cảm như các lớp, giống như các nguyên mẫu như trong JavaScript hoặc Self Nam, tất cả các hệ thống này có thể được triển khai theo các khía cạnh khác.
Ví dụ
Hãy nói rằng Playerlà một thực thể có Position, Velocityvà KeyboardControlledcác thành phần, mà làm những điều hiển nhiên.
entity Player:
Position
Velocity
KeyboardControlled
Chúng tôi biết Positionphải bị ảnh hưởng bởi Velocity, và Velocitybởi KeyboardControlled. Câu hỏi là làm thế nào chúng ta muốn mô hình hóa các hiệu ứng đó.
Các thực thể, thành phần và hệ thống
Giả sử rằng các thành phần không có tham chiếu với nhau; một Physicshệ thống bên ngoài đi qua tất cả các Velocitythành phần và cập nhật Positionthực thể tương ứng; một Inputhệ thống đi qua tất cả các KeyboardControlledthành phần và cập nhật Velocity.
Player
+--------------------+
| Position | \
| | Physics
/ | Velocity | /
Input | |
\ | KeyboardControlled |
+--------------------+
Điều này thỏa mãn các tiêu chí:
Các hệ thống hiện chịu trách nhiệm xử lý các sự kiện và ban hành hành vi được mô tả bởi các thành phần. Họ cũng chịu trách nhiệm xử lý các tương tác giữa các thực thể, chẳng hạn như va chạm.
Các thực thể và thành phần
Tuy nhiên, giả sử rằng các thành phần làm có tài liệu tham khảo với nhau. Bây giờ thực thể chỉ đơn giản là một hàm tạo tạo ra một số thành phần, liên kết chúng lại với nhau và quản lý vòng đời của chúng:
class Player:
construct():
this.p = Position()
this.v = Velocity(this.p)
this.c = KeyboardControlled(this.v)
Bây giờ thực thể có thể gửi các sự kiện đầu vào và cập nhật trực tiếp đến các thành phần của nó. Velocitysẽ trả lời các bản cập nhật và KeyboardControlledsẽ trả lời đầu vào. Điều này vẫn đáp ứng các tiêu chí của chúng tôi:
Ở đây các tương tác thành phần là rõ ràng, không bị áp đặt từ bên ngoài bởi một hệ thống. Dữ liệu mô tả một hành vi (lượng vận tốc là bao nhiêu?) Và mã ban hành nó (vận tốc là gì?) Được ghép nối, nhưng theo kiểu tự nhiên. Dữ liệu có thể được xem như là tham số cho hành vi. Và một số thành phần không hành động ở tất cả các khu vực a Positionlà hành vi ở một nơi .
Các tương tác có thể được xử lý ở cấp độ của thực thể ( PlayerHồi khi va chạm với một Tấn vụ Enemy) hoặc ở cấp độ của các thành phần riêng lẻ (Hồi khi một thực thể có Lifeva chạm với một thực thể với Hồi phạm Strength).
Các thành phần
Lý do cho các thực thể tồn tại là gì? Nếu nó chỉ là một hàm tạo, thì chúng ta có thể thay thế nó bằng một hàm trả về một tập hợp các thành phần. Nếu sau này chúng ta muốn truy vấn các thực thể theo loại của chúng, chúng ta cũng có thể có một Tagthành phần cho phép chúng ta làm điều đó:
function Player():
t = Tag("Player")
p = Position()
v = Velocity(p)
c = KeyboardControlled(v)
return {t, p, v, c}
Các thực thể câm lặng như có thể là họ, họ chỉ là một bộ các thành phần.
Các thành phần phản ứng trực tiếp với các sự kiện như trước đây.
Các tương tác bây giờ phải được xử lý bằng các truy vấn trừu tượng, tách hoàn toàn các sự kiện từ các loại thực thể. Không có nhiều loại thực thể để truy vấn Tagdữ liệu tùy ý có lẽ được sử dụng để gỡ lỗi tốt hơn logic trò chơi.
Phần kết luận
Các thực thể không phải là chức năng, quy tắc, tác nhân hoặc tổ hợp dataflow. Chúng là những danh từ mô hình hiện tượng cụ thể, nói cách khác, chúng là đối tượng. Nó giống như Wikipedia nói rằng các hệ thống thành phần của LinkedIn là một mô hình kiến trúc phần mềm để mô hình hóa các đối tượng chung.