Các ngôn ngữ dành riêng cho tên miền để tạo kịch bản [đã đóng]


12

Như hầu hết các bạn đều biết, các trình thông dịch nhúng cho các ngôn ngữ như Lua và Python được sử dụng rộng rãi cho logic trò chơi kịch bản, nhưng tôi chưa thấy nhiều thông tin về những người sử dụng ngôn ngữ dành riêng cho miền của họ, ví dụ: xây dựng một phương ngữ logic kịch bản nhỏ 'trên đầu ngôn ngữ được sử dụng cho phần còn lại của trò chơi, sử dụng macro hoặc lập trình trôi chảy hoặc không có gì.

Vì vậy, câu hỏi của tôi là như sau:

  • Những ví dụ nào về DSL như vậy bạn đã thấy trong các trò chơi trong thế giới thực?
  • Những vấn đề đã được chạy vào?
  • Bạn có muốn giới thiệu tuyến đường này cho các nhà phát triển trò chơi khác không, và trong hoàn cảnh nào?
  • Bạn có thấy điều này trở nên phổ biến hơn khi phát triển trò chơi chuyển sang các ngôn ngữ thân thiện với siêu lập trình hơn, ví dụ như Boo?

Để trả lời câu hỏi sử dụng DSL trong thế giới thực, Battlefield 1942 đã sử dụng chúng. Mặc dù rất nhiều mod đã xuất hiện; từ quan điểm của các lập trình viên (của tôi), điều đó thật kinh khủng và tôi mất hứng rất nhanh.
Jonathan Dickinson

Câu trả lời:


6

Lời khuyên của tôi sẽ là "không".

Tôi đã sử dụng ngôn ngữ đánh dấu dành riêng cho tên miền cho dữ liệu trò chơi. Đó là một nỗi đau. Tôi đã dành nhiều ngày để thiết kế nó, và sau đó mỗi tuần hoặc hai tuần tôi cần phải điều chỉnh nó để thêm nhiều tính năng hơn. Tại một thời điểm, tôi nhận ra rằng tôi cần phải tự động tạo một số dữ liệu trò chơi của mình và cuối cùng tôi đã viết một chương trình nhỏ để phân tích các tệp đầu vào bằng ngôn ngữ đánh dấu, xoa bóp chúng và xuất các tệp khác nhau bằng ngôn ngữ đánh dấu.

Tôi thực sự không biết tôi đang nghĩ gì. Toàn bộ mọi thứ sẽ đơn giản hơn, hiệu quả hơn, ít bugprone hơn và ít tốn thời gian hơn nếu tôi chỉ sử dụng Lua.

Nếu bạn đang làm việc trên một hệ thống bị hạn chế đến mức bạn không thể khởi động môi trường Lua, thì có lẽ bạn nên sử dụng DSL, nhưng hãy chuẩn bị cho sự đau đớn. Nếu không tôi tin chắc rằng bạn chỉ nên sử dụng Lua. Lua ban đầu được thiết kế như một ngôn ngữ đánh dấu dữ liệu đơn giản và vẫn cực kỳ thuận lợi để sử dụng như vậy, và khi (không nếu) bạn nhận ra rằng bạn cần một cái gì đó phức tạp hơn, bạn đã có nó. Tất cả sự phát triển trò chơi hiện tại của tôi được thực hiện ở Lua và tôi chưa bao giờ hiệu quả hơn hoặc ít bugprone hơn.

Tôi không thể đề nghị chống lại DSL đủ mạnh.


Er, tại sao không? Bạn vừa mới sử dụng Lisp, tôi nghĩ đó sẽ là một trải nghiệm thú vị hơn nhiều. :) Starcraft II có ngôn ngữ kịch bản Galaxy, đây thực sự là ngôn ngữ dành riêng cho tên miền nhắm vào những kẻ / cô gái phi công nghệ.
jacmoe

3
Lisp sẽ không phải là DSL nhiều hơn Lua hoặc Python. Nó sẽ là một ngôn ngữ được hình thành đầy đủ mà người khác đã dành một thời gian dài để thiết kế, thời gian mà bạn có thể tránh chi tiêu cho mình.
coderanger

