Làm cách nào tôi có thể thiết kế sơ đồ tương tác đối tượng trò chơi hiệu quả với kiến ​​trúc dựa trên thành phần?

Đây là một câu hỏi về thiết kế ... Tôi chắc chắn rằng điều này có thể được khái quát hơn, nhưng tôi đang gặp khó khăn với nó. Tôi đang tự hỏi về thiết kế cho các tương tác đối tượng trò chơi - đây là ví dụ của tôi (nền tảng câu đố 2D).

Nói rằng người chơi đang cố gắng tiến bộ thông qua một cấp độ. Có nhiều đèn có thể được chỉ theo các hướng khác nhau. Dưới đây là một ví dụ về cách các vật thể ánh sáng này có thể tương tác ...

• Một ánh sáng chiếu một nền tảng cho phép người chơi vượt qua một khoảng trống
• Một ánh sáng làm giảm các hệ số ma sát của bất cứ thứ gì nó chạm vào, một ánh sáng khác làm tăng nó
• Một ánh sáng làm mất tác dụng của tất cả các đèn, điều này sẽ làm cho nền tảng biến mất trong khi đèn đó sáng và vô hiệu hóa các bộ điều chỉnh ma sát
• Vân vân...

Cách tốt nhất để tiếp cận vấn đề này khi sử dụng kiến ​​trúc thành phần là gì? Các thành phần cho từng đối tượng chính có vẻ rõ ràng, cũng như một cách rõ ràng để xác định ảnh hưởng của chúng đối với môi trường. Một lớp để "giải quyết" tương tác (có vẻ như điều đó có thể trở thành một mớ hỗn độn một cách nhanh chóng)? Một số cách sử dụng mẫu trang trí để tạo các đối tượng kết hợp cho những đối tượng đang tương tác tại một thời điểm nhất định? Một cấu trúc dữ liệu cho vay chính nó?

Ngoài ra, kết nối âm thanh với các tương tác này? Có vẻ như việc kết nối âm thanh với hệ thống sẽ giống như kết nối bất kỳ tài sản nào khác, như khả năng hiển thị hoặc chuyển động / va chạm của người chơi.

Rõ ràng là khi nhiều thành phần được thêm vào, sẽ rất tuyệt nếu có một hệ thống mạnh mẽ có thể xử lý các thành phần mới với ít sửa đổi, nhưng tôi không quen với cách thiết kế này.

Thông tin khác: Công cụ tôi đang sử dụng là công cụ XNA có tên IceCream .

Trong một hệ thống hướng đối tượng, câu trả lời thực sự duy nhất cho câu hỏi về cách tốt nhất để làm X là bạn chỉ nên làm theo cách đơn giản nhất mà bạn có thể nghĩ ra để lấy thứ gì đó và chạy, sau đó thay đổi nó khi biểu hiện dễ dàng hơn trở nên rõ ràng. Liên quan đến việc bạn chọn đúng mẫu trước khi bạn viết bất kỳ mã nào là một cách tốt để tự làm yên với câu trả lời sai từ việc di chuyển; hãy để mọi suy nghĩ về các mẫu và các thành phần tan chảy và chỉ cần làm theo các bước sau, bắt đầu từ nơi bạn đang ở ngày hôm nay (giả sử bạn đã thực hiện một thành phần nhẹ):

