Làm thế nào tôi có thể tăng tốc độ tải chậm của các cấp độ lớn?

Tôi đã tạo một trình tải mức tải các mức được lưu theo định dạng XML. Điều này có nghĩa là tôi đang sử dụng trình phân tích cú pháp XML để đọc các mức. Nó hoạt động, nhưng mức độ lớn hơn một chút mất quá nhiều thời gian để tải. Vì vậy, bây giờ tôi đang tìm kiếm một cách để tăng tốc độ tải. Tôi không cần phải tải toàn bộ tệp cùng một lúc, vì dù sao người chơi cũng không thể nhìn thấy toàn bộ bản đồ, vì vậy tải một phần sẽ ổn.

Tôi đã nghĩ về một cơ chế tải dựa trên ô trong đó có nhiều phần của bản đồ và trình tải chỉ tải phần / ô nơi người dùng đang đứng. Nhưng tôi không chắc đó là một ý tưởng tốt.

Trước hết, bạn nên đo chính xác nơi tắc nghẽn để bạn không lãng phí thời gian để cải thiện những thứ đã đủ tốt. Nút thắt có thể là bất kỳ trong số này:

• Đọc tệp XML từ ổ cứng
• Trình phân tích cú pháp XML của bạn phân tích cú pháp nó
• Mã của bạn diễn giải đầu ra của trình phân tích cú pháp XML và chuyển đổi nó thành các cấu trúc dữ liệu nội bộ của bạn
• Việc tải các tài sản liên quan (gạch bản đồ, v.v.)
• Khởi tạo trò chơi

Nhưng câu hỏi của bạn đặc biệt đề cập đến việc tải một phần các phần bản đồ. Vì vậy, vì câu trả lời này, hãy giả sử rằng bạn đã lập hồ sơ mã của mình, thấy rằng việc đọc và / hoặc phân tích tệp XML là vấn đề và tải một phần thực sự là giải pháp rõ ràng nhất cho vấn đề của bạn.

Với các định dạng tệp dựa trên XML, điều này thường là không thể. Trình phân tích cú pháp XML dựa trên DOM sẽ cần phân tích và xác thực toàn bộ tài liệu XML trước khi bạn có thể trích xuất bất kỳ dữ liệu nào từ nó. Một trình phân tích cú pháp XML dựa trên SAX ít nhất sẽ phải đọc mọi thứ cho đến nút mà bạn đang tìm kiếm. Vì vậy, nếu bạn muốn cho phép tải một phần, bạn sẽ phải bỏ định dạng dựa trên XML và phát minh định dạng tệp nhị phân của riêng bạn nơi các khối bản đồ bắt đầu tại các vị trí tệp đã biết mà bạn có thể chọn seekmà không cần phải đọc dữ liệu ở giữa.

Khi bạn thực sự muốn tiếp tục sử dụng XML, bạn có thể lưu trữ từng đoạn bản đồ dưới dạng một tệp XML riêng biệt.

Mặc dù nó được sử dụng cho hầu hết mọi thứ và mặc dù nó được sử dụng ngay cả trong các ứng dụng có khối lượng lớn, độ trễ thấp, XML là định dạng gớm ghiếc cho hầu hết mọi thứ, nhưng đặc biệt đối với các ứng dụng có các ràng buộc kịp thời, bao gồm cả các trò chơi (ngoại trừ có thể lưu trữ cài đặt của trò chơi). Ngay cả đối với dữ liệu trực tiếp, một định dạng được gắn thẻ nhị phân đơn giản về cơ bản giống như XML, không thể đọc được bằng con người (giả sử, loại nút 16 bit, độ dài 32 bit, theo sau là nội dung), sẽ nhanh hơn nhiều lần để đọc và viết.

XML rất hấp dẫn bởi vì nó có thể đọc được và con người không cần nhiều công cụ hơn trình soạn thảo văn bản để viết tệp XML. Tuy nhiên, nó cũng là quá dài dòng, không xử lý một số loại dữ liệu (dữ liệu nhị phân, một lượng lớn số, vv) quá tốt, và phải mất rất thời gian không neglegible để xử lý.
Bạn có thể tăng tốc độ phân tích cú pháp đáng kể bằng cách sử dụng một trình phân tích cú pháp khác, có nhiều lựa chọn thay thế (quickxml, pugixml, bất cứ điều gì), tuy nhiên, điều đó không giải quyết được vấn đề chung về định dạng quá dài và dễ đọc của con người.