2

Tôi chưa thấy nhiều thông tin về những người sử dụng ngôn ngữ dành riêng cho tên miền cho các tập lệnh của họ, ví dụ: xây dựng một tập lệnh logic nhỏ "phương ngữ" trên đầu ngôn ngữ được sử dụng cho phần còn lại của trò chơi, sử dụng macro hoặc lập trình trôi chảy hoặc không có gì.

Ngôn ngữ kịch bản có xu hướng là một đề xuất đắt tiền trong các trò chơi. Ngay cả Lua, khá nhanh, vẫn chậm hơn rất nhiều so với mã gốc. Các đội trò chơi thường chỉ sẵn sàng nhận cú đánh đó vì họ mua lại cho họ hai lợi ích rất lớn:

  1. Khả năng thay đổi tập lệnh mà không phải biên dịch lại và tải lại trò chơi.
  2. Khả năng cho những người không lập trình viết kịch bản.

DSL không cung cấp cho bạn điều đó, thật không may.


Tôi cho rằng 2) là cá trích đỏ. Đối với bất kỳ kịch bản thú vị nào, một người không chuyên nghiệp sẽ cần nhiều sự giúp đỡ hoặc gỡ lỗi với nó hơn là đáng giá. Có những nhà thiết kế lập trình viên giỏi ngoài kia không cần giúp đỡ, nhưng bạn không thể tát Lua For Dummies trên bàn của một nhà thiết kế cấp thường và mong họ sẽ vui vẻ.
tenpn

Tôi đồng ý. Tôi không nghĩ rằng # 2 hoạt động tốt trong thực tế, nhưng tôi đã thấy rằng nó được sử dụng như một lý do phô trương để tích hợp một ngôn ngữ kịch bản.
khoan hồng

Có rất nhiều người có ý tưởng trò chơi hay, có thể viết kịch bản Lua nhưng tôi không bao giờ tin tưởng gần malloc / sprintf / bất kỳ nơi nào họ phải chọn cấu trúc dữ liệu / v.v. Đó thực sự là ý nghĩa số 2 - "Khả năng các lập trình viên xấu gây ra thiệt hại tối thiểu và vẫn hoàn thành công việc."

Chúng có thể không gây rò rỉ bộ nhớ với một tập lệnh, nhưng một lập trình viên tồi vẫn có thể viết mã lỗi, không thể nhầm lẫn và mã chậm. Lập trình viên xấu không nên được cho phép gần trò chơi của bạn. Thuê các nhà thiết kế với kinh nghiệm kịch bản đã được chứng minh và bạn sẽ ổn thôi.
tenpn

2

Tôi thấy tò mò rằng câu hỏi của bạn giới hạn ở DSL bên trong , vì tôi muốn ủng hộ việc sử dụng DSL bên ngoài để có khả năng tải tập lệnh khi chạy và đặc biệt là cho phép những người không phải nhà văn viết logic trò chơi trong DSL .

Chẳng hạn, dự án hiện tại của tôi đang sử dụng DSL bên ngoài đơn giản (hiện tại) để chỉ định một phần logic trò chơi cho phép các nhà thiết kế trò chơi thực hiện các bài kiểm tra cân bằng mà không cần sự can thiệp của nhà phát triển.

Tất nhiên bạn sẽ cần phải viết một trình phân tích cú pháp; Cuối cùng, tôi nghĩ rằng công cụ được khuyên dùng nhất là ANTLR nhắm đến khá nhiều ngôn ngữ . Trong dự án của tôi, mặc dù chúng tôi đã đi theo con đường kết hợp trình phân tích cú pháp với jParsec (phần phụ trợ của chúng tôi là Java, có các biến thể trong các ngôn ngữ khác) khá tốt cho mối quan hệ chặt chẽ với BNF nhưng có lẽ ít được ghi chép lại.


2

Lời khuyên của tôi sẽ là: Làm !

Nhưng chỉ khi bạn có một sử dụng cho nó.

