Blog của Noel Llopis từ Inside Inside đã chạm vào điều này gần đây trong bài đăng "Chỉnh sửa trò chơi từ xa" . Đoạn mở đầu:
Tôi từ lâu đã là một fan hâm mộ của thời gian chạy trò chơi tối thiểu. Bất cứ điều gì có thể được thực hiện ngoại tuyến hoặc trong một công cụ riêng biệt, nên được đưa ra khỏi thời gian chạy. Điều đó khiến kiến trúc trò chơi và mã rất gọn gàng và đơn giản .
(Bài viết được đọc rất khuyến khích, như với hầu hết các nội dung của Noel, cho dù bạn có đồng ý 100% hay không.)
Tôi tin rằng chìa khóa ở đây là giữ sự phức tạp bên ngoài động cơ. Bạn vẫn có thể linh hoạt, nhưng đó là tính linh hoạt trong đường ống nội dung. Và bạn có được hiệu suất tốt hơn bằng cách không dành thời gian chuyển đổi và di chuyển dữ liệu xung quanh.
Hiệu suất tốt hơn có thể chuyển thành thời gian lặp thấp hơn, kỳ lạ, mặc dù mất một số khả năng chỉnh sửa trong động cơ: dễ dàng hơn để thử một cái gì đó nếu bạn có thể tải trò chơi trong một giây.
Việc chấp nhận một số nguyên lý của " triết lý unix " sẽ giúp bạn giữ cho chuỗi công cụ của bạn linh hoạt: một đường ống mô-đun nhỏ.
Triết lý cá nhân của tôi: nướng càng nhiều dữ liệu càng nhiều càng tốt ngoại tuyến, nhưng cung cấp hỗ trợ công cụ để nhận dữ liệu nướng mới bất cứ lúc nào. (Lưu ý rằng dữ liệu mới này không cần phát huy cho đến khi có điểm thuận tiện: nhấn nút "làm mới", cấp độ tiếp theo bắt đầu, bạn chuyển sang khu vực mới, bất cứ điều gì. Chìa khóa là tìm điểm ngọt giảm thiểu thời gian lặp với độ phức tạp mã tối thiểu và nỗ lực mã hóa.)
Tại công ty của chúng tôi, hầu hết các công cụ dành cho nghệ sĩ / nhà thiết kế của chúng tôi đều tập trung vào các vấn đề về giao diện người dùng: dễ dàng thao tác với các tài sản đơn lẻ hoặc các lô của chúng, v.v. Đôi khi, chúng chỉ là các công cụ của bên thứ 3 như Photoshop hoặc 3DS Max. Các công cụ này xuất sang định dạng trung gian (thường là xml tham chiếu dữ liệu nhị phân nguồn, nhưng không phải luôn luôn). Định dạng trung gian được chọn bởi một công cụ "tạo dữ liệu" phụ trợ, giúp biến nó thành thứ gì đó hữu ích và tải nhanh cho nền tảng đích.
Tính di động đạt được bằng cách thêm các công cụ tạo dữ liệu phụ trợ bổ sung hoặc mở rộng các công cụ tạo dữ liệu phụ trợ hiện có, có lợi thế bổ sung là vô hình đối với người tạo nội dung.
Giờ đây, với dữ liệu gia tăng phù hợp, bạn có thể có các thay đổi ở định dạng nướng trong vài giây; động cơ của bạn có thể là nhện hoặc một công cụ có thể là nhện và sau đó những công cụ này sẽ xuất hiện trong hệ thống tài nguyên của bạn, sẵn sàng để tải lại khi thuận tiện.
Các công cụ - đặc biệt là các công cụ tạo dữ liệu phụ trợ - thường chậm chạp và lỗi hơn so với mã công cụ. Điều này là ổn, bởi vì chúng dễ dàng hơn để cấu trúc lại / viết lại, mở rộng và kiểm tra; bạn có thông số kỹ thuật cho hành vi của họ và khá đơn giản để kiểm tra chúng so với một số mã công cụ.
Ý kiến của tôi về câu hỏi của bạn:
Động cơ có nên tải các định dạng hình ảnh khác nhau? Một trình tải chỉ TGA là khá dễ dàng để mã tay.
(Ngoài ra: ngay cả khi bạn sử dụng bộ giải mã TGA trong động cơ, đừng mã hóa nó. Bạn chỉ đang gặp rắc rối - có rất nhiều sự tinh tế với hầu hết các định dạng hình ảnh và rất nhiều công cụ không tuân thủ chính xác với định dạng có thể chưa được xác định rõ ràng. Tốt nhất bạn nên tìm mã thư viện được kiểm tra tốt hiện có để xử lý hình ảnh.)
Tôi có công cụ ở đây chuyển đổi từ TGA sang định dạng kết cấu bên trong của bạn, cộng với siêu dữ liệu.
Còn định dạng âm thanh thì sao? Có khả thi khi chỉ hỗ trợ tải tập tin wav? Những gì về các tập tin âm nhạc xung quanh thường rất lớn.
Chúng tôi sử dụng ba định dạng ở đây: nhạc được theo dõi (.xm), ADPCM (.wav) và Speex (.spx). Điều này chủ yếu là vì chúng tôi trên thiết bị cầm tay và các định dạng này rất nhẹ để giải mã.
Động cơ có nên có khả năng phân tích cú pháp TTF động và tạo bản đồ không? Kết cấu bao bì.
Atlasing là một vấn đề khó khăn: xem câu trả lời gần đây của câu hỏi của bạn. Nó hầu như luôn luôn đáng làm ngoại tuyến.
Ngoài ra, bạn có thể biến siêu dữ liệu trên mỗi ký tự thành cấu trúc nướng mã gần như không tải.
Khi kết thúc, bạn có thể dọn sạch và đóng gói đường ống này với trò chơi của mình cho cộng đồng mod. Bạn luôn có thể thêm các định dạng nguồn. Và không có gì ngăn bạn thu hẹp khoảng cách giữa các công cụ tạo nội dung và công cụ trong các trường hợp cụ thể; hy vọng mã nướng dữ liệu của bạn và mã nhện / mã chuyển có thể được tái cấu trúc thành các thư viện mà cuối cùng có thể được sử dụng trực tiếp bởi các công cụ tạo nội dung trong một số trường hợp. Nhưng tôi sẽ không thực hiện mục tiêu đầu tiên của mình, nhất thiết ... Chỉ cần lưu ý rằng đó sẽ là mục tiêu cuối cùng và để điều đó ảnh hưởng đến thiết kế của bạn một chút, và trước tiên hãy cho quả treo thấp.
Là một bản cập nhật, bạn có thể muốn xem xét sử dụng Định dạng tệp KTX cho kết cấu. Nó có lợi thế chủ yếu là "đọc vào structvà đi" trong hầu hết các giai đoạn GL (và từ nhận xét của bạn, có vẻ như bạn đang nhắm mục tiêu GL) trong khi vẫn linh hoạt và được xác định rõ.
Chi phí tiêu đề KTX có thể hơi cao đối với dữ liệu được nướng hoàn toàn, tùy thuộc vào mục tiêu của bạn và bạn có thể muốn từ bỏ hỗ trợ hoán đổi endian, tùy thuộc vào usecase của bạn ... nhưng ít nhất nó đáng để người xem xét thiết kế.