Mặc dù có thể chấp nhận và thậm chí không quá phổ biến, để sử dụng XML trong đường ống sản xuất của một người (mặc dù hầu hết mọi người muốn sử dụng JSON hoặc YAML), thông thường có một công cụ được tạo tùy chỉnh chạy trong quá trình xây dựng và chuyển đổi các tệp XML của bạn đến một định dạng nhị phân độc quyền có thể lý tưởng (không nhất thiết, nhưng lý tưởng) chỉ đơn giản là được tải hoặc ánh xạ bộ nhớ như vốn có. Không phân tích cú pháp gì, chỉ cần bản đồ bộ nhớ và đặt con trỏ.
Công cụ tương tự (hoặc một công cụ tương tự) thường cũng sẽ đọc trong các dữ liệu khác, chẳng hạn như kết cấu được lưu trữ ở nhiều định dạng khác nhau có thể không tầm thường để phân tích cú pháp, và cũng đưa chúng vào tệp trò chơi nhị phân theo cách để họ có thể được lập bản đồ sẵn sàng để đi.
Với định dạng chính xác, tải phải là 0,45 giây hơn 45 giây.

Có một số yếu tố để tiếp cận vấn đề này, mặc dù bạn đang đi đúng hướng.

Tải đơn

Cách tiếp cận đầu tiên, như bạn đã thử, là tải tất cả cùng một lúc. Điều này đặt tất cả thời gian tải của bạn và I / O tập tin lên phía trước. Như bạn đã nhận thấy, khi kích thước bản đồ tăng lên, thời gian tải ban đầu của bạn có thể gây khó chịu cho người dùng. Điều này cũng tạo ra giới hạn trên về kích thước thế giới tối đa của bạn dựa trên bộ nhớ yêu cầu tối thiểu của nền tảng đích.

Có hai cách khác để xử lý việc này mà tôi biết: bạn có thể chia nhỏ thế giới và tải chúng ra khỏi màn hình khi người chơi di chuyển đến gần chúng hơn (tải luồng); và bạn có thể có các khu vực tải.

Đang tải khu

Các vùng tải cho phép bạn tìm kích thước khối tối đa hoạt động thuận lợi và chia thế giới của bạn thành các phần không lớn hơn thế. Khi người chơi đi vào khu vực chuyển tuyến (cửa, hang, cạnh bản đồ), một số loại hình ảnh hoặc hoạt hình chuyển tiếp diễn ra để đánh lạc hướng người chơi. Vùng mới được tải từ hệ thống tệp, trong khi vùng cũ được lưu và không tải. Đây là một cách tiếp cận giữa đường. Mặc dù nó cho phép bạn có các thế giới lớn hơn nhiều so với dung lượng bộ nhớ của thiết bị đích và đặt tất cả nỗ lực I / O của bạn trước khi người chơi được kiểm soát, điều này làm tăng các thao tác I / O so với cách tiếp cận ban đầu của bạn. Điều này cũng có thể phá vỡ tính liên tục của trò chơi, có thể có hoặc không thuận lợi cho phong cách chơi của bạn. Sê-ri Final Fantasy có lẽ dễ nhận biết nhất cho kiểu tiếp cận này.

Tải luồng

Những gì tôi sẽ xem xét ví dụ dễ nhận biết nhất về tải luồng là Minecraft. Chun được tải đến và xóa khỏi bộ nhớ khi thay đổi độ gần của người chơi. Cũng như tải vùng, tải luồng cũng loại bỏ giới hạn trên của kích thước thế giới. Nó cũng loại bỏ sự gián đoạn của nỗ lực tải từ trải nghiệm người dùng. Tuy nhiên, đây là cách tiếp cận I / O nặng nhất của tệp, vì các vùng có thể được tải và thả khỏi bộ nhớ nhiều lần trong một phiên phát. Cũng cần phải cẩn thận để tải một vùng ở gần hơn so với chúng bị xóa khỏi bộ nhớ, để ngăn người chơi liên tục đi qua một ranh giới chunk khỏi chôn vùi trò chơi trong các hoạt động I / O. Đối với trò chơi 3D, một phương pháp được gọi là dogleggingthường được sử dụng để chặn tầm nhìn của người chơi về khu vực đang được tải. Điều này thường có dạng hành lang với một lối rẽ trong đó, nhưng có thể là bất kỳ vật cản nào cản trở tầm nhìn của người chơi.

