Bạn tìm kiếm gì trong một ngôn ngữ kịch bản? [đóng cửa]


10

Tôi đang viết một ngôn ngữ nhúng nhỏ cho một dự án khác. Mặc dù phát triển trò chơi không phải là mục đích ban đầu của nó, nhưng nó bắt đầu có vẻ phù hợp và tôi nghĩ rằng tôi sẽ phát triển nó theo hướng đó vào một lúc nào đó.

Không tiết lộ bất kỳ chi tiết nào (để tránh sai lệch), tôi tò mò muốn biết:

Những tính năng nào bạn yêu thích trong một ngôn ngữ kịch bản để phát triển trò chơi?

Nếu bạn đã sử dụng Lua, Python hoặc một ngôn ngữ nhúng khác như Tcl hoặc Guile làm ngôn ngữ kịch bản chính của bạn trong một dự án trò chơi, bạn thấy khía cạnh nào hữu ích nhất?

  • Đặc điểm ngôn ngữ (lambdas, lớp học, song song)

  • Các tính năng triển khai (tối ưu hóa hiệu suất, JIT, tăng tốc phần cứng)

  • Các tính năng tích hợp (liên kết C, C ++ hoặc .NET)

  • Hay một cái gì đó hoàn toàn khác nhau?


2
Obfuscation: Bởi vì nếu nó có thể bị xáo trộn thì có lẽ nó cũng khá linh hoạt. Ví dụ, hãy lấy Perl, có thể bị che khuất đến mức trông giống như đầu ra gây ra bởi nhiễu đường truyền từ modem 300bps (khi có người khác nhấc điện thoại ở đầu kia của ngôi nhà) vào những ngày khi chúng bị Nhanh. ;-P
Randolf Richardson

1
@Randolf: Điểm tốt. Vấn đề duy nhất với obfuscation là nó có xu hướng dựa vào một ngôn ngữ ổn định, ngôn ngữ trẻ không có. Một obfuscator hoạt động với 0.10 có thể không hoạt động với 0.11.
Jon Purdy

@Jon Purdy: Điều đó đúng (+1 cho bạn). Ngoài ra, khía cạnh của mã bị xáo trộn là khó khăn hơn để duy trì. Tuy nhiên, điều quan trọng cần lưu ý là obfuscation có thể cung cấp một thước đo thú vị về mức độ linh hoạt của một ngôn ngữ.
Randolf Richardson

5
@Randolf: khi nào perl không giống như vậy?
Ken

1
@Joe Wreschnig Đó là câu nói 'tôi nên chọn cái nào', đây là 'những tính năng tốt trong ngôn ngữ kịch bản'.
Vịt Cộng sản

Câu trả lời:


4

Tôi đang tìm kiếm hai thứ - tốc độ và sự tích hợp. Thông thường hai người đi cùng nhau, và với sự quen thuộc. Thật không may, đối với C ++, có khá nhiều ngôn ngữ không cung cấp tốc độ và tích hợp. Tôi đã sử dụng Lua và nó rất tệ. Tôi đã dành toàn bộ thời gian để viết các ràng buộc và không nơi nào đủ thời gian để viết mã.

Đặc điểm ngôn ngữ? Điểm của việc nhúng một ngôn ngữ kịch bản không phải là nó có thể có các tính năng ngôn ngữ động mạnh mẽ mà ngôn ngữ gốc của tôi không có, vì vậy nó có thể được giải thích trong thời gian chạy . Tôi thực sự không quan tâm đến điều đó, miễn là về cơ bản nó hoạt động, thì điều đó cũng ổn - và phù hợp với ngôn ngữ máy chủ của tôi (trong trường hợp này là C ++). Tuy nhiên, thật đáng kinh ngạc, các ngôn ngữ được thiết kế để tích hợp vào các ứng dụng máy chủ hoàn toàn thất bại trong phần tích hợp .

Tôi có cần đồng nghiệp không? Không, tôi không cần đồng hành. Tôi có cần gõ động không? Không, tôi cần biết loại nào đang quay trở lại với tôi từ ngôn ngữ kịch bản của mình và vì tất cả các mã hiện có của tôi được xây dựng xung quanh việc gõ rất mạnh, tôi thực sự muốn mã kịch bản của mình cũng có thể tôn trọng điều đó. Tôi có cần thu gom rác không? Không, các loại của tôi đã quản lý tài nguyên của riêng chúng và tôi chắc chắn muốn phá hủy xác định. Tôi có muốn goto không? Không- tôi muốn ném ngoại lệ.

Vấn đề tôi gặp phải là về cơ bản tất cả các ngôn ngữ kịch bản lệnh hiện tại được thiết kế để mở rộng C, không phải C ++ và không hỗ trợ đúng cách cho mô hình C ++ theo nhiều cách, và ngoài ra, chúng còn có ngữ nghĩa hoàn toàn khác nhau. Làm thế nào trên trái đất tôi sẽ dịch shared_ptr, đó là sự phá hủy xác định tự động, vào một môi trường thu gom rác? Bạn có thể viết bất cứ thư viện gói nào bạn muốn, bạn sẽ không thay đổi ngữ nghĩa ngôn ngữ cơ bản không tương thích với ngôn ngữ bạn đang cố gắng mở rộng với nó. Làm thế nào tôi có thể đảm bảo rằng đây void*là loại đúng? Làm thế nào tôi có thể đối phó với thừa kế? Làm thế nào để tôi ném và bắt ngoại lệ? Nó không hoạt động.

