Những gì nên được chứa trong một biểu đồ cảnh trò chơi?

Bạn có thể giúp tôi làm rõ, làm ơn, chính xác những gì nên được chứa trong một biểu đồ cảnh trò chơi? Xem danh sách sau đây, xin vui lòng:

• Diễn viên trò chơi? (rõ ràng là có, tất cả các đối tượng thay đổi trạng thái phải là phần chính của Biểu đồ cảnh)
• Trò chơi tĩnh đơn giản ojbects? (Ý tôi là từ chối các vị trí trong nền không được hoạt hình, chúng cũng không va chạm)
• Trò chơi kích hoạt?
• Đèn trò chơi ?
• Máy ảnh trò chơi ?
• Đạn vũ khí ?
• Trò chơi bùng nổ và hiệu ứng đặc biệt?

Các loại đối tượng được xem xét ở trên. Bây giờ đến phạm vi bảo hiểm của biểu đồ cảnh:

• Một biểu đồ cảnh có nên chứa toàn bộ bản đồ cấp trò chơi kể từ khi bắt đầu cấp hoặc chỉ nên chứa phần hiển thị của bản đồ? Nếu điều thứ hai là đúng, điều đó có nghĩa là biểu đồ cảnh sẽ được cập nhật liên tục, bằng cách thêm / xóa các đối tượng trò chơi, khi người chơi di chuyển. Tuy nhiên, chỉ chứa các bản đồ có thể nhìn thấy rõ ràng sẽ nhanh hơn rất nhiều để đi qua và cập nhật.

Tôi nghĩ rằng một chút tốt để đọc về những gì công nghệ đồ thị cảnh khác đang làm sẽ mang lại rất nhiều lợi ích cho bạn.

Bối cảnh
Ví dụ, nhìn vào mô tả của Ogre3D. Nó là một công cụ đồ họa dựa trên đồ thị cảnh là nguồn mở. Tôi sẽ đề nghị xem hướng dẫn và xem các nút cảnh đang được sử dụng như thế nào (Lưu ý: Tôi không bảo bạn học cách sử dụng Ogre, thay vào đó là các tính năng nào có trong các nút cảnh và trình quản lý cảnh của Ogre)

Tài liệu về CảnhNode: http://www.ogre3d.org/docs/api/1.9/ class_ogre_1_1_scene_node.html

Tài liệu về Trình quản lý cảnh: http://www.ogre3d.org/docs/api/1.9/ class_ogre_1_1_scene_manager.html

Một cái gì đó khác đáng xem là liên kết sau:
http://sgl.sourceforge.net/#features

Nó là một giải pháp đồ thị cảnh dựa trên OpenGL và trang tính năng hiển thị tất cả các nút mà nó có thể chứa.

Các nút được đề xuất của bạn
Tôi cho rằng một biểu đồ cảnh nên được trừu tượng hóa càng nhiều càng tốt khỏi logic trò chơi để bạn không gặp phải bất kỳ vấn đề phụ thuộc nào. Đối với mỗi điểm đạn của bạn, tôi sẽ nói như sau:

Diễn viên trò chơi
có lẽ tôi sẽ nói không. Tương tự như Ogre, tôi sẽ có một lớp Thực thể cơ sở (sẽ chứa logic cụ thể của đối tượng) và một CảnhNode cơ sở với một con trỏ thành viên Thực thể để có được thông tin phù hợp để hiển thị đối tượng (Vị trí, Định hướng, v.v.)

EDIT: Tôi không nói không bao gồm các diễn viên trò chơi của bạn trong biểu đồ cảnh ở đây (nếu không sẽ không có gì hiển thị: P) Tôi đang nói có một nút cảnh có tham chiếu đến lớp diễn viên trò chơi logic, vì vậy bạn đã vẫn có khớp nối lỏng lẻo của kết xuất và cập nhật các đối tượng trò chơi.

Trò chơi tĩnh đơn giản ojbects
Có

Trò chơi kích hoạt?
Không, điều này nghe có vẻ như logic cụ thể của trò chơi với tôi.

Đèn trò chơi?
Đúng

Máy ảnh trò chơi?
Đúng

Đạn vũ khí?
Không hoàn toàn chắc chắn về điều này, nhưng tôi có thể nói có, nhưng có lẽ bạn muốn tất cả các viên đạn khi còn nhỏ vào nút cảnh phụ huynh "BulletCollection", để bạn có thể lưu trữ vị trí đó và bạn sẽ không phải vượt qua đồ thị cảnh nhiều để loại bỏ và thêm đạn để kết xuất.

Trò chơi bùng nổ và hiệu ứng đặc biệt?
Không chắc chắn, tôi sẽ để người khác trả lời.

Phạm vi đồ thị cảnh
Nếu bạn có một mức độ tương đối nhỏ, bạn sẽ có thể lưu trữ toàn bộ cấp độ trong một biểu đồ cảnh và sau đó tối ưu hóa khả năng hiển thị bằng cách sử dụng Octree (thường cho môi trường ngoài trời) hoặc cây BSP (thường cho môi trường trong nhà).