Không cần phải tạo DSL nếu bạn chỉ muốn sử dụng nó - nội bộ.

Galaxy là ngôn ngữ kịch bản mà trình soạn thảo Startcraft II đang sử dụng. Đó là một ví dụ điển hình của một ngôn ngữ cụ thể miền.

Nó nhắm mục tiêu các nhà thiết kế trò chơi hơn là lập trình viên:

Timer - Start Raise Lava Timer as a One Shot timer that will expire in 20.0 Game Time seconds
Variable - Set Raise Lava Timer = (Last started timer)
Timer - Create a timer window for (Last started timer), with the title "Lava will raise in: ", using Remaining time (initially Visible)
Variable - Set Lava Timer Window = (Last created timer window)
Timer - Show (Last created timer window) for (All players)
Variable - Set Lava Death? = false

Hướng dẫn mẫu

Lisp là ngôn ngữ hoàn hảo để sử dụng để tạo các ngôn ngữ cụ thể cho miền, nhưng tất nhiên còn có các tùy chọn khác. Giống như Boo.

Bằng cách đó, các nhà thiết kế / modder của bạn không phải học lập trình, ngay cả khi đó chỉ là Lua, nó vẫn là lập trình.

Chỉnh sửa: Hãy để tôi thêm rằng DSL có thể được triển khai bằng ngôn ngữ kịch bản - nó không đồng nghĩa với việc không sử dụng ngôn ngữ kịch bản. Đặc biệt là nếu bạn đang sử dụng Lisp hoặc tương tự, vì nó cho vay rất tốt để tạo các ngôn ngữ cụ thể cho miền.


1

DSls nội bộ chỉ là đường cú pháp trên một API tốt. API là điều quan trọng nhất. Sau khi bạn có một API tốt, việc tạo một dsl là không đáng kể và điều đó không quan trọng.


0

Có thể cho rằng UnrealScript là DSL. Nó dường như hoàn thành công việc, mặc dù tôi nghĩ rằng có thể làm cho các ngôn ngữ kịch bản trò chơi thậm chí còn 'đặc thù miền' hơn thế. Tôi sẽ khuyên bạn nên tạo DSL nếu có một cái gì đó cụ thể cho miền sẽ được hưởng lợi từ thay đổi ngôn ngữ - Tôi có một vài ý tưởng trong lĩnh vực này nhưng hiện tại chưa có gì được hình thành đầy đủ.

Bạn có thấy điều này trở nên phổ biến hơn khi phát triển trò chơi chuyển sang các ngôn ngữ thân thiện với siêu lập trình hơn, ví dụ như Boo?

Tuy nhiên, tôi không nghĩ rằng một công cụ khá mới hỗ trợ ngôn ngữ là bằng chứng cho sự phát triển trò chơi theo một hướng nhất định. Đó là những ngày đầu.


0

Nếu những gì bạn thực sự cần là một ngôn ngữ lập trình có mục đích chung thì việc tự lăn lộn gần như chắc chắn là một sai lầm. Nếu ngôn ngữ của bạn dường như cần các biến, đánh giá biểu thức, vòng lặp, điều kiện, lớp, hàm và tương tự thì tốt nhất hãy sử dụng ngôn ngữ đã biết như Lua, Lisp, Python, JavaScript, v.v. [Unreal đã từ bỏ ngôn ngữ của họ.]

Nhưng nếu những gì bạn cần chủ yếu là về việc xác định dữ liệu; có lẽ là tuyên bố hơn là bắt buộc; có lẽ định nghĩa các trạng thái và quy tắc (như GDL); và không cần hầu hết những gì một ngôn ngữ GP làm tốt, sau đó xem xét DSL.

Nhưng hãy cẩn thận: việc tạo ngôn ngữ và trình biên dịch có thể rất khó khăn và kinh nghiệm trước đây là một trợ giúp lớn. Tôi muốn giới thiệu một trình phân tích cú pháp PEG (chính là DSL) dựa trên ngữ pháp EBNF (một DSL khác) và nếu đó là một câu hỏi quá lớn, thì tốt nhất không nên thử.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.