Cách triển khai hệ thống dựa trên thành phần cho các vật phẩm trong trò chơi web

Đọc một số câu hỏi và câu trả lời khác về việc sử dụng một hệ thống dựa trên thành phần để xác định các mục tôi muốn sử dụng một mục cho các mục và phép thuật trong trò chơi web được viết bằng PHP. Tôi chỉ bị mắc kẹt trong việc thực hiện.

Tôi sẽ sử dụng lược đồ DB được đề xuất trong loạt bài này (phần 5 mô tả lược đồ);
http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/

Điều này có nghĩa là tôi sẽ có một bảng mục với các thuộc tính mục chung, một bảng liệt kê tất cả các thành phần cho một mục và cuối cùng ghi lại trong mỗi bảng thành phần được sử dụng để tạo thành mục.

Giả sử tôi có thể chọn hai truy vấn đầu tiên cùng nhau trong một truy vấn, tôi vẫn sẽ thực hiện N truy vấn cho từng loại thành phần. Tôi khá ổn với điều này vì tôi có thể lưu trữ dữ liệu vào memcache và kiểm tra trước khi thực hiện bất kỳ truy vấn nào. Tôi sẽ cần phải xây dựng các mục theo mọi yêu cầu mà chúng được sử dụng để việc triển khai cần được thực hiện ngay cả khi chúng được lấy từ memcache.

Nhưng ngay tại đó, tôi cảm thấy tự tin về việc triển khai một hệ thống thành phần cho các mục của mình kết thúc. Tôi nghĩ rằng tôi cần phải mang các thuộc tính và hành vi vào trong thùng chứa từ mỗi thành phần mà nó sử dụng. Tôi chỉ không chắc làm thế nào để làm điều đó một cách hiệu quả và cuối cùng không viết nhiều mã chuyên dụng để xử lý từng thành phần.

Ví dụ, AttackComponent có thể cần biết cách lọc các mục tiêu bên trong bối cảnh chiến đấu và cũng có thể cung cấp hành vi tấn công. Cùng một vật phẩm đó cũng có thể có UsableComponent, cho phép vật phẩm được sử dụng và áp dụng một số hiệu ứng lên một nhóm mục tiêu khác được lọc khác với cùng bối cảnh chiến đấu. Sau đó, không phải mọi phần của vật phẩm là một phần hoạt động, AttributionBonusComponent có thể chỉ cần khởi động khi vật phẩm ở trạng thái được trang bị hoặc khi hiển thị trang chi tiết vật phẩm.

Cuối cùng, làm thế nào tôi nên mang tất cả các thành phần lại với nhau trong thùng chứa để khi tôi sử dụng một vật phẩm làm vũ khí tôi có được danh sách chính xác các mục tiêu? Biết khi nào một vũ khí cũng có thể được sử dụng như một vật phẩm? Hoặc để áp dụng các phần thưởng mà vật phẩm cung cấp cho một đối tượng nhân vật?

Tôi cảm thấy như mình đã đi quá xa xuống hố thỏ và tôi không thể nắm bắt được giải pháp đơn giản trước mặt. (Nếu nó không hoàn toàn có nghĩa.)

Tương tự như vậy nếu tôi thực hiện câu trả lời tốt nhất từ ​​đây, tôi cảm thấy như mình có rất nhiều câu hỏi tương tự.
Cách mô hình hóa nhiều "cách sử dụng" (ví dụ vũ khí) cho hàng tồn kho / vật thể / vật phẩm có thể sử dụng (ví dụ katana) trong cơ sở dữ liệu quan hệ

Có vẻ như bạn đang sử dụng mô hình quan hệ. Có một phương pháp khác: mô hình hóa tài sản / nguyên mẫu, mà Steve Yegge đã sử dụng để tạo ra MMORPG "mở rộng cuối cùng" của mình, Wyvern . Về cơ bản, mỗi đối tượng trò chơi được lưu trữ dưới dạng một đốm màu (chỉ một truy vấn cho mỗi đối tượng) sau đó được phân tích cú pháp vào danh sách thuộc tính sau khi truy xuất. Tính linh hoạt của danh sách tài sản cho phép các đối tượng trò chơi khác nhau có các bộ thuộc tính khác nhau khi cần.

Mẫu thiết kế phổ quát của Yegge đi sâu vào mô hình tài sản / nguyên mẫu. Các bài đăng trên blog của Steve có xu hướng khá dài, vì vậy tôi sẽ cố gắng chỉ cho bạn các phần có liên quan và tóm tắt các điểm liên quan đến câu hỏi của bạn:

1. Wyvern sử dụng một triển khai của Thuộc tính mẫu. Một đối tượng trò chơi về cơ bản là một túi thuộc tính tùy ý. Bất kỳ đối tượng nào có thể đóng vai trò là nguyên mẫu cho bất kỳ đối tượng nào khác, dẫn đến tính linh hoạt kết thúc mở tuyệt vời.
2. Danh sách tài sản dai dẳng. Có nhiều phương pháp khác nhau để tuần tự hóa và lưu danh sách tài sản. Wyvern sử dụng một cơ sở dữ liệu, "đưa danh sách thuộc tính được tuần tự hóa XML vào một cột văn bản / clob và không chuẩn hóa hai mươi hoặc ba mươi trường ... cần thiết cho các truy vấn vào các cột riêng của chúng."
3. Kho dữ liệu của danh sách tài sản hiện cần một phương thức thực hiện truy vấn trên chúng. Steve đưa ra một số gợi ý. Các truy vấn dựa trên văn bản đơn giản không hoạt động tốt cho dữ liệu phân cấp. Cơ sở dữ liệu XML hoặc JavaScript / JSON + jQuery có thể là câu trả lời cho vấn đề này.

