Các kịch bản mở rộng có nên được chạy trong một hộp cát?

Đặc biệt, đây là về phần mở rộng trò chơi được viết bằng lua (luajit-2.0). Tôi đang suy nghĩ xem liệu tôi có nên hạn chế những gì các kịch bản này có thể làm hay không, và đi đến kết luận rằng có lẽ tôi không nên:

• Thật khó để có được đúng. Nghe có vẻ ngớ ngẩn, nhưng rất có thể hộp cát của tôi sẽ bị rò rỉ.

• Lợi ích duy nhất tôi có thể nghĩ đến là mang lại cho người dùng cảm giác an toàn khi chạy các tập lệnh của bên thứ ba.

• Nhược điểm là nó cực kỳ khó chịu đối với các nhà văn khuyến nông. Đó là, bây giờ, bản thân tôi (nội dung trò chơi sẽ chủ yếu là kịch bản).

Lý do tôi đang hỏi điều này ngay bây giờ trước khi tôi thực sự có bất cứ điều gì có thể trình bày được là việc thêm một hộp cát sớm rất dễ dàng, nhưng cũng sẽ áp đặt các hạn chế gây phiền nhiễu cho chính tôi. Tuy nhiên, nếu lần đầu tiên tôi tiếp tục với nó và sau đó quyết định rằng tôi cần một hộp cát, tôi sẽ gặp vấn đề (tôi phải viết lại các tập lệnh đã có sẵn hoặc giới thiệu một số dạng hệ thống quản lý ủy thác có vẻ rắc rối hơn giá trị của nó).

Tôi tin rằng cả sự phát triển của một trò chơi điện tử, trong bất kỳ sự phát triển phần mềm nào có kích thước trung bình lớn, lập trình viên sẽ luôn cố gắng tạo ra một tùy chọn trao đổi lớp hoặc tùy chọn thiết lập miễn phí cho chức năng trong tương lai.

Lua là ngôn ngữ cho phép các tùy chọn này dễ thực hiện cho người dùng cuối và cho nhà phát triển, nhưng điều đó không có nghĩa là dễ dàng lập kế hoạch cho không gian làm việc của bạn, với kinh nghiệm tôi có thể nói với bạn ngày hôm nay, một phép nhân đơn giản có thể bị rò rỉ, nếu người dùng cuối được phép tùy chỉnh hành vi của họ.

Nếu chúng ta tập trung vào những gì một trò chơi hộp cát cung cấp, chúng ta có thể hiểu rằng việc sử dụng cuối có thể là một lưỡi dao đôi, cho phép trò chơi trở thành phi tuyến tính, thú vị và vui vẻ , nhưng đồng thời không phải là kế hoạch dễ dàng giới hạn của họ trong khu vực làm việc.

Từ quan điểm bảo mật, nó có vẻ tuyệt vời! một môi trường thử nghiệm tốt cho các tiện ích mở rộng, nên được triển khai trong tất cả các loại phần mềm.

Tóm lại, tôi có thể nói rằng mặc dù có vẻ như không đáng để tạo một hộp cát cho sản phẩm của bạn, nhưng thực sự nhà phát triển hoặc nhóm nhà phát triển sẽ nhận được nhiều lợi ích hơn, vì người dùng cuối có thể dễ dàng định cấu hình môi trường của bạn tại nhà phát triển cũng có thể mất ít thời gian hơn thay đổi cấu trúc chức năng. Tôi tin chắc rằng một trò chơi hộp cát, (như trong khả năng mở rộng phần mềm), cho phép một sự phát triển sáng tạo của các phần mở rộng của chúng và một sự phát triển tự nhiên của các chức năng của nó.

Thật khó để có được đúng

Thực sự không khó để tạo ra một hộp cát cơ bản với danh sách trắng các chức năng và sau đó thêm các triển khai tùy chỉnh của các chức năng có thể không an toàn. Câu hỏi SO này có vẻ như là một điểm khởi đầu tốt.

nhưng rất có thể hộp cát của tôi sẽ bị rò rỉ

Tôi nghĩ rằng nó sẽ đủ để bắt đầu cung cấp một số bảo mật cơ bản: hạn chế quyền truy cập vào các tệp bên ngoài một số thư mục đặc biệt. Không có thứ gọi là ứng dụng an toàn 100% nào. Hãy nghĩ về những gì có thể xảy ra nếu ai đó sẽ viết một số phần mở rộng độc hại: người dùng có thể sẽ đổ lỗi cho bạn là nhà phát triển. Nếu bạn có kế hoạch cho ai đó một cơ hội để viết gia hạn, cuối cùng bạn sẽ cần một số bảo mật. Nếu chỉ có mình bạn - nó vẫn ổn.

Lợi ích duy nhất tôi có thể nghĩ đến là mang lại cho người dùng cảm giác an toàn khi chạy các tập lệnh của bên thứ ba.

Đây chính xác là lý do tại sao bạn nên làm hộp cát và nó không phải là một đối số hợp lệ chống lại hộp cát.

Nhược điểm là nó cực kỳ khó chịu đối với các nhà văn khuyến nông

Tôi có một số kinh nghiệm về kịch bản trò chơi và tôi không thấy khó chịu khi phải làm việc trong môi trường hộp cát. Điều làm tôi khó chịu là thiếu chức năng liên quan đến trò chơi, như các API cụ thể của các đối tượng trong trò chơi hoặc triển khai kém như vậy.

Nó có thể hữu ích nếu bạn xem xét công cụ LOVE như một ví dụ điển hình (nếu bạn chưa có), đặc biệt là hướng dẫn về API tập tin .