Tại sao đặt cấu hình thực thể bên ngoài các tập lệnh?

Tôi đã thấy rất nhiều trò chơi xác định các thành phần thực thể trong tệp tập lệnh, nhưng khi chúng định cấu hình từng thực thể và chỉ định thành phần nào có, chúng sử dụng một số định dạng tệp khác (như XML). Tại sao họ làm điều đó?

Tôi đang hỏi chủ yếu để xem lý do của người khác là gì cho việc này. Tôi cũng định cấu hình các thực thể của mình bên ngoài các tập lệnh (mặc dù tôi đã chọn JSON chứ không phải XML). Lý do của tôi để làm điều này là để giúp tôi dễ dàng thực hiện lưu trò chơi hơn và cũng vì tôi nghĩ loại cấu hình này được tổ chức tốt hơn trong một cái gì đó như XML hoặc JSON.

Câu trả lời của @ Christopher Larsen: Quá lâu để đăng bình luận

Tôi sợ bạn có thể đã đi lệch một chút so với chủ đề của câu hỏi. Các vấn đề bạn đang mô tả có liên quan nhiều hơn đến các thực thể dựa trên phân cấp; lưu ý trong câu hỏi của tôi, tôi đã đề cập đến việc tôi đang nói về các thực thể dựa trên thành phần.

Đây là một ví dụ về những gì tôi muốn hỏi. Dưới đây là hai cách khác nhau để định cấu hình một thực thể: thông qua tập lệnh và thông qua tệp JSON bên ngoài. Câu hỏi của tôi là, tại sao nhiều người thích cấu hình thực thể bên ngoài các tập lệnh?

Một lớp thực thể cơ sở:

class Entity:
    def __init__(self, name):
        pass
    def addComponent(self, comp):
        pass

Cách tiếp cận kịch bản:

orc = Entity('Orc')
orc.addComponent(PositionComponent(3.4, 7.9))

Cách tiếp cận JSON:

{
    "name" : "Orc",
    "components":
    {
        "PositionComponent": {
            "x" : 3.4,
            "y" : 7.9
        }
    }
}

Tôi đã nêu lý do của tôi để sử dụng phương pháp này, đó là kỹ thuật và tổ chức. Tôi muốn biết lý do tại sao rất nhiều người khác (từ những gì tôi đã thấy) sử dụng điều này.

Ưu điểm chính xuất hiện trong đầu tôi là nó cho phép cấu hình được chỉnh sửa / quản lý bởi một người không lập trình mà không yêu cầu họ chạm vào bất kỳ kịch bản trò chơi nào.

Một lý do tôi thường sử dụng tệp cấu hình thay vì tập lệnh này là:

Cách duy nhất để kiểm tra tính chính xác của tập lệnh, ví dụ: chỉ định tất cả các giá trị và như vậy là chạy tập lệnh.

Viết mã để cho phép các tập lệnh cấu hình các giá trị có nghĩa là viết mã để tạo các đối tượng bộ xương cho các tập lệnh để điền vào các giá trị và sau đó xác nhận rằng tập lệnh đã làm như vậy và như vậy. Mã của nó nhiều hơn và mã buggier hơn là tải từ tệp cấu hình phẳng, thường sử dụng thư viện hỗ trợ một số loại cơ chế xác thực.

Cấu hình thực thể có thể chỉ đơn giản là một tuần tự hóa của một thực thể cụ thể. Điều này cho phép bạn xử lý đầu ra của công cụ chỉnh sửa và chỉnh sửa trò chơi gần giống như cách bạn lưu trò chơi. Đặc biệt, đối với các trò chơi mà bạn không thể dự đoán trạng thái của một thực thể nhất định trong quá trình lưu trò chơi - ví dụ vì AI của chúng hoặc do chúng được tạo một phần theo thủ tục ở nơi đầu tiên - thật hữu ích khi có thể kết xuất toàn bộ dữ liệu xác định những gì một thực thể "là" (trái ngược với những gì nó "làm") như là một luồng byte được lưu.

Mẫu bạn mô tả là một triển khai của Hệ thống hướng dữ liệu.

Các hệ thống điều khiển dữ liệu thường được sử dụng trong phát triển trò chơi vì chúng cho phép định nghĩa nội dung được gói gọn bên ngoài vào nguồn. Đại diện bên ngoài này sau đó có thể dễ dàng được sửa đổi (và thậm chí được cập nhật trong thời gian thực bởi một ứng dụng đang theo dõi sửa đổi) để thay đổi cách hành xử của một thực thể.

Khi dữ liệu được xác định bên ngoài, bạn có tất cả các khả năng về cách các nhà thiết kế tương tác với nó, từ chỉnh sửa trực tiếp các tệp văn bản (ugh!) Đến các UI tinh vi hướng dẫn các lựa chọn của nhà thiết kế một cách hợp lý, nhất quán và thậm chí được xác minh tính chính xác (từ quan điểm của sự cân bằng trò chơi) cách.