Những cách tiếp cận nào hoạt động tốt nhất cho trò chơi của bạn là tùy thuộc vào bạn.

Hãy nhìn vào thông minh ... chính xác thì thông minh là gì?

Bạn nói rằng bạn sử dụng XML làm định dạng để lưu trữ các cấp của bạn. XML là một định dạng phân cấp được lưu trữ trong một tệp. Do đó, chúng tôi có 2 yếu tố chính ảnh hưởng đến thời gian tải của chúng tôi:

1. Tốc độ IO: Đó là một hạn chế cứng . Bạn không thể ảnh hưởng đến tốc độ đọc và viết với mã của bạn. Ít nhất là không quá nhiều. Bạn có thể sử dụng những thứ như kích thước bộ đệm của bộ xử lý, v.v. nhưng đó là thứ cấp thấp và cũng khác với máy tính.

2. Cấu trúc XML của bạn: Đây là nơi bạn có thể phát triển tự nhiên. Bạn có thể quyết định cách bạn lưu trữ mọi thứ và những gì đến sớm hơn, những gì sau đó. Bạn thậm chí có thể bắt đầu nhóm các phần của một mức thành các bộ dữ liệu nhỏ hơn và sau đó đặt các bộ dữ liệu này trong tài liệu XML lớn của bạn, những phần cần thiết trước đó gần với phần đầu của tệp.

Vì vậy, mở rộng trên yếu tố thứ hai, bạn có thể lưu trữ cấp độ của mình ở định dạng như thế này:

<level>
    <name>Dragon Boss</name>
    <par-time>45</par-time>
    <sections>
        <section>
        ...
        </section>
        <section>
        ...
        </section>
        <section>
        ...
        </section>
    </sections>
</level>

Mỗi <section> phần chứa một cấp độ để nó có thể được tải một trong số này tại một thời điểm.

Bây giờ chúng tôi đã sắp xếp định dạng thành một thứ hữu ích hơn, bước tiếp theo sẽ đảm bảo rằng chúng tôi thực sự có thể sử dụng tính năng này. Một cách là tải toàn bộ tập tin vào bộ nhớ, sau đó phá vỡ nó và chỉ bắt đầu phân tích dữ liệu mức sau khi phá vỡ nó. Do đó, bạn có thể tải các phần bổ sung theo yêu cầu mà không phải thực hiện tất cả việc tạo ra các kết cấu, vật thể vật lý đắt tiền và những gì không phải trước khi bạn cần chúng.

Nếu tệp của bạn, vì một số lý do kỳ lạ, quá lớn để tải vào bộ nhớ thì bạn có thể bắt đầu sử dụng trình phân tích cú pháp SAX thay vì trình phân tích cú pháp DOM mà bạn có thể đang sử dụng . Ưu điểm của trình phân tích cú pháp SAX là nó không cần phân tích toàn bộ tệp trước khi bạn có thể làm việc với nó. Nó cũng đọc và xử lý tệp vốn đã khác với trình phân tích cú pháp DOM, do đó, đọc cả hai có thể là một cách tốt.

Một chủ đề khác dường như sôi nổi từ ý kiến ​​của bạn về các câu trả lời khác là tổ chức dữ liệu của bạn . Nói chung, bạn nên cố gắng tách rời logic trò chơi của bạn khỏi dữ liệu trò chơi của bạn nếu có thể. Ví dụ, tải một cấp độ không có nghĩa là đọc một tệp từ đĩa và tạo mọi thứ được mô tả trong mỗi dòng của tệp. Thay vào đó, có thể tốt hơn là lưu trữ dữ liệu trong cơ sở hạ tầng trong bộ nhớ và sau đó bắt đầu làm việc trên đó khi cần thiết.

Đừng thay đổi tệp XML của bạn nếu bạn thấy nó là định dạng hữu ích để bạn làm việc.

