Làm thế nào để camera / UI biết người chơi là ai?

7

Tôi có một chút khó xử về việc các thành phần động cơ nhất định - như máy ảnh và giao diện người dùng - biết phải theo dõi ai, sức khỏe và các thuộc tính khác để thể hiện trên màn hình.

Làm thế nào để bạn kiến trúc sư một hệ thống, nơi giao tiếp giữa các thành phần đó và các thực thể diễn ra? Tôi có thể có một thực thể riêng đại diện cho người chơi, nhưng điều đó có vẻ hơi 'mã hóa cứng'. Nếu tôi muốn lia máy ảnh thì sao? Nếu người chơi bắt đầu kiểm soát thực thể khác thì sao?

Nói cách khác, làm cách nào để trừu tượng hóa các nguồn dữ liệu cho các thành phần như máy ảnh và giao diện người dùng, sao cho chúng không quan tâm đến thực thể chúng đại diện cho cái gì?

Một hệ thống sự kiện sẽ thực hiện trong nhiều trường hợp, nhưng phù hợp hơn cho việc truyền bá thông tin thay đổi hoặc được tạo ra "hiếm khi" (như cái chết của người chơi). Đối với một cái gì đó như sức khỏe thực thể và vị trí - cần được biết đến mọi khung hình - một hệ thống sự kiện không phù hợp lắm.

architecture camera

— Paul Manta
nguồn

Và máy ảnh có nhận được đầu vào không? Hoặc nhân vật người chơi, hoặc một số bộ điều khiển trừu tượng. Vì vậy, máy ảnh theo dõi người chơi, người di chuyển bởi bộ điều khiển điện ảnh?

— deceleratedcaviar

10

Giải pháp đơn giản nhất là giữ một con trỏ thành viên cho một đối tượng như Camera.Target hoặc UI.Subject chỉ vào nhân vật người chơi nhưng có thể được chuyển hướng đến các đối tượng khác (hoặc được đặt thành NULL) khi cần thiết.

Nếu người chơi thay đổi nhân vật, hãy gửi một sự kiện để thay đổi biến mục tiêu của máy ảnh và chủ đề của UI. Nếu bạn muốn xoay camera, ghi đè hành vi "mục tiêu" và đặt nó thành chuyển động thủ công.

— Alex
nguồn

+1 Điều này tương tự với những gì tôi sử dụng. Tôi đã tạo một ITargetgiao diện chỉ định nghĩa cơ bản các biến X / Y (trò chơi của tôi là 2D). PlayerLớp của tôi thực hiện giao diện này và cập nhật các giá trị với tọa độ X / Y của chúng và sau đó thuộc tính Cameracó Targetkiểu ITarget. Mỗi Update, Camerakiểm tra nếu nó có Targetvà tự cập nhật tương ứng, nếu không nó sẽ làm một cái gì đó khác (trong trường hợp của tôi, nó miễn phí và di chuyển dựa trên các lần nhấn phím, nhưng bạn có thể làm bất cứ điều gì bạn muốn).

— Richard Marskell - Drackir

2

Tôi thấy rằng cách dễ nhất để làm điều này là chỉ đơn giản là không giới hạn bản thân mình chỉ có một máy ảnh duy nhất.

Thay vào đó, thế giới trò chơi của tôi có rất nhiều máy ảnh, hàng chục hoặc hàng trăm trong số chúng. Bất kỳ nhân vật có khả năng điều khiển nào cũng có máy ảnh, bất kỳ đoạn phim cắt cảnh nào cũng có máy ảnh, thường thì một thực thể sẽ có một số máy ảnh khác nhau cho các hoạt động khác nhau của người chơi. (di chuyển chiến đấu, chạy không tải, chạy nước rút, vv). Mỗi camera được đưa ra mục tiêu khi nó được tạo và mục tiêu đó (như một quy tắc chung) không đổi trong suốt vòng đời của máy ảnh.

Vấn đề bây giờ không phải là "làm thế nào để máy ảnh biết được nhân vật nào đang theo dõi" mà là "làm thế nào để trình kết xuất biết máy ảnh nào trong cảnh mà nó thực sự nên sử dụng để kết xuất ngay bây giờ". Tôi sử dụng một lớp trình quản lý camera cho điều đó, biết về tất cả các camera trong cảnh và có thể kết hợp từ cái này sang cái khác, theo chỉ dẫn của các sự kiện mà nó nhận được từ logic trò chơi.

— Trevor Powell
nguồn

Nghe có vẻ hơi quá mức? Bạn có thể không chỉ xác định hành vi dựa trên các loại cơ sở thay thế? (cutscene, head, v.v.)

— deceleratedcaviar

Đừng hiểu lầm tôi; các máy ảnh có hành vi tiêu chuẩn. Tôi không ủng hộ việc triển khai riêng cho mọi trường hợp của máy ảnh trong cảnh! Chỉ có mỗi máy ảnh tiềm năng tồn tại như một thể hiện riêng biệt trong cảnh là khá hữu ích để pha trộn và để đơn giản hóa số loại sự kiện máy ảnh cần được xử lý bởi phần còn lại của cơ sở mã.

— Trevor Powell

0

Người chơi có thể đủ khác biệt với các đối tượng hoặc thực thể khác mà họ sẽ có lớp riêng. Đối với nhiều trò chơi, việc có một đối tượng người chơi toàn cầu có thể có sẵn trên toàn bộ máy và luôn đại diện cho người chơi và bất kỳ hệ thống nào cần biết về người chơi đều có thể nói chuyện với lớp đó. Điều này có thể sạch hơn và đơn giản hơn là đi vòng quanh một con trỏ ở mọi nơi.

Nếu trò chơi của bạn là nhiều người chơi qua mạng, điều này vẫn có thể có ý nghĩa bởi vì có một sự khác biệt lớn giữa người chơi cục bộ và người chơi từ xa. Nếu bạn hỗ trợ nhiều người chơi cục bộ với hai bộ điều khiển, thì bạn sẽ cần nhiều đối tượng người chơi và chuyển con trỏ đồng thời.

— Sậy
nguồn