Những lý do đằng sau thiết kế công cụ Unity3D (thành phần biến đổi / đối tượng trò chơi)

Tôi đang cố gắng hiểu lý do đằng sau thiết kế công cụ Unity3D và đây là điều tôi chưa thể hiểu được: tại sao dữ liệu biến đổi được lưu trữ trong một thành phần riêng biệt, thay vì là một phần của GameObject, như tên, mặt nạ lớp và thẻ? Nó không thể được gỡ bỏ như tất cả các thành phần khác dù sao, không có lựa chọn thay thế và do đó không cần phải loại bỏ nó.

architecture unity component-based

— con rắn5
nguồn

Đối với tôi điều này nghe có vẻ như di sản kiến trúc. Có thể thành phần biến đổi này từng là một thành phần thông thường, tùy chọn, để bạn có thể có các đối tượng "ra khỏi" không gian Cartesian. Sau đó, một số ràng buộc triển khai (tối ưu hóa?) Yêu cầu thành phần này luôn có mặt và nó vẫn giữ nguyên như vậy. Nhưng đó chỉ là giả định, sẽ cần một kỹ sư từ Unity trả lời câu hỏi đó thật sự.

— Laurent Couvidou

Câu trả lời:

Chỉ các nhà phát triển Unity mới có thể tạo động lực thực sự cho thiết kế này, nhưng một lập luận hỗ trợ cho việc thực hiện theo cách này là có một lập luận rằng mỗi lớp trong một dự án phần mềm nên xử lý một và chỉ một trách nhiệm . GameObject là một bộ sưu tập các Thành phần có tên và thêm vị trí / xoay / vv vào đó có nghĩa là nó sẽ có 2 trách nhiệm. Thành phần Transform xử lý vị trí và xoay và do đó cũng không nên chịu trách nhiệm đặt tên hoặc tổng hợp các thành phần khác (có khả năng không liên quan). Vì vậy, thật hợp lý khi 2 khái niệm này tồn tại trong 2 đối tượng riêng biệt.

Tổng quát hơn, câu hỏi này hỏi "nếu có mối quan hệ 1-1 giữa X và Y, tại sao Y không phải là một phần của X hoặc ngược lại?" Và câu trả lời chung là phần mềm dễ phát triển và bảo trì hơn khi được chia thành các phần nhỏ hơn, ngay cả khi 2 phần luôn hoạt động cùng nhau.

— Kylotan
nguồn

Tôi cũng đã xem xét điều đó nhưng họ đã có thể chuyển bộ lọc GameObject (các lớp, thẻ) sang một thành phần riêng biệt vì cùng một lý do - nhưng họ đã không làm vậy. Hơn nữa, thành phần biến đổi được gắn quá sâu trong hệ thống bằng cách giữ dữ liệu phân cấp (cha mẹ, con cái, v.v.).

— rắn5

Có thể lập luận rằng các lớp và thẻ là một hình thức đặt tên, nên nằm cùng với tên và do đó, là một phần nội tại của những gì tạo thành một bộ sưu tập các thành phần trong hệ thống. Đối với các biến đổi giữ cha mẹ, bạn có một điểm, nhưng không ai tuyên bố hệ thống Unity là hoàn hảo. Nếu đó là hệ thống của tôi, tôi sẽ tách riêng Transforms và chuyển cha mẹ / con cái vào GameObject.

— Kylotan

Transform là một thành phần bắt buộc trong Unity.

Lý do tại sao một biến đổi là một thành phần bắt buộc là các đối tượng trò chơi được đặt trong một cảnh và do đó cần thông tin không gian (vị trí, hướng và tỷ lệ) về đối tượng đó. (Thông tin này không phải lúc nào cũng được sử dụng, nhưng việc giữ thành phần biến đổi bắt buộc giúp mọi thứ đơn giản hơn một chút).

— Mortennobel
nguồn

Câu hỏi không phải là về thiết kế dựa trên thành phần nào. Đó là lý do tại sao "biến đổi" cũng không phải là một thành phần

— bummzack

Nhưng Transform là một thành phần trong Unity! docs.unity3d.com/Documentation/ScriptReference/Transform.html . Điều kỳ lạ duy nhất về chuyển đổi là nó là Thành phần bắt buộc cho GameObject.

— Mortennobel

Tôi đoán sau đó câu hỏi là tại sao bạn không thể loại bỏ nó? OP sẽ không gắn thẻ câu hỏi của anh ấy "dựa trên thành phần" nếu anh ấy không quen với thuật ngữ này.

— bummzack

Bạn nói đúng - cảm ơn. Tôi đã cập nhật câu trả lời để trả lời tốt hơn câu hỏi.

— Mortennobel

Câu hỏi là về lý do tại sao dữ liệu biến đổi là một thành phần riêng biệt (trái ngược với dữ liệu đơn giản bên trong GameObject như tên, mặt nạ lớp, thẻ). Tôi đã cố gắng làm cho nó rõ ràng hơn trong phiên bản mới nhất của bài viết của tôi.

— rắn5

Đây TransformComponentlà khó khăn nhất Componentđể thiết kế đúng trong kiến trúc trò chơi video. Hầu như mọi Componentnhu cầu khác cần biết về GameObjectvị trí, vòng quay hoặc tỷ lệ nhất định, do đó, việc tách riêng tất cả các hệ thống có liên quan này vốn đã khó khăn.

Sẽ luôn có sự đánh đổi trong kiến trúc. Bằng cách có TransformComponenttĩnh (tức là không động), các nhà phát triển tại Unity có thể viết mã theo giả định này. Tôi sẽ cho rằng điều này làm cho mọi thứ dễ dàng hơn nhiều về phía họ mà không thêm nhiều bất tiện về phía chúng tôi. Đây là giống như một mô hình hướng đối tượng, nơi GameObjectsẽ extendmột số abstract class,Transformable .

— Alex
nguồn