Mẹo nhỏ là giữ tệp bạn thích nhưng không để trò chơi của bạn sử dụng tệp đó trực tiếp. Viết một thói quen đơn giản (để chạy như một phần của việc đóng gói trò chơi) để phân tích XML của bạn thành các kích thước khối tối ưu để được tải động và đồng thời tạo một chỉ mục cho các khối mà bạn có thể tải vào bộ nhớ khi trò chơi của bạn bắt đầu.

Như một ví dụ rất đơn giản nếu khoảng cách vẽ của bạn là .9km thì mỗi tệp chunk có thể đại diện cho 1 km vuông của lưới thế giới của bạn.

Trình phân tích cú pháp của bạn chia thế giới của bạn thành các tệp chunk vuông 1km

Trong mỗi tệp chunk có trình phân tích cú pháp thêm tên tệp của 8 tệp chunk liền kề với nó, theo cách đó bạn không cần phải nhấn chỉ mục để biết hàng xóm nào sẽ tải. Đồng thời thêm tọa độ trên cùng bên trái và tọa độ dưới cùng bên phải của khối lưới để bạn có thể dễ dàng kiểm tra xem vị trí của người chơi có nằm trong khối đó không

Trình phân tích cú pháp sau đó tạo một tệp chỉ mục bằng cách đi qua tất cả các khối lưu trữ tên tệp chunk, tọa độ trên cùng bên trái, tọa độ dưới cùng bên phải

Tải trò chơi, tìm kiếm chỉ mục để tìm phần nào của trình phát. Tải tệp chunk, đọc danh sách đoạn liền kề từ tệp chunk đó và cũng tải các đoạn đó. Bây giờ bạn có 9 khối được tải xung quanh trình phát của bạn. Khi người chơi của bạn di chuyển qua cấp độ nếu vị trí người chơi của bạn vượt ra khỏi đoạn hiện tại, sau đó tìm kiếm các đoạn được tải khác cho đoạn mà người chơi hiện đang ở. Sử dụng danh sách các đoạn liền kề của khối mới để tải các đoạn liền kề mới và dỡ bỏ các đoạn gần đó dài hơn liền kề.

Nếu người chơi di chuyển (dịch chuyển tức thời) tìm kiếm các khối được tải để tìm ra cái nào trong đó sẽ thất bại .. tại thời điểm đó bạn tìm kiếm lại chỉ số

Điều này về cơ bản là bỏ qua các đề xuất về cấu hình thời gian tải của bạn, đánh giá độ phức tạp của định dạng tệp, v.v. và bây giờ tôi thấy một biến thể trên đề xuất vùng tải của Stephan.

Hãy xem xét nếu bạn có một mức độ RẤT lớn - như MMO sẽ có. Thực tế bạn sẽ không tải toàn bộ trong một lần. Thay vào đó, bạn sẽ làm nó thành từng mảnh. Hoặc tải nó ở các mức độ chi tiết khác nhau - chi tiết cấp thấp (và có thể do đó tệp dữ liệu nhỏ hơn) cho những thứ ở xa và chỉ mức độ chi tiết cao gần trình phát.

Vì vậy, cách tiếp cận sẽ là một cái gì đó như thế này ...

1. Chia cấp độ của bạn thành các phần
2. Mô hình các phần này ở các mức độ chi tiết khác nhau - từ độ chi tiết rất thấp đủ để người chơi có thể xem nó từ khoảng cách xa và chi tiết rất cao cho vị trí của người chơi.
3. Chỉ tải các phần dựa trên mức độ được yêu cầu.
4. Tải động (và dỡ tải) các phần khi người chơi di chuyển.

Giả định là các phần chi tiết cấp thấp sẽ tải rất nhanh và cấp cao sẽ mất nhiều thời gian hơn.

Điều này sẽ giúp bằng cách cho phép bạn tải chỉ những gì bạn cần, không phải tất cả mọi thứ. Nó cũng cung cấp cho bạn một số quyền kiểm soát tải bộ xử lý, vì bạn sẽ không phải kết xuất hoặc mô phỏng các chi tiết tốt ở xa - chỉ nơi người chơi ở.

Đó là một câu trả lời khái quát, nhưng đó là một câu trả lời có thể phù hợp với bạn. Nó chắc chắn là một cách tiếp cận cho một mức độ rất lớn, nhưng không thực sự thực tế cho một nhỏ. Có thể nhu cầu của bạn ở đâu đó ở giữa và nó sẽ giúp ích.