Hệ thống thành phần thực thể của Unity hoạt động như thế nào trong thực tế? [đóng cửa]


7

Nhìn bề ngoài, Entity-Element có vẻ như là một cách tốt để lập trình trò chơi. Tất cả mọi thứ là một đối tượng trò chơi và những đối tượng trò chơi được tạo thành từ các thành phần. Điểm hấp dẫn là các thành phần rất linh hoạt, chỉ cần bạn "thêm" chúng vào đối tượng trò chơi để kế thừa chức năng của nó.

Vì vậy, rõ ràng một ví dụ tốt có thể là một nền tảng mà nhân vật phải nhảy vào. Có lẽ thứ này có một máy va chạm, một thành phần chuyển động, có thể là một thành phần xoay hoặc thậm chí có thể là một "Xoay vòng cứng". Được rồi, nghe có vẻ hay, chỉ cần thêm tất cả các thành phần này vào đối tượng trò chơi và thế là xong, bạn có chức năng bổ sung này. Tuy nhiên, tôi thấy rằng mức độ phức tạp này là nơi mà tính hữu dụng của nó kết thúc.

Hãy thử điều này với các menu, chuyển động nhân vật phức tạp với nhiều trạng thái, ý tưởng trừu tượng như chế độ trò chơi hoặc trạng thái trò chơi, và tính linh hoạt và mô đun của bạn bị phá hủy. Menu liên quan đến rất nhiều chi tiết cụ thể, chuyển động nhân vật phức tạp thường liên quan đến nhiều trạng thái có nghĩa là cần phải giao tiếp giữa các thành phần này hoặc phải có một thành phần điều khiển được tạo ra chỉ dành cho loại nhân vật này. Trên hết, một số thành phần sẽ cần phải dựa vào trạng thái trò chơi theo một cách nào đó.

Tôi thấy rất ít lợi ích để lập trình theo cách này so với thừa kế thông thường. Việc thiếu cấu trúc đối tượng tại thời gian biên dịch khiến cho việc thực hiện rất nhiều thứ trở nên rất khó khăn và không đáng tin cậy.

Tôi cảm thấy cách tốt nhất và dễ dàng nhất về mọi thứ sẽ là sử dụng các thành phần lớn hơn với nhiều phụ thuộc hơn. Tôi không thấy đây là một vấn đề (giống như kiến ​​trúc 4 không thực), nhưng sau đó tôi tự hỏi điểm nào trong kiến ​​trúc Thực thể-Thành phần.


1
Tiêu đề dường như đang hỏi "nó hoạt động như thế nào", nhưng cơ thể đọc giống như một câu thần chú, hoặc hỏi tại sao nó nên được sử dụng.
Anko

2
Làm thế nào điều này được đóng lại là "Ý kiến ​​dựa trên?" Chỉ có một cách Unity hoạt động, anh chàng đang yêu cầu câu trả lời đó. Chỉ có một câu trả lời, và nó chắc chắn không phải là một ý kiến.
Bối rối

Câu trả lời:


8

Tôi sẽ mạo hiểm và gửi câu trả lời gần như dựa trên ý kiến. Những gì Unity đang thiếu là yếu tố "hệ thống". Sẽ tốt hơn nhiều nếu có "Thành phần-Thực thể-Hệ thống" thay vì "Thực thể thành phần" hiện tại. Đó là vì những vấn đề bạn đề cập.

Vấn đề giao tiếp bạn đã đề cập có thể bằng cách thêm Hệ thống. Thành phần Unity, chứa cả hai, dữ liệu và logic, do đó, hoặc bạn xây dựng Thành phần lớn có rất nhiều thứ và biết rất nhiều. Loại nguyên khối này, có thể được bỏ trong một trò chơi khác, nhưng bạn có thể sử dụng lại một phần của nó. Bạn cũng có thể thử và phá vỡ nó, bằng cách xây dựng nhiều thành phần nhỏ, nhưng bạn sẽ kết thúc với hàng tấn các thành phần nhỏ trao đổi các sự kiện, tin nhắn và công cụ. Bạn có thể "tái sử dụng" chúng, nhưng chúng sẽ không hoạt động một mình.

Đây là nơi Hệ thống xuất hiện. Hệ thống chỉ là một logic. Nó sẽ nói với người quản lý trò chơi của bạn "Tôi có thể làm cho cây của bạn bay, nhưng tôi cần cây để có [cánh, vật lý]". Người quản lý trò chơi sau đó sẽ tìm kiếm các thực thể có cánh và vật lý và đưa nó vào hệ thống. Hệ thống sau đó sẽ làm bất cứ điều gì nó phải làm để làm cho cây của bạn bay. Cánh và vật lý là các thành phần. Nhưng khác với những người Unity, họ sẽ chỉ giữ dữ liệu, như cánh rộng bao nhiêu, hoặc vật sẽ rơi nhanh như thế nào (đó là một cây bay, nó sẽ rơi nhanh!). Bây giờ, tất cả các thành phần của bạn có thể được sử dụng lại, vì chúng không biết về bất cứ điều gì khác ngoài một số dữ liệu kỳ lạ mà chúng nắm giữ. Chúng không có ý nghĩa, trừ khi một số Hệ thống quan tâm. Nhưng đó là công việc hệ thống để đọc và sử dụng dữ liệu. Hệ thống không cần biết ai có thành phần nào và không cần biết về hệ thống khác.

