Sử dụng các cú pháp được tiêu chuẩn hóa trong chơi game: phải hay không?

TL; DR: Sử dụng CSS như một yếu tố trong việc xác định các quy tắc trong các trò chơi chiến lược theo lượt dân sự: Sự điên rồ hay chỉ là sự điên rồ cũ kỹ?

Câu hỏi thực sự:

Thiết kế quy tắc phân tích quy tắc là một nỗi đau. Mỗi trò chơi ngoài kia dường như xác định bộ quy tắc riêng của mình về cách phân tích các quy tắc (tất nhiên là trong trường hợp trò chơi có các quy tắc tùy chỉnh, tất nhiên).

Có phải là thời gian cho các trò chơi dev. cộng đồng để nắm lấy synatxes tiêu chuẩn hóa cho các quy tắc?

CSS có phải là một lựa chọn khả thi cho các trò chơi tùy biến không?

Ví dụ: Xem xét giống như Civil với các quy tắc tùy chỉnh; thật tuyệt vời khi không thể thiết kế các quy tắc như sau:

artillery:era(modern) {
  range: 2;
  sprite: url(/isophex/artillery.png);
}

artillery:era(classical) {
  range: 1;
  sprite: url(/isophex/cannon.png);
}

Tôi đồng ý với đề xuất của Michael Stum về việc giữ XML, để tránh viết trình phân tích cú pháp giống CSS của riêng bạn. Nếu bạn có thể tìm thấy một thư viện phân tích cú pháp CSS hiện có, nhưng ngược lại, KISS .

Đây là ví dụ của bạn có thể trông như thế nào trong XML:

<artillery era="modern">
    <range>2</range>
    <sprite>/isophex/artillery.png</sprite>
</artillery>

<artillery era="classical">
    <range>1</range>
    <sprite>/isophex/cannon.png</sprite>
</artillery>

Không quá khác biệt hả? Và với một trong nhiều thư viện phân tích cú pháp XML ngoài kia, tôi đảm bảo nó sẽ là một miếng bánh để tải một tệp như vậy.

Cá nhân, tôi cũng sẽ sử dụng XML cho các quy tắc hoặc các tệp cấu hình khác.

Có một số lựa chọn thay thế khác như YAML hoặc JSON . Chúng thường có kích thước tệp nhỏ hơn các tệp XML (nếu đó là mối quan tâm) và có các trình phân tích cú pháp mạnh mẽ để đọc các tệp này. Cú pháp của họ cũng gần với CSS hơn nếu điều đó quan trọng với bạn :-)

Ngôn ngữ của bạn trông giống như CSS, nhưng không phải vậy. Đó là ngôn ngữ cụ thể miền của riêng bạn.

Hãy tự hỏi mình điều này: Bạn có thực sự muốn tạo định dạng tệp của riêng mình mà bạn cần phải viết trình phân tích cú pháp. Trình phân tích cú pháp này cần phải nhanh và mạnh mẽ. Bạn cũng cần ghi lại định dạng tệp của mình và dạy mọi người cách thức hoạt động - sau tất cả, đó là ngôn ngữ tùy chỉnh. Sau đó, bạn cần lưu ý rằng bạn có thể gặp phải các vấn đề mà bạn chưa từng nghĩ đến - có thể ai đó nghĩ rằng đó là một ý tưởng tuyệt vời để tạo tệp 50 MB và trình phân tích cú pháp của bạn gặp sự cố, làm hỏng một trò chơi lưu trữ hoặc như vậy. Hoặc bạn quyết định bạn cần thêm một tính năng chỉ có thể được thực hiện với một thay đổi cú pháp vi phạm, do đó phá vỡ tất cả các tệp hiện có.

Lý do tại sao các định dạng như XML rất phổ biến là vì XML đã giải quyết được các vấn đề này. Bạn có thể tìm thấy nhiều trình phân tích cú pháp XML tuyệt vời được chứng minh là mạnh mẽ, nhanh chóng và không bị rò rỉ. Ngoài ra, nhiều người biết các tệp XML và cách chỉnh sửa chúng, và vì đó là một cú pháp chung nhưng được xác định rõ ràng, bạn có thể chắc chắn rằng bạn có thể mở rộng sau này.

Động lực của bạn dường như dễ dàng chỉnh sửa bằng tay, điều phổ biến trong SDK cộng đồng. Bây giờ, lý do mọi người chỉnh sửa các tệp đó bằng tay là vì họ không có các công cụ mà Game Dev sử dụng. Bạn có thể giả định rằng một công ty phát triển trò chơi trong vài năm có một số công cụ đồ họa để chỉnh sửa các tệp đó - chúng có thể không tuyệt vời và không có lỗi, nhưng họ chỉnh sửa các tệp cho bạn và các nhà phát triển hiếm khi chỉnh sửa chúng bằng tay để chỉnh sửa thứ gì đó. Những công cụ này hiếm khi được phát hành trong 'Modding SDK', vì vậy hầu hết các modder đều chỉnh sửa bằng tay.

Vì vậy, phản ứng ban đầu của tôi sẽ là: Thay vì dành thời gian phát triển một định dạng mới, chưa được chứng minh, dễ chỉnh sửa bằng tay, tôi thà sử dụng định dạng được chứng minh bằng trận chiến và dành thời gian viết các công cụ giúp chỉnh sửa dễ dàng.

Nhưng tuyên bố chăn không hoạt động như thế. Nó luôn luôn phụ thuộc. Nếu bạn dành từ 3 năm trở lên để viết một trò chơi lớn với một nhóm phát triển khá lớn, thì bạn có thể dành nhiều thời gian để phát triển, thử nghiệm và hoàn thiện hệ thống của mình. Nếu bạn có 15000 tệp để phân tích cú pháp, thì việc tìm cách giảm sử dụng bộ nhớ trở nên quan trọng.

