Có các khung dựa trên thành phần FOSS hiện có không? [đóng cửa]


25

Mô hình lập trình trò chơi dựa trên thành phần đang trở nên phổ biến hơn nhiều. Tôi đã tự hỏi, có bất kỳ dự án ngoài đó cung cấp một khung thành phần có thể tái sử dụng? Trong bất kỳ ngôn ngữ nào, tôi đoán tôi không quan tâm đến điều đó. Nó không dành cho dự án của riêng tôi, tôi chỉ tò mò.

Cụ thể, ý tôi là có những dự án bao gồm một Entitylớp cơ sở , một Componentlớp cơ sở và có thể một số thành phần tiêu chuẩn? Sau đó, việc bắt đầu một trò chơi sẽ dễ dàng hơn nhiều nếu bạn không muốn phát minh lại bánh xe, hoặc có thể bạn muốn một trò chơi có thể tạo ra GraphicsComponentbằng Direct3D, nhưng bạn cho rằng nó đã được thực hiện hàng chục lần.

Một Googling nhanh chóng bật lên Rizer . Có ai nghe nói về điều này / có ai sử dụng nó? Nếu không có những cái phổ biến, thì tại sao không? Có quá khó để làm một cái gì đó như thế này có thể tái sử dụng, và họ cần tùy chỉnh nặng? Trong quá trình thực hiện của riêng tôi, tôi đã tìm thấy rất nhiều nồi hơi có thể được đưa vào một khung.


4
Bạn nên là người đầu tiên viết một! :)
Ricket

1
Vâng, tôi đã viết một trong C # cho dự án của riêng tôi. Có lẽ tất cả chúng ta có thể đóng góp?
Tesserex

Tôi hoàn toàn sẵn sàng làm việc với dự án C # đó. Vâng, không có sự đồng thuận lớn về cách một tiêu chuẩn nên hoạt động, nhưng có lẽ chúng ta có thể tập trung vào XNA (bất cứ điều gì làm nổi thuyền của bạn). Chỉ vì một nhóm người khổng lồ chưa tuyên bố cách tốt nhất để làm điều đó không có nghĩa là chúng tôi không thể thử / thử nghiệm.
Michael Coleman

Có lẽ bởi vì thiết kế dựa trên thành phần thu hút các nhà quản lý dự án hơn các lập trình viên
M. Utku ALTINKAYA

Câu trả lời:


45

Nếu không có những cái phổ biến, thì tại sao không?

Bởi vì không có gì giống với sự đồng thuận về cách một khung như vậy sẽ hoạt động.

Trên một chủ đề trên Gamedev.net tôi đã xác định rằng khi mọi người nói về các hệ thống trò chơi dựa trên thành phần, thực tế có ít nhất 8 hoán vị có thể về cách họ mong đợi chúng hoạt động, dựa trên 3 yếu tố khác nhau:

Trong và ngoài - các thành phần nên được tổng hợp thành một thực thể, hay chúng nên là một phần của hệ thống con và chỉ được liên kết bởi một ID thực thể?

Thành phần tĩnh so với động - nên các thực thể bao gồm một tập hợp các thành phần đã biết (ví dụ: 1 Vật lý, 1 Hoạt hình, 1 AI, v.v.) có thể giao tiếp bằng mã thông qua các giao diện nổi tiếng hoặc các thực thể có thể có số lượng thành phần tùy ý được thêm vào chúng (với các chiến lược liên quan để định vị các thành phần quan tâm khác)

Dữ liệu trên thành phần so với dữ liệu trên thực thể - Dữ liệu có nên được giữ bởi thành phần chủ yếu hoạt động theo nó không? Hoặc dữ liệu nên được lưu trữ trên thực thể trong một không gian chung, có thể truy cập bởi tất cả các thành phần?

Ngoài ra còn có nhiều câu hỏi khác về cách các thành phần nên giao tiếp (thông qua dữ liệu được chia sẻ? Thông qua con trỏ chức năng? Qua tín hiệu / khe cắm? Hoặc không phải tất cả?), Làm thế nào để cập nhật (theo thứ tự cố định dựa trên loại thành phần? thứ tự ưu tiên được xác định tại thời điểm tạo? dựa trên một loại cấu trúc liên kết cấu thành liên kết cấu trúc?), v.v.

Mỗi lựa chọn này là hoàn toàn tùy ý và bất cứ điều gì bạn có thể làm với một hệ thống đều có thể được thực hiện với hệ thống kia. Nhưng cách mà bạn phải mã hóa nó khá khác nhau trong từng trường hợp. Và mọi người dường như có ý kiến ​​mạnh mẽ về cách làm việc tốt nhất cho họ.

Ngay bây giờ mọi người vẫn còn bị cuốn vào ý tưởng rằng các thành phần bằng cách nào đó thay thế cho hướng đối tượng (mà chúng không phải) và cũng tưởng tượng rằng chúng là một sự thay đổi lớn từ cách các trò chơi được tạo ra theo cách truyền thống (một lần nữa, chúng không phải là - mọi người đã tìm ra các hệ thống con khác nhau trong các thực thể của họ từ lâu), vì vậy có rất nhiều sự cường điệu và không có nhiều thỏa thuận. Có thể trong một vài năm mọi thứ sẽ ổn định và mọi người sẽ giải quyết theo một hoặc hai cách tiếp cận khá chuẩn.


1
Tôi đánh giá cao câu trả lời này đã cũ, nhưng giờ đã sai: có các khung phổ biến và có rất ít tranh luận về chủ đề này. Khi viết trò chơi, hầu hết các câu hỏi trên không thành vấn đề: chúng không có tác dụng gì trong việc thiết kế mã, hoặc một cách tiếp cận nhanh và có thể sử dụng lại ở những nơi khác. Trong thực tế, có một loạt các Khung phổ biến - wiki được liên kết với một trong những câu trả lời khác là điểm khởi đầu tốt (một nhóm chúng tôi duy trì nó để giúp tìm các trò chơi + khung thực tế dễ dàng hơn)
Adam

1
@Adam: Tôi muốn một liên kết về các chi tiết về cách tiếp cận chiến thắng trận đấu tiến hóa darwin sau đó. Khi tôi nói chi tiết, tôi không muốn nghe về inboard và outboard, tôi muốn nghe về bản đồ băm, vectơ, cấp phát, riêng tư, công cộng, vòng lặp, const ... chi tiết ở mức THẤP.
v.oddou

@ v.oddou ai đó đã đăng một liên kết đến wiki dưới dạng câu trả lời (xem bên dưới). Bạn muốn biết chi tiết? Nó có đầy đủ mã nguồn .
Adam

10

Có một wiki thu thập các ví dụ về tất cả những điều này:

http://entity-systems.wikidot.com/

... Cùng với những giải thích về sự khác biệt giữa các phương pháp khác nhau.


Ash và Artemis (cả trên wiki) đã thực sự nổi tiếng, cả hai đều được sử dụng để phát triển trò chơi thương mại, cùng với nhà phát triển trò chơi sở thích.
Adam

4

Kiểm tra các khung này tôi thấy có liên quan đến kiến ​​trúc này ...

www.burgerengine.com

PushButtonEngine

Khung Arthemis - https://github.com/artemis-esf/artemis-framework/tree/master/src/com/artemis

Có một cái nhìn về Unity Api. Bạn có thể tìm thấy rất nhiều thứ liên quan đến kiến ​​trúc dựa trên Thành phần. (Sẽ cập nhật danh sách ngay khi tôi tìm thấy ở đâu đó ...)

Cập nhật:

      https://code.google.com/p/spartanframework/

Điều này giải thích về các hệ thống thực thể theo cách tốt ... http://piemaster.net/2011/07/entity-component-primer/


2

Có công cụ nút nhấn cho Flash: http://pushbuttonengine.com/

Và có Panda3D cho c ++ / python: panda3d dot com (xin lỗi tôi chỉ được phép 1 url cho mỗi bài đăng dưới dạng n00b)

Tôi chắc chắn có rất nhiều ngoài kia :)

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.