Tại sao chúng ta sử dụng các kịch bản trong phát triển?


67

Trong dự án hiện tại của tôi, các tập lệnh Lua được gọi bởi các hàm C ++ ở phía máy chủ. Sau đó, các tập lệnh lại gọi các hàm C ++ vẫn trong giải pháp đó. Tại sao chúng ta nên làm những việc như vậy và không gọi hàm C ++ trực tiếp? Các tình huống trong đó các kịch bản là cần thiết?

Câu trả lời:


73

Các tập lệnh thường được biên dịch vào thời gian chạy , trong khi ngôn ngữ máy chủ sẽ được biên dịch vào thời gian biên dịch. Điều này có nghĩa là chúng ta không cần biên dịch lại nếu tập lệnh thay đổi. Việc biên dịch lại một trò chơi đầy đủ có thể mất vài phút đến vài giờ, điều này ngụ ý một năng suất lớn.

Thông thường, mã quan trọng hoặc mã phụ trợ sẽ không được viết kịch bản. Mã này nên chạy nhanh và thường quản lý bộ nhớ là rất quan trọng.
Trong các trò chơi, logic và cấu hình trò chơi thường được chứa trong các tệp script. Các kịch bản này có thể dễ dàng được cập nhật bởi những người không lập trình (như nhà thiết kế) để điều chỉnh lối chơi. Ngôn ngữ script rất dễ dàng và hành động theo cách tha thứ cho mục đích đó.

Thông thường, một ngôn ngữ kịch bản cũng được sử dụng để thực hiện kịch bản theo thời gian thực . Điều này có ích để điều chỉnh một số yếu tố chơi trò chơi hoặc thậm chí để gỡ lỗi. Nhiều trò chơi cung cấp một giao diện điều khiển cho mục đích này (chủ yếu là trong nhà).

Rất có khả năng bạn tạo một trò chơi bằng cách sử dụng một công cụ trò chơi hiện có, chỉ bằng cách viết kịch bản. Các vì vậy lớp công cụ trò chơi được tách hoàn toàn khỏi lớp trò chơi logic . Các công cụ hiện đại thường có thể được sử dụng để tạo các game FPS hoặc RTS dễ dàng như thế này, nhưng không thể áp dụng cho bất kỳ thể loại nào. Một MMO có thể sẽ yêu cầu một loại động cơ khác.

Vì vậy, dòng dưới cùng là tách rời. Các lợi ích được liệt kê ở trên thường vượt trội so với công việc làm thêm để tạo hoặc tích hợp ngôn ngữ kịch bản.


7
+1 để nói rằng các tập lệnh thường dễ cập nhật hơn bởi những người không lập trình. Nhà thiết kế không phải lúc nào cũng là lập trình viên, và họ không phải như vậy.
Sồi

19
Tôi cảm thấy như tôi đang lặp lại chính mình trong mọi câu hỏi về kịch bản - nếu quy trình làm việc của bạn yêu cầu những người không phải lập trình viên lập trình (bao gồm cả kịch bản), thì nó sẽ cắn vào mông bạn sau. Các nhà thiết kế không phải lúc nào cũng là lập trình viên, nhưng ngay khi họ viết các kịch bản không tầm thường (ví dụ ngay khi họ cố gắng xác định hàm hoặc sử dụng một vòng lặp), họ sẽ giả vờ là một. Nếu họ không được đào tạo về lập trình, điều đó sẽ kết thúc trong nước mắt và lãng phí thời gian cho mọi người.

5
Joe - điều đó không làm mất hiệu lực đối số, điều đó chỉ có nghĩa là bạn phải quyết định nơi tách rời "công cụ lập trình" khỏi "công cụ thiết kế" và đường phân chia sẽ khác nhau dựa trên chuyên môn kỹ thuật của các nhà thiết kế của bạn (hoặc thiếu trong đó).
Ian Schreiber

3
Tôi khá chắc chắn rằng bất kỳ nhà thiết kế tự tôn trọng nào cũng được dạy tốt bằng ít nhất một ngôn ngữ. Để làm rõ mọi thứ một chút, tôi muốn sử dụng thuật ngữ "không lập trình viên" vì ai đó không phải là kỹ sư phần mềm. Tôi rất tiếc khi sử dụng thuật ngữ này, nhờ Joe tôi thấy nó mơ hồ. Tôi tin rằng có một loạt các lập trình viên, từ những người viết XML đơn giản đến lắp ráp khó tính đến xử lý tín hiệu nặng toán học. Tôi hy vọng điều này sẽ giải quyết vấn đề đối ngẫu "không lập trình viên".
Nef