Bây giờ làm thế nào để dịch nó sang Unity? Bạn có thể viết trình quản lý tùy chỉnh của mình, trong đó các thành phần là các hệ thống và tất cả những gì chúng làm là logic (và trạng thái hệ thống nếu được yêu cầu, như trong hệ thống Menu bạn có thể muốn biết tốc ký nào được nhấp gần đây nhất). GameObject của bạn là Thực thể của bạn. Mô hình thì sao? Chà, bạn đang sử dụng c # hoặc JavaScript, chỉ cần sử dụng Class / Object bình thường cho việc này, đó là lý do tại sao bạn sẽ cần trình quản lý tùy chỉnh. Để xử lý các mô hình không thống nhất.

Tùy chọn thứ hai là chia Thành phần thành Mô hình và Hệ thống. Thành phần có thể truy vấn GameObject và toàn bộ Cảnh cho các GameObject khác với các thành phần nhất định. Chỉ định một GameObject làm Trình quản lý hệ thống của bạn. GO này sẽ chỉ giữ các thành phần có thể làm công cụ. Các thực thể khác trong cảnh, sẽ có các thành phần với dữ liệu thuần túy.

Xin lưu ý, đây chỉ là lý thuyết (thêm Hệ thống vào Unity) và nó có thể không dẫn đến kiến ​​trúc hiệu quả cho trò chơi của bạn.

Về thừa kế. Cách dễ nhất để thấy sự khác biệt là sử dụng cả hai mẫu để mô tả đối tượng. Hãy mô tả "Xe hơi" trong hệ thống phân cấp lớp tiêu chuẩn. Xe sẽ Kế thừa từ bánh xe để nó có thể di chuyển xung quanh, do đó, xe là bánh xe. Bây giờ trong Thực thể thành phần. Đối tượng này có bánh xe và cửa ra vào, vì vậy nó là một chiếc xe hơi!

Rất ít liên kết đến các bài báo, về Thành phần-Thực thể. Cái đầu tiên mô tả Unity như Thành phần-Thực thể, cái thứ hai thêm Hệ thống.

http://gameprogrammingpotypes.com/component.html

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

http://python-utilities.readthedocs.org/en/latest/ebs.html


Tôi không thích ý tưởng "xe hơi là một bánh xe" về sự không phù hợp nhưng ý tưởng tổng thể thì khá hay, thường thì tôi tự bọc logic của mình bên trong các bộ phận.
MVCDS

5

Điều này không trực tiếp trả lời câu hỏi, nhưng, từ âm thanh của câu hỏi của bạn và thông tin bạn muốn có vẻ khác nhau một chút (ít nhất là với tôi). Vì vậy, "triển vọng" này có thể giúp kết nối chúng.

Trừu tượng thường dẫn đến khái quát hóa để bạn có thể chuẩn bị cho những điều chưa biết trong tương lai. Đây là những gì Unity làm vì nó hầu như không biết gì về loại trò chơi bạn sẽ thực hiện cho đến khi bạn bắt đầu cung cấp thông tin đó cho nó (ví dụ như mã trò chơi). Sự trừu tượng của bạn càng phức tạp (rất có thể) thì chúng càng khái quát.

Tổng quát hóa là một điều tuyệt vời, nó cho phép bạn sử dụng lại mã giữa các trò chơi (với ít hoặc không thay đổi) và điều chỉnh khi chi tiết thiết kế thay đổi. Tuy nhiên, với sự khái quát hóa đã nói từ lâu rằng quá nhiều thứ là một điều xấu . Quá khái quát hóa có thể dẫn đến việc thực hiện khó khăn và tẻ nhạt để làm một cái gì đó đơn giản.

Một ví dụ:

Giả sử bạn là một công ty phát triển trò chơi. Bạn thích các trò chơi TBS và chỉ có kế hoạch làm các trò chơi TBS. Sẽ có ý nghĩa khi thiết kế và lập trình hệ thống quản lý trạng thái trò chơi của bạn để khái quát hóa tiềm năng của các trò chơi RTS trong tương lai, khi bạn biết bạn sẽ chỉ tạo ra các trò chơi TBS? Không, không phải bạn có thể đi qua cây cầu đó nếu nó đến.

Bây giờ đừng nhầm lẫn việc khái quát hóa quá mức là xấu với "không khái quát hóa" bởi vì chúng tôi có được một chút linh hoạt khi làm như vậy. Bạn có thể biết chính xác trò chơi này mà bạn đang cần 100% (rất có thể bạn không và họ sẽ thay đổi), nhưng vì lý do cho phép bạn giả vờ làm. Chà, bạn có biết trò chơi TBS tiếp theo bạn cần làm gì không? Không, rất có thể nó sẽ khác về mặt cơ học theo một cách nào đó (để mọi người không chán nó trước khi bạn thực hiện nó). Vì vậy, bạn vẫn cần một số khái quát và trừu tượng chỉ không đến mức mà sự thống nhất làm vì bạn biết nhiều hơn.

TLDR;

Quá nhiều và quá ít khái quát hóa có thể là một điều xấu (đối với người mới bắt đầu và nhà phát triển trò chơi đơn, tốt hơn là nên khái quát hóa thấp hơn nhiều). Bạn càng biết nhiều bạn càng cần phải khái quát hóa.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.