1. Thêm mã vào thành phần ánh sáng cho nền tảng dự án. (Làm việc này.)
2. Sao chép thành phần đó vào một thành phần mới, loại bỏ các công cụ nền tảng và thêm mã để giảm ma sát của các đối tượng thích hợp. (Làm việc này, xác minh rằng # 1 vẫn hoạt động.)
3. Sao chép thành phần đó vào một thành phần mới, loại bỏ mã "mới" và thêm nội dung để vô hiệu hóa các hiệu ứng của các thành phần khác. (Làm việc này, sau đó xác minh rằng # 1 và # 2 vẫn hoạt động.)

Tại thời điểm này, bạn sẽ (có thể) có một tấn mã trùng lặp. Trích xuất mã chung vào các hàm hoặc lớp khác (có thể là lớp cơ sở) hoặc bất cứ thứ gì có vẻ phù hợp. Chỉ vì bạn đã bắt đầu với một "thành phần ánh sáng" mặc dù điều đó không có nghĩa là LightComponent là một cơ sở thích hợp; có thể là bất cứ mã nào tạo thành thành phần ánh sáng không thực sự là "thành phần" và có thể sẽ được biểu diễn tốt nhất bằng một tập hợp các hàm hoặc thậm chí một lớp riêng biệt được tổng hợp thành các thành phần mới của bạn (như một biến thành viên ).

Nói chung, khi một đối tượng loại A tương tác với một đối tượng loại B, bạn muốn có một số hiệu ứng C. Điều này được gọi là "công văn kép" và rất khó thực hiện một cách tao nhã trong các ngôn ngữ giống như C.

Cách hiệu quả nhưng khó bảo trì chỉ là một loạt các chuyển đổi và nếu các câu lệnh, tùy thuộc vào loại đối tượng của bạn. Bạn sẽ cảm thấy viết bẩn nhưng nó sẽ hoàn thành công việc.

Mẫu khách truy cập là một giải pháp mạnh mẽ hơn, che giấu việc chuyển đổi loại khó chịu, nhưng có thể vụng về để thiết lập.

Thông thường, bất kỳ loại chuyển đổi loại nào trong mã của bạn đều có mùi, nhưng ở đây bạn đang cố gắng khái quát hóa đa hình, thường chuyển các chức năng dựa trên một loại duy nhất, để chuyển đổi các chức năng dựa trên hai loại. Đa hình là một nền tảng của OOP vì vậy nó không phải là mùi.

Hãy để tôi xem. Đây chỉ là thứ tôi đã nấu chín trong đầu khi tôi đang viết, rất xin lỗi nếu tôi thiếu thứ gì đó.

Nhận tất cả các nút ánh sáng trong một khoảng cách hợp lý xung quanh anh chàng của bạn.

Đối với mỗi ánh sáng, bạn kết xuất một đa giác thể hiện vùng ảnh hưởng của nó tới một đối tượng bộ đệm khung. Vì vậy, một hình nón ánh sáng sẽ tạo ra một hình nón gồm một loại pixel trong FBO của bạn. Kết xuất từng loại nút trong lượt ưu tiên thích hợp. Bạn có thể mã hóa thông tin vào từng pixel như kênh màu xanh lá cây có thể là ma sát, màu đỏ là trọng lực, màu xanh lam và alpha là thứ gì đó khác.

Kỹ thuật pha trộn màu sắc thông minh sau đó có thể tạo ra các hiệu ứng thú vị. Mỗi cấp độ có thể có quy tắc pha trộn riêng của nó. Bạn cũng có thể thêm bóng mờ cho các hiệu ứng động ảo giác như lực hấp dẫn xung, v.v.

Cuối cùng, chỉ cần kiểm tra các pixel mà mandude của bạn chạm vào và thực hiện tính toán lại bitmap bất cứ khi nào bạn ở gần các cạnh của khu vực được tính toán trước.

Scetch thô sơ được thực hiện trong 2 phút minh họa ý tưởng của tôi:

Chỉnh sửa: Trong thực tế điều này có nghĩa là điều duy nhất bạn cần là một thành phần ánh sáng phát ra một màu nhất định. Các quy tắc kết nối với màu sắc làm những gì có thể ở một nơi khác hoàn toàn. Bạn có thể mã hóa rất nhiều dữ liệu vào 32 bit bạn có pixel pr. Ngoài ra, bạn có thể có nhiều FBO chứa các thuộc tính khác nhau không ảnh hưởng lẫn nhau. Bạn có thể có một FBO trọng lực / ma sát và một FBO va chạm 1 bit. Nếu bạn chọn cái này, tất nhiên bạn sẽ phải gắn cờ FBO mà ánh sáng của bạn sẽ hiển thị.

Mẫu quan sát là một trong những giải pháp tốt nhất. Tin nhắn sẽ chỉ được gửi đến những đối tượng (thành phần) thực sự quan tâm đến nó. Vì vậy, người nhận phải đăng ký loại tin nhắn / sự kiện này.

Có nhiều triển khai tín hiệu / khe cắm. Ví dụ: trong C ++ có thư viện sigslot

Để biết thêm thông tin đọc về tín hiệu Qt và khe cắm .