8
Tôi không nghe ai đề nghị rằng các nhà thiết kế nên viết các kịch bản quan trọng, phức tạp cho sản xuất. Tuy nhiên, các nhà thiết kế với sự hiểu biết khiêm tốn về lập trình vẫn có thể điều chỉnh một số tập lệnh bằng thực nghiệm (và sau đó loại bỏ các lập trình viên thực tế). Họ chắc chắn có thể viết các tập lệnh ad hoc đơn giản từ bảng điều khiển trong thời gian chạy để tạo điều kiện cho thử nghiệm của riêng họ. Tôi tưởng tượng các nhà thiết kế có thể muốn tận dụng kịch bản cơ bản để tạo ra các thiết kế màn hình mới (ngay cả khi chúng không hơn gì các mockup tương tác, bán chức năng). Rất nhiều mã phi sản xuất cần viết.
Mike Strobel

38

Bạn đã hỏi sai câu hỏi. Câu hỏi thực sự, tôi nghĩ, là tại sao chúng ta đưa ra các ngôn ngữ "không viết kịch bản" như C, C ++, Java, v.v. Và câu trả lời là một lý do: hiệu suất. (Và có thể là quán tính, nhưng quán tính đó là do hiệu năng và bất kỳ ai có thể viết C / C ++ / Java tốt đều có thể viết ít nhất là Ruby / Python / Lua / JavaScript.

Chúng tôi sử dụng các ngôn ngữ "scripting" (có nghĩa là, mức độ rất cao, rác được thu thập và thường là một số hình thức gõ lỏng hơn và biên dịch động) bởi vì chúng thường là ngôn ngữ dễ dàng hơn cho bất kỳ ai - bao gồm các lập trình viên - để viết mã. những thứ ngu ngốc như nhớ để giải phóng sau khi bạn malloc hoặc đảm bảo mã của bạn là ngoại lệ an toàn hoặc ghi nhớ để làm cho tất cả các hàm hủy của bạn trở nên ảo. Nếu máy tính của chúng tôi cực kỳ nhanh, chúng tôi sẽ sử dụng ngôn ngữ "scripting" cho mọi thứ.


4
Tôi thích lập luận này vì thế tốt hơn nhiều so với "vì vậy các nhà thiết kế có thể lập trình." Đó là một ý tưởng rất tồi để loại bỏ giá trị của sự phát triển nhanh chóng và có thể thử nghiệm các thay đổi mà không cần biên dịch lại mọi thứ.
ojrac

10

Các ngôn ngữ kịch bản cho logic trò chơi là một ví dụ rất hay về mẫu kiến ​​trúc phần mềm Alternate Hard and Soft Layer . Có một cuộc thảo luận tốt trên trang web đó (và những người khác tôi chắc chắn) về lợi ích của việc đó.


8
  1. Mỗi lớp lua mới là hai dòng. Mỗi lớp C ++ mới là nỗi đau.
  2. Không than vãn về các loại khi tất cả những gì bạn muốn là xáo trộn các giá trị xung quanh.
  3. Thu gom rác thải.
  4. Mã script được cách ly độc đáo trong các máy ảo, tránh xa tất cả các phân đoạn lang thang khó chịu và tràn mảng.

5

Thay đổi tập lệnh rất dễ triển khai. Ví dụ: bạn có thể giữ các tập lệnh trong cơ sở dữ liệu, điều đó có nghĩa là thay vì triển khai lại nhị phân đầy đủ và có thể khởi động lại dịch vụ, bạn chỉ cần đưa ra một câu lệnh SQL UPDATE duy nhất, có thể theo sau là tín hiệu cho dịch vụ đang chạy của bạn để tải lại tập lệnh.

Ngoài ra, các ngôn ngữ tập lệnh thường đơn giản dễ hiểu và dễ lập trình, do đó bạn không cần các nhà phát triển 'khó tính' (những người liên quan đến Quản lý bộ nhớ / Con trỏ và tối ưu hóa mức cpu) cho phần lớn mã (nếu là một game nhập vai lớn, các tập lệnh cho AI, Phép thuật, Hiệu ứng vật phẩm và thế giới thường lớn hơn mã động cơ). Các ngôn ngữ script cho phép tập trung nhiều hơn vào 'cái gì' hơn là 'làm thế nào' do Bộ sưu tập rác (trong trường hợp của Lua) và mức độ trừu tượng cao hơn.


4

Một tình huống trong đó các đoạn mã rất hữu ích là khi chúng ta muốn công cụ của chúng ta có thể mở rộng bằng các plugin / addons. Các tiện ích mở rộng này được tạo ra trong nhiều trường hợp bởi những người không chuyên nghiệp (như những người chơi và người đam mê tiên tiến). Kịch bản an toàn hơn và dễ dàng hơn cho mục đích này. Bằng cách sử dụng tập lệnh, họ không cần sử dụng trình biên dịch và không cần biết về con trỏ ...

Một ví dụ tuyệt vời về điều này là trò chơi World of Warcraft. Nó có hàng ngàn addon được tạo bởi cộng đồng. Các addon này được viết bằng LUA + XML.

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.