Một ngôn ngữ kịch bản tốt cho C ++ sẽ được nhập tĩnh, ngữ nghĩa giá trị, bị phá hủy một cách xác định, ném và bắt ngoại lệ và tôn trọng các hàm hủy / hàm tạo / sao chép của tôi, bởi vì sau đó tất cả các kiểu của tôi sẽ hoạt động, tốt và dễ dàng, và ngôn ngữ kết quả sẽ nhanh chóng và hỗ trợ tất cả các ngữ nghĩa ban đầu của tôi, dễ dàng để liên kết.


Bạn nên thử một cái gì đó như thư viện trình bao bọc này tôi đã viết cho chính mình gần đây để giải quyết một số vấn đề tương tự bạn đang gặp phải. Bạn có thể sử dụng shared_ptrs và mọi thứ với nó đều ổn, loại này an toàn (nhiều nhất có thể), bạn có thể quyết định xem bạn có muốn cuộc sống của một cái gì đó được kiểm soát bởi mã của bạn hoặc bởi môi trường Lua, nó hỗ trợ kế thừa, và nó cực kỳ giống với API Lua bình thường. Tôi không chắc chắn tôi nhận được khiếu nại về việc thực hiện các ràng buộc, mặc dù vậy, tôi chỉ sử dụng các đoạn vim để thực hiện các ràng buộc của mình 99% thời gian.
Alex Ames

2

Đối với trò chơi dựa trên web, ba yếu tố quan trọng đối với tôi là:

  • Quen thuộc
  • Tốc độ
  • Hội nhập

Tôi đặc biệt thích Perl, một phần vì tôi đã quen với ngôn ngữ này và vì với mô-đun máy chủ web như mod_perl2, có một lợi ích tích hợp và hiệu năng rất lớn - mod_perl2 giữ một phiên bản biên dịch của các tập lệnh trong RAM (chỉ được hiểu theo tải lần đầu tiên) mang lại lợi thế lớn về tốc độ so với các ngôn ngữ được dịch khác không có tùy chọn biên dịch và nó cũng tích hợp vào máy chủ Apache HTTPd với API giàu tính năng cung cấp quyền truy cập vào rất nhiều tính năng rất mạnh.

Các yếu tố này có thể hữu ích cho phát triển trò chơi dựa trên web (và khi cần truy cập cơ sở dữ liệu, lưu trữ các kết nối cơ sở dữ liệu giúp giảm thêm thời gian phản hồi cho người dùng). Tất nhiên, đây có thể không phải là giải pháp lý tưởng nhất cho mọi thứ vì mỗi ngôn ngữ đều có ưu điểm (và nhược điểm), nhưng nó luôn hoạt động tốt cho nhu cầu của tôi.


2

Sắp xếp theo thứ tự quan trọng (giảm):

  • Có thể đọc được trong nháy mắt. Trên thực tế, đó là một yêu cầu cho bất kỳ ngôn ngữ nào tôi muốn sử dụng, nhưng đối với kịch bản, nó quan trọng hơn nhiều: kịch bản, theo định nghĩa, thay đổi thường xuyên hơn mã "cốt lõi". Vì vậy, không có LISP hoặc PERL.
  • Khó chịu. Các tập lệnh liên tục được viết và viết lại, và việc nhập rất nhiều mã "soạn sẵn" là không hiệu quả.
  • Dễ dàng gỡ lỗi. Tốt nhất là với các điểm dừng, bước qua vv
  • Dễ dàng tích hợp với công nghệ "cốt lõi" đã chọn của tôi. Nếu tôi đang sử dụng C ++ cho trò chơi của mình, tôi sẽ cần các ràng buộc C ++ tốt, như trong LUA. Nếu trò chơi ở dạng C #, tôi sẽ chọn ngôn ngữ dựa trên CLI: C #, IronPython, Boo.
  • Đặc điểm ngôn ngữ: mảng kết hợp dễ dàng, coroutines, có thể là lambdas. Trên thực tế, điều này chủ yếu phụ thuộc vào những gì tôi sẽ sử dụng các kịch bản cho. Các kịch bản AI khác với các kịch bản khởi tạo.
  • Tài liệu tốt. C # có toàn bộ MSDN dành riêng cho nó và Boo chỉ có nguồn. đó là lý do tại sao C # là cách tốt hơn.
  • Môi trường phát triển tốt. VS hoặc Eclipse đánh bại Notepad mỗi lần.

+1 Điều này giúp tôi khá nhiều, cảm ơn bạn. Tôi sẽ chờ xem liệu có cuộc thảo luận nào nữa không, nhưng tôi nghĩ rằng bạn đã giải quyết nó tốt.
Jon Purdy
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.