Nếu bạn có cấp độ lớn hơn nhiều và bạn không muốn thực hiện bất kỳ tải cấp nào, thì đây là lúc phát trực tuyến sẽ phát huy tác dụng, nhưng đó hoàn toàn là một vấn đề khác. Tôi sẽ bắt đầu với một mức độ nhỏ và tăng dần xem bạn có thể làm cho nó lớn đến mức nào mà không ảnh hưởng xấu đến hiệu suất.

Kết luận
Đối với tôi một đồ thị cảnh là phần Render của vòng lặp trò chơi. Bạn không nên kết hợp kết xuất của mình và logic của bạn cập nhật quá gần nhau, nếu không bạn sẽ gặp phải các vấn đề phụ thuộc gây phiền nhiễu.

Xu hướng của tôi là đề nghị đưa ít thứ hơn vào biểu đồ cảnh. Xem cụ thể bài viết này của Tom Forsyth: " Đồ thị cảnh - Chỉ cần nói không ."

Mấu chốt của bài viết của Forsyth là bạn không nên cố gắng nhồi nhét một loạt các công cụ không liên quan vào một cấu trúc dữ liệu chủ lớn. Điều này gần giống với những ý tưởng mà tôi đã chạm đến trong câu trả lời này liên quan đến việc lấy mọi thứ trong trò chơi GameObjectvà sau đó đưa tất cả vào một danh sách không đồng nhất lớn (có nghĩa là, điều đó thật tệ).

Một số đối tượng tương đối trên thế giới thực sự thể hiện mối quan hệ cha mẹ và con cái mạnh mẽ như là một cấu trúc cây. Ví dụ kinh điển về tách cà phê trên bàn thường được sử dụng ở đây - chắc chắn, bạn có thể coi nó là 'đứa con' của bàn ... ít nhất là cho đến khi nó bị đánh bật. Sau đó, nó thực sự vẫn là một đứa trẻ của bảng? Điều này có nghĩa là 'cây' của bạn có thể kết thúc khá nông và loại thoái hóa vào danh sách dù sao đi nữa.

Vì vậy, tôi sẽ đề nghị bạn sử dụng nhiều cấu trúc dữ liệu cho nhiều thứ, vì nó có ý nghĩa nhất cho những thứ đó. Ví dụ, hình học và ánh sáng tĩnh dường như là một điều hợp lý để đưa vào biểu đồ cảnh. Ngay cả khi các đối tượng được đại diện không có mối quan hệ cha-con tự nhiên, thực tế rằng chúng là tĩnh có nghĩa là bạn có thể cung cấp cho chúng các mối quan hệ cha-con cấu trúc biết rằng chúng không bao giờ thay đổi.

Diễn viên trò chơi ... Tôi không chắc lắm. Trên thực tế, bất cứ thứ gì có xu hướng di chuyển, có nghĩa là bạn thường cần giữ chúng ở gần gốc của biểu đồ hoặc liên tục bố mẹ chúng (đây là một việc vặt và không siêu hiệu quả).

Đạn, cò súng, hiệu ứng đặc biệt và các vật thể thoáng qua khác tôi sẽ lưu trữ ở nơi khác. Không có gì biểu hiện hoặc có biểu diễn trực quan (kích hoạt thường là âm lượng giới hạn vô hình, một viên đạn thường chỉ là một tia đúc) nên có trong biểu đồ kết xuất. Bạn nên cố gắng tách lớp kết xuất và lớp logic .

Để biết giá trị của nó, tôi chưa bao giờ sử dụng biểu đồ cảnh giống như cây trong bất kỳ trình kết xuất nào tôi đã xây dựng cho mục đích phi học thuật (rõ ràng tôi đã xây dựng biểu đồ cảnh giống như cây trước đây, đó là cách tôi đi đến kết luận rằng tôi hiện đang cố gắng để bạn đồng ý với).

Tôi sử dụng các phương pháp phân vùng không gian phù hợp với phong cách của trò chơi (quad-tree, octree, BSP, et cetera) để nhóm / loại bỏ các thực thể logic trong trò chơi nên (a) xử lý khung này và (b) được hiển thị khung này. Sau đó, tôi kết thúc việc đưa tập hợp các đối tượng từ danh sách (b) vào một hệ thống ánh xạ các đối tượng logic để hiển thị mô tả và sắp xếp các mô tả đó vào các thùng dựa trên các thuộc tính (ví dụ: mọi thứ sử dụng độ trong suốt sẽ được đưa vào nhóm cho "công cụ nên được kết xuất ngược về phía trước). Sau đó, tôi kết xuất mọi nhóm theo thứ tự và với mỗi nhóm hiển thị mọi mô tả theo thứ tự. Tôi đoán bạn có thể gọi đây là "cây", nhưng nó không thể hiện trạng thái điển hình / biến đổi các phương pháp nhân giống mà đồ thị cảnh hướng cây truyền thống làm. YYMV,