Nhưng đối với các trò chơi nhỏ / vừa / độc lập, tôi sẽ sử dụng định dạng được biết đến và được hỗ trợ tốt như XML và một công cụ tuyệt vời để chỉnh sửa nó.

Những gì bạn đang đề xuất không phải là một cú pháp tiêu chuẩn. Có vẻ như một cú pháp tiêu chuẩn, nhưng nó không thực sự là CSS và mô hình CSS không phù hợp với những gì bạn đang cố gắng thực hiện. Cú pháp tốt trong việc chọn cấu trúc, nhưng không mô tả chúng.

Vít XML. Đó là dài dòng, ồn ào, khó chịu khi phân tích, rất nhiều trường hợp khó khăn và đối với tất cả các yêu cầu xác nhận của nó, không ai thực sự làm điều đó. Tôi đề nghị YAML . Đây là định dạng mô tả dữ liệu tiêu chuẩn, với các thư viện phân tích cú pháp có sẵn cho bất kỳ ngôn ngữ lập trình thực tế nào.

Vì vậy, đây là mã của bạn sẽ trông như thế nào trong YAML - đầu tiên là một biến thể chưa được xử lý, sau đó với các thẻ loại tùy chọn cho những người quá tầm thường để thực sự hoàn thành công việc.

artillery:
    modern:
        range: 2
        sprite: /isophex/artillery.png
    classical:
        range: 1
        sprite: /isophex/cannon.png

--
artillery:
    !Era modern: !Artillery
        range: 2
        sprite: !URI /isophex/artillery.png
    !Era classical: !Artillery
        range: 1
        sprite: !URI /isophex/cannon.png

Các định dạng thứ hai hút. Trong thực tế, bạn không thực sự quan tâm nếu ai đó đặt một! Era hoặc a! Thời gian hoặc chỉ là một từ điển đơn giản chưa được đánh dấu ở đó, miễn là nó có các phím bạn muốn - phạm vi và sprite. Nó tương tự như gõ vịt trong các ngôn ngữ lập trình, và nó làm cho mọi thứ dễ đọc hơn rất nhiều. Nếu nó không có khóa bạn muốn, thật dễ dàng để phát hiện điều đó tại thời điểm tải ngay cả khi không có lược đồ. Điều này thật tuyệt, vì dù sao bạn cũng cần mã, vậy tại sao lại lặp lại? (Điều này cũng có nghĩa là miễn là ứng dụng biết cách giải quyết các URI, bạn sẽ không gặp rủi ro khi ai đó vô tình gọi chúng là URL và không xác thực vì những lý do ngu ngốc, như bạn đã làm.)

Nếu bạn thực sự cần phải có một mô tả có thể phân tích được các tệp dữ liệu - như, bạn muốn tự động tạo các trang thuộc tính cho người chỉnh sửa và vì lý do nào đó thực hiện nó trong cùng một cơ sở mã vì công cụ của bạn không được chấp nhận - bạn có thể sử dụng một cái gì đó như lược đồ Kwalify .

Theo tôi hiểu đề xuất của bạn, bạn đang nói về việc tạo một Ngôn ngữ cụ thể miền (DSL) bên ngoài cho các quy tắc trò chơi của bạn, tuân thủ một cú pháp chính xác và chuẩn.

Từ kinh nghiệm của tôi trong việc xây dựng DSL cho các quy tắc trò chơi và việc tôi đọc cuốn sách gần đây về Martins của Martin Fowler , tôi tập hợp rằng hai phần chính được yêu cầu để xây dựng một cái gì đó giống như ý tưởng của bạn:

• Một mô hình ngữ nghĩa (hoặc mô hình kinh doanh) cho những gì DSL của bạn đại diện. Nếu bạn thực hiện OOP, đó sẽ là một lớp để giữ các đơn vị có các thuộc tính như thời đại, phạm vi, sức mạnh, v.v. (Tuy nhiên, OOP không bắt buộc)
• Trình phân tích cú pháp để điền mô hình đó từ các tệp văn bản sử dụng cú pháp đã chọn của bạn.

Tôi nghĩ rằng nỗ lực lớn hơn thực sự là trong việc xây dựng mô hình chứ không phải trình phân tích cú pháp, nhưng việc chọn một cú pháp tiêu chuẩn sẽ giúp trình phân tích cú pháp nhanh hơn và dễ dàng hơn để xây dựng. Hơn nữa, nếu cú ​​pháp đơn giản và / hoặc được biết đến bởi những người viết các quy tắc, họ sẽ dễ dàng hơn nhiều để làm điều đó.

Vì vậy, có, bằng mọi cách, xây dựng một mô hình kinh doanh phong phú cho các quy tắc của bạn và sau đó viết chúng bằng một cú pháp tiêu chuẩn. XML thực sự thường được sử dụng trong khả năng đó trong các trò chơi và các nơi khác, nhưng nó thường được cho là quá dài dòng và ngày càng được thay thế bằng các định dạng gọn hơn như Json hoặc Yaml (và tại sao không phải là CSS).

Hy vọng rằng sẽ giúp đưa ý tưởng của bạn trong một ánh sáng khác.

Tôi không chắc đó thực sự là cú pháp CSS, vì vậy đây là định dạng "$ selector {$ rule;}" hơn là CSS. Phản ứng ruột của tôi là phần "xếp tầng" của CSS cuối cùng sẽ quá phức tạp để làm việc và nó sẽ trông giống như mã vào thời điểm đó.