Tôi sẽ triển khai một hệ thống hook (một cơ chế mà các hàm gọi lại cho các chức năng có thể xác định có thể được thêm vào và xóa khỏi một đối tượng khi có sự kiện) trên container và có các thành phần thiết lập các hook thích hợp khi thêm và xé chúng khi gỡ bỏ. Chẳng hạn, AttributionBonusComponent có thể sử dụng atEquipvà atUnequiphook để thêm và xóa phần thưởng của nó, AttackComponent có thể cung cấp các giá trị cho pollForTargetsvà pollForAttackBehaviorshook và UsableComponent có thể nói chuyện pollForUseBehaviors.

Vì vậy, container chỉ có một sự hiểu biết trừu tượng về các loại thông tin có thể được yêu cầu và cách thức có thể tương tác với nó, và các thành phần chịu trách nhiệm xác định cách chúng giao tiếp với chúng.

Có vẻ như bạn đang thiếu điểm của loại hệ thống thực thể này. Nếu bạn "tải tất cả các thành phần mọi lúc" thì bạn sẽ gần như không nhận được lợi ích gì từ nó.

Bạn nên thiết lập nó để tất cả dữ liệu cần thiết cho một lớp hoạt động cụ thể (ví dụ: "giải quyết các cuộc tấn công") được gói thành một thành phần duy nhất.

Về cơ bản, hãy tưởng tượng rằng bạn phải viết mã chính cho một phần của trò chơi, hoàn thành với các trường hợp đặc biệt chính và bạn muốn chỉ định dữ liệu nào cần từ đầu mã đến cuối. Đó là một thành phần (bạn có thể chia nó thành các thành phần nhỏ hơn, nhưng chỉ khi bạn cần bởi vì một số phần được sử dụng sau bởi mã khác).

Sau đó, khi bạn gặp trường hợp đặc biệt, bạn có lựa chọn chỉnh sửa thành phần chính của mình (thường là: không) hoặc phát minh ra các thành phần bổ sung cho phép tất cả các thực thể hiện có tiếp tục hoạt động và tất cả các mã hiện có để tiếp tục hoạt động, không thay đổi.

Hãy nhớ các quy tắc để tối ưu hóa !

1. Đừng.
2. Đừng (chỉ dành cho chuyên gia).

Ví dụ, AttackComponent có thể cần biết cách lọc các mục tiêu bên trong bối cảnh chiến đấu và cũng có thể cung cấp hành vi tấn công. Cùng một vật phẩm đó cũng có thể có UsableComponent, cho phép vật phẩm được sử dụng và áp dụng một số hiệu ứng lên một nhóm mục tiêu khác được lọc khác với cùng bối cảnh chiến đấu. Sau đó, không phải mọi phần của vật phẩm là một phần hoạt động, AttributionBonusComponent có thể chỉ cần khởi động khi vật phẩm ở trạng thái được trang bị hoặc khi hiển thị trang chi tiết vật phẩm.

Có thực sự là một vấn đề nếu bạn tải tất cả các thành phần (AttackComponent, UsableComponent, AttributionBonusComponent) ngay cả khi tất cả trừ một người không sử dụng?

"Tôi cảm thấy như mình đã đi quá xa xuống hố thỏ"

Đúng chính xác. Các hệ thống dựa trên thành phần vẫn đang trong giai đoạn 'mốt', nơi không có thỏa thuận về cách sử dụng chúng tốt nhất. Một số người có kiến ​​thức và có thẩm quyền đã đăng các bài viết gợi ý sử dụng của họ, nhưng mỗi người có xu hướng không đồng ý về cách bạn lắp ráp chúng, cách họ giao tiếp, v.v.

Ý kiến ​​cá nhân của tôi là mô hình quan hệ mà bạn liên kết đến quá trừu tượng để sử dụng hàng ngày.

Thay vào đó, tôi sẽ xem xét kỹ hơn về thiết kế của riêng bạn và xem những khía cạnh phổ biến nào của chức năng có thể được đưa ra để hình thành các thành phần có thể hoán đổi cho nhau. Điều đó có lẽ sẽ hiệu quả hơn nhiều so với việc cố gắng đưa trò chơi của bạn vào một khái niệm định sẵn về những thành phần nên có.

Theo tôi hiểu loạt bài viết được tham chiếu trên Hệ thống thực thể, "mục" của bạn được tải với các thành phần. Và một Thành phần là một danh sách các tài liệu tham khảo. Theo dõi qua ví dụ của bạn: AttackComponent sẽ bao gồm các tham chiếu về cách thức "vật phẩm" tấn công; AttackTargetComponent sẽ bao gồm các tham chiếu đến các cơ chế để có danh sách các mục tiêu; và như thế. Do đó, khi "vật phẩm" của bạn tấn công mục tiêu hoặc mục tiêu - đó là sử dụng AttackComponent và AttackTargetComponent hoặc kích hoạt một phương thức bên ngoài dựa trên vật phẩm (và các thành phần của nó) Cảm ơn vì đã chia sẻ các bài viết này.