Nếu dữ liệu được nhúng trực tiếp vào mã, mọi thay đổi sẽ yêu cầu xây dựng lại ứng dụng, đối với các dự án lớn sẽ tốn thời gian vừa phải cũng như thời gian cần thiết để triển khai các nhị phân (ví dụ: nhị phân mới phải được triển khai và cài đặt trên người phục vụ).

Hãy lấy một ví dụ về một thực thể vô hình "orc" ...

Một cách để thực hiện cho orc của chúng tôi là viết một mô tả đầy đủ bằng mã của tất cả các đặc điểm và logic cho orc.

• tối đa = 10
• sát thương = 3 sát thương mỗi giây
• chạy trốn = đúng
• runawaywhen = sức khỏe <10
• hung hăng = đúng

Khi chúng tôi khởi tạo Orc, tất cả các giá trị của chúng được khởi tạo giống hệt nhau (hoặc có thể là tĩnh). Vấn đề nảy sinh là một số nhà thiết kế sẽ xuất hiện và nói rằng "Chúng tôi cần một loại orc khác cho các khu vực người mới, ít sức khỏe hơn, không bao giờ chạy trốn và không hung hăng. Điều đó sẽ cho người chơi mới quen với việc chiến đấu mà không cần tăng độ khó và nhầm lẫn trong khi học hệ thống chiến đấu ".

Tuyệt vời, bây giờ bạn cần một lớp khác hoặc (có thể chúng tôi đã mong muốn) điều chỉnh các giá trị chúng tôi cung cấp cho "nhà máy" tạo ra orc khi tạo chúng trong khu vực "người mới". Vì vậy, chúng tôi thực hiện các thay đổi, triển khai nhị phân mới. Chỉ có những người chơi trò chơi quay trở lại và nói rằng các giá trị sức khỏe mới quá thấp khi chúng ta tiêu diệt lũ Orc trong một đòn.

Nếu hệ thống của chúng tôi được điều khiển dữ liệu (và điểm thưởng cho các ứng dụng hỗ trợ tải lại khi thực hiện sửa đổi), thì các sửa đổi cần thiết để đáp ứng trình thiết kế và người thử nghiệm chơi là những thay đổi dữ liệu đơn giản không cần biên dịch lại / triển khai. Điều này làm cho các nhà thiết kế hài lòng vì họ không bị kẹt chờ đợi thay đổi mã và nó làm cho các lập trình viên hài lòng vì chúng tôi liên tục sửa đổi mã nguồn để điều chỉnh các giá trị.

Đưa các hệ thống điều khiển dữ liệu đến cực đoan cho phép mọi thứ từ cấp độ trò chơi, phép thuật và thậm chí các nhiệm vụ được thực hiện bằng các thay đổi đơn giản đối với dữ liệu của bạn không yêu cầu thay đổi mã nào cả. Cuối cùng, đó là về việc làm cho nó dễ dàng để tạo, tinh chỉnh và lặp lại nội dung trò chơi.

Trong ví dụ của bạn, bạn thực sự đang sử dụng hai ngôn ngữ scripting. Đây là cách tôi sẽ nói về lâu dài sẽ tốt hơn nhưng tôi sẽ đề nghị bạn thống nhất ngôn ngữ kịch bản bạn đang sử dụng. Nếu ví dụ về kịch bản mà bạn đưa ra được thực hiện ở Lua thì thay vì Json, tôi sẽ nói hãy sử dụng các bảng của Lua để xây dựng đối tượng của bạn. Cú pháp thực sự sẽ tương tự và cho phép bạn hỗ trợ một giao diện để hiển thị các thành phần của bạn.

Để giải thích lý do tại sao mọi người chọn làm điều đó thường bằng XML và sau đó là tập lệnh theo logic, điều này có hợp lý khi bạn nói không. Dưới đây là định nghĩa của tôi về đối tượng trong dữ liệu, định dạng lưu trữ dữ liệu tốt là gì? Nó hầu như luôn luôn là XML (mặc dù tôi cũng đi với JSON;). Và sau đó khi họ muốn thêm vào logic, điều đó được mã hóa hoặc đưa vào một tập tin kịch bản.

Nó không suy nghĩ sai nhưng trong mắt tôi mọi người chỉ không đi đến bước tiếp theo. Nhìn vào bất kỳ ngôn ngữ đầy đủ, c / c ++ / c # ,. Bạn có thể định nghĩa tất cả các đối tượng và logic của chúng trong một ngôn ngữ, tại sao không làm như vậy trong giao diện tập lệnh của bạn ... Nó gần giống như nói rằng chúng ta nên định nghĩa các lớp của chúng ta trong XML và các phương thức của chúng ta trong c # khi bạn nghĩ về nó. Có thể các ngôn ngữ kịch bản trò chơi cũ không đủ mạnh và nó vẫn tiếp tục như cách nó được thực hiện.