Những ưu và nhược điểm của việc kết hợp Lua vào trò chơi C ++ là gì?

Tôi có một cuốn sách lập trình trò chơi C ++ và nó có phần Lua trong đó. Tôi đã bắt đầu đọc phần Lua và nghe có vẻ thú vị, nhưng tôi không thể xác định ưu và nhược điểm của việc sử dụng Lua trong trò chơi C ++ của mình. Lợi ích duy nhất hiện tại tôi có thể nghĩ đến là bạn có thể thực hiện một số cập nhật mã hóa, thông qua Lua, mà không phải biên dịch lại. Ngoài ra, tôi không thể nghĩ gì khác. Vậy những ưu và nhược điểm của việc thêm Lua vào trò chơi C ++ là gì?

Ví dụ sẽ được đánh giá cao.

Lợi ích duy nhất hiện tại tôi có thể nghĩ đến là bạn có thể thực hiện một số cập nhật mã hóa, thông qua Lua, mà không phải biên dịch lại.

Đừng giảm giá tiện ích này một cách dễ dàng. Bạn sẽ không bao giờ hiểu bạn sẽ làm việc hiệu quả như thế nào cho đến khi bạn bỏ đi bước biên dịch lại.

Các "chảy" là một khái niệm tâm lý khá tốt-hiểu khi nói đến công việc. Dòng chảy là cảm giác mà bạn có được khi bạn tập trung vào một hoạt động, khi bạn phân tích và giải quyết vấn đề gần như không cần suy nghĩ, v.v. Bạn làm việc hiệu quả nhất khi bạn "chảy".

Biên dịch lần vít tất cả lên. Thật khó để duy trì dòng chảy nếu bạn thậm chí có một biên dịch 10 giây giữa khi thử nghiệm một cái gì đó.

Khi bạn đang phát triển trò chơi, những gì bạn thường có là một "vòng lặp chặt chẽ". Bạn có một ý tưởng, bạn viết mã một bài kiểm tra để xem nó có hoạt động không, và sau đó bạn thử nó. Nếu nó không hoạt động, bạn sửa đổi nó và thử lại. Thời gian "kiểm tra mã" là rất quan trọng để duy trì lưu lượng. Làm cho nó nhỏ nhất có thể là rất quan trọng.

Những gì Lua (hoặc bất kỳ ngôn ngữ kịch bản nhúng nào) cho phép bạn làm là kiểm tra các thay đổi, không chỉ là không "biên dịch", mà còn sống trong trò chơi . Tùy thuộc vào cách bạn xây dựng trò chơi của mình, bạn có thể chạy một lệnh sẽ khởi động lại trò chơi với các tập lệnh mới mà không phải dừng và tải lại dữ liệu, v.v. Bạn không chỉ không phải biên dịch lại mà còn không phải chạy lại.

Khả năng để làm điều này, với sự hỗ trợ động cơ thích hợp, có thể tăng năng suất đáng kể.

Một lợi ích lớn khác cho kịch bản là khả năng không quan tâm. Nếu bạn đã dành một thời gian dài để viết C ++, bạn sẽ ngạc nhiên về số lượng thời gian bạn dành cho minutae. Nơi bộ nhớ bị xóa. Nơi này được giải phóng. Ngay cả khi bạn đang sử dụng shared_ptrở mọi nơi, chỉ cần hành động gõ vào tất cả các tên loại biến đó sẽ làm bạn chậm lại.

Trong một ngôn ngữ kịch bản được gõ động, bạn không cần phải quan tâm. Phạm vi là đơn giản. Chức năng là các đối tượng hạng nhất; bạn không phải tự xây dựng functor. Nó chỉ là quá dễ dàng để làm một số điều.

Bây giờ điều đó có tiêu cực, nếu bạn không phải là một lập trình viên có kỷ luật. Rất dễ sử dụng toàn cầu trong Lua (mặc dù có nhiều cách để ngăn chặn điều đó). Không quan tâm có nghĩa là bạn có thể rất cẩu thả khi bạn viết mã.

Nhưng sau đó, một lần nữa, rất cẩu thả có thể có lợi thế .

Một ưu điểm khác của Lua là nó tạo ra một ngôn ngữ mô tả dữ liệu đẹp. Giống như JSON chỉ là một tệp JavaScript xây dựng và trả về một mảng / bảng, bạn có thể tạo các tập lệnh Lua trả về các bảng.

Điều này rất hữu ích cho các tập tin cấu hình; Định dạng bảng của Lua tốt hơn nhiều so với định dạng .ini. Định dạng vẫn khá sạch sẽ, nhỏ gọn và có thể mở rộng.

Ồ, và nó vẫn là một kịch bản Lua, vì vậy nó có thể thực hiện logic thực tế. Nhược điểm của nó là ... tốt, đó là một kịch bản Lua, vì vậy nó có thể thực hiện logic thực tế . Điều đó có thể là thảm họa trong trò chơi, vì người dùng có khả năng bắt đầu làm hỏng mọi thứ.

Nhưng thực sự, điều này dễ dàng được xử lý. Lua được thiết kế để nhúng, điều đó có nghĩa là sự cô lập thực sự khá dễ dàng. Thật vậy, một trạng thái Lua tươi không cung cấp gì theo mặc định; bạn phải thực sự làm một cái gì đó để lộ ngay cả những thư viện Lua cơ bản nhất. Truy cập tệp, truy cập trạng thái trò chơi, v.v., tất cả đều chọn tham gia, không chọn không tham gia. Và mỗi bang Lua tách biệt với nhau. Trạng thái Lua bạn sử dụng cho các tập lệnh AI không phải là trạng thái Lua bạn sử dụng cho các tệp cấu hình.

Tôi thực sự có một số mã cho phép bạn đăng ký nhiều thư viện chuẩn Lua, nhưng đi qua và xóa tất cả tệp IO. Cuối cùng, điều tồi tệ nhất mà tệp cấu hình dựa trên tập lệnh Lua có thể làm là khiến trò chơi của bạn bị sập ngay lập tức khi chạy nó, bằng cách chạy nó ra khỏi bộ nhớ. Và vì bạn không chia sẻ các tệp cấu hình này theo cách thủ công, điều đó sẽ không thú vị cho tin tặc.

Tôi muốn nói rằng nhược điểm lớn nhất của bất kỳ ngôn ngữ kịch bản nào là gỡ lỗi. Hầu hết các ngôn ngữ script không có trình gỡ lỗi và Lua cũng không khác. Lua có tất cả các công cụ mà người ta sẽ cần để xây dựng các công cụ gỡ lỗi. Nhưng nó không thực sự có trình gỡ lỗi tích hợp. Bạn phải đặt một cái lại với nhau. Và điều đó sẽ đòi hỏi một mức độ hợp lý của công việc.

Hoặc bạn có thể thực hiện do "gỡ lỗi printf". Nó thực sự phụ thuộc vào số lượng mã Lua bạn viết.

Nơi tôi làm việc:

Ưu điểm:

• cải tiến thời gian lặp lại . Trò chơi của chúng tôi được thiết lập để thăm dò hệ thống tập tin máy chủ để thay đổi và tự động "luồn lách" trong các thay đổi. (Chúng chỉ có hiệu lực ở lần mở tệp tiếp theo, nhưng trên thực tế, đó là một cải tiến lớn: tải lại cấp độ và các thay đổi lua mới của bạn xuất hiện ngay lập tức.)
• tích hợp bàn điều khiển . Bất kỳ chức năng gỡ lỗi nào cũng có thể được nối với bảng điều khiển kiểu Quake truyền thống với REPL. Đối với các bản dựng nội bộ, chúng tôi thậm chí có thể kết nối REPL với một ổ cắm đơn giản có thể nói telnet và chúng tôi có quyền kiểm soát mạng đối với trò chơi của chúng tôi.
• giảm api và đường cong học tập thấp hơn . Các nghệ sĩ và nhà thiết kế phi kỹ thuật có thể tham gia vào một số nhiệm vụ thường bị tắc nghẽn bởi lập trình viên.
• chuyên phân tích mã tĩnh . Thật dễ dàng để phân tích đầu ra luac -lvà nhìn trộm mã byte để thực hiện một số phân tích; nó cũng khá dễ dàng để phân tích hầu hết các tệp nguồn lua, đặc biệt nếu bạn có một quy ước mã hóa. Chúng tôi có thể thực thi quy ước địa phương. Bạn cũng có thể nhìn vào metalua để có thêm sức mạnh ở đây.
• xử lý lỗi . Nếu API của chúng tôi không có sự cố, ngay cả khi lua làm điều gì đó ngớ ngẩn, chúng tôi có thể bắt nó và khôi phục bằng cách sử dụng lua_pcall.
• mở rộng API dễ dàng . Viết một hàm mới cho API Lua <-> C ++ không quá khó. Ngoài ra còn có các gói sẽ giúp tự động hóa điều này.
• nguồn đơn giản . Thực hiện các thay đổi để ví dụ tránh toán học dấu phẩy động trong trình thông dịch lua (quan trọng trên một số nền tảng nhúng) hoặc để tối ưu hóa cho các hệ thống cụ thể không quá khó!
• siêu vật liệu . Những thứ này thật tuyệt. Rất nhiều tiềm năng để làm những điều thú vị trong thời gian chạy. Chúng tôi có các "bảng ảo" thực sự không có nội dung và thực hiện tra cứu cấu trúc dữ liệu phức tạp trên mặt C ++ của các trò chơi của chúng tôi.
• xác chết . Có thể dừng lại và tiếp tục, ví dụ kịch bản hành vi AI là tuyệt vời. Mặc dù vậy, cần có một chút hiểu biết hơn về phần của người viết kịch bản - chúng tôi vẫn đang nghiên cứu làm thế nào để làm cho điều này "an toàn" hơn với động cơ của chúng tôi.

Nhược điểm:

• không thể đoán trước được . Điều chỉnh những gì chúng ta stepnên thay đổi mạnh mẽ cho mỗi trò chơi. Một số hoạt động tốt hơn với đầy đủ mọi khung hình (bộ làm việc nhỏ). Một số làm việc tốt hơn với những đường chuyền nhỏ hơn không thường xuyên hơn. Lưu ý rằng có rất nhiều công việc trong việc cải thiện GC trên các phiên bản lua mới hơn và trong một số bản vá (mà bạn không nên ngại sử dụng!)
• chi phí cao hơn . Chúng tôi giữ rất nhiều cấu trúc dữ liệu lớn của chúng tôi ở phía C để tránh chi phí bộ nhớ cho mỗi mục nhập. C ++, C và lắp ráp thường tạo ra mã nhanh hơn. Vì vậy, nó giữ cho 90% công cụ trò chơi không có hiệu suất quan trọng và đôi khi chúng tôi di chuyển mọi thứ từ lua sang C (hoặc ngược lại).
• phân mảnh . Có lẽ vấn đề lớn nhất trên các hệ thống bộ nhớ nhỏ. Chúng ta thường sử dụng các nhóm đối tượng nhỏ và một đống đối tượng lớn hoàn toàn riêng biệt cho lua. Chúng tôi đặt các đường chuyền đầy đủ vào các điểm chiến lược trong trò chơi. Chúng tôi dỡ tập lệnh hoặc vứt bỏ lua_Statehoàn toàn trong một số trường hợp. Và đôi khi chúng ta vẫn có vấn đề. Điều chỉnh kích thước của các nhóm đối tượng nhỏ (chúng được cố định, vì đơn giản và chi phí thấp hơn) và kích thước của đống đối tượng lớn cụ thể lua có thể là một nỗi đau. Nhưng trên các hệ thống lớn hơn khoảng 4 MB, chúng tôi vẫn chưa bận tâm đến các đống và nhóm chuyên dụng.
• thiếu loại an toàn . Nếu bạn không xây dựng bộ công cụ phân tích mã tĩnh tốt, bạn sẽ rơi vào tình trạng kiểm tra lỗi thời gian chạy (có thể sử dụng __indexvà __newindex). Sẽ tốt hơn nếu bạn có thể bắt lỗi trong thời gian biên dịch. Có nhiều điều bạn có thể làm để giảm bớt điều này.

Lua rất khuyến khích, chỉ cần sẵn sàng làm việc với nó một chút! Bạn cũng có thể muốn kiểm tra Squirrel , mặc dù tôi tin rằng nó có lượng người dùng nhỏ hơn.

Trên thực tế có 3 ưu điểm lớn:

• Tải thời gian chạy cho phép bạn tải tập lệnh trong khi thực thi ứng dụng.
• Sandboxing https://stackoverflow.com/questions/3400851/execut-time-limit-for-a-lua-script-called-from-the-c-api 43200896 # 3400896
• Tính di động

Các yếu tố này cho phép bạn là nhà phát triển trò chơi kích hoạt các tính năng giúp tăng tốc độ phát triển và tăng chất lượng trò chơi của bạn.

Ví dụ:

• Bạn sẽ có thể thay đổi logic trò chơi của mình chỉ bằng cách cập nhật trò chơi của bạn từ tệp hoặc ổ cắm mạng.
• Bạn có thể cho phép người dùng tạo tập lệnh của riêng họ (cho bot hoặc mod)
• Các nhà thiết kế và nghệ sĩ trò chơi của bạn sẽ có thể cập nhật và kiểm tra các phần của trò chơi mà không phải sử dụng bộ công cụ biên dịch của bạn.
• Bạn sẽ không phải biên dịch lại mỗi khi bạn thay đổi một vài tập lệnh.
• Bạn sẽ không phải viết lại toàn bộ trò chơi nếu bạn thay đổi nền tảng / công cụ / ngôn ngữ.

Từ kinh nghiệm của tôi, đun sôi một chút.

Ưu

• Tích hợp ban đầu thực sự dễ dàng. Các công cụ tồn tại để giúp tạo các liên kết, nhưng cơ chế liên kết đơn giản đến mức bạn có thể viết phiên bản của riêng mình, với các tính năng tùy chỉnh của riêng bạn, ngay lập tức
• Bạn nhận được lặp lại nhanh hơn nhiều trên logic trò chơi (giả sử bạn thực hiện tải lại thời gian chạy)
• Bạn sẽ có một môi trường tự do để thử nghiệm: bạn sẽ thử nhiều thứ hơn vì chi phí để làm như vậy giảm đáng kể
• Cú pháp quen thuộc: đối với tất cả sự khác biệt của nó, bạn sẽ khó có thể trở thành một lập trình viên C không thể thoải mái trong vài giờ
• Phân tách logic trò chơi tốt hơn với "engine": công cụ của bạn trở thành nhà cung cấp dịch vụ phải đưa ra một API tốt cho khách hàng Lua. Rào cản ngôn ngữ khiến bạn suy nghĩ về điều đó nhiều hơn, thay vì chỉ tiếp cận trong đó và thay đổi một biến thành viên

Nhược điểm

• Quản lý bộ nhớ Lua không lý tưởng cho các trò chơi. Bạn đối phó với nó, bạn không thích nó
• Lua gỡ lỗi là khủng khiếp ra khỏi hộp. Bạn sẽ phải làm việc để cải thiện trải nghiệm
• Giữ dữ liệu trong Lua có nghĩa là bạn sẽ cần gỡ lỗi trong Lua: việc kiểm tra dữ liệu từ C ban đầu sẽ rất khó khăn
• Lua có một số lượng lớn bản thân bạn theo cú pháp chân, giống như tất cả các biến là toàn cầu theo mặc định
• Lua là một ngôn ngữ lập trình, giống như bất kỳ ngôn ngữ nào khác. Đừng mong đợi những người không lập trình biến thành lập trình một cách kỳ diệu chỉ vì bạn đã gỡ bỏ trình biên dịch
• Trở nên giỏi trong việc tích hợp và hỗ trợ Lua là một công việc lớn. Đừng mong đợi nó sẽ bật ra khỏi hộp. Thật công bằng khi cho rằng bạn thực sự sẽ phải khấu hao chi phí này qua một vài trò chơi

Cuối cùng, cá nhân, phán quyết: nếu bạn đang xây dựng một trò chơi có kích thước phù hợp và chưa có ngôn ngữ kịch bản, thì hãy lấy Lua. Nó sẽ có giá trị nó.

Garry's Mod là một ví dụ về trò chơi sử dụng Lua và C ++. Họ sử dụng Lua cho tất cả các mod, điều này giúp mọi người dễ dàng thực hiện hơn nhiều. C ++ được sử dụng cho tất cả các bên trong. Điều duy nhất tôi có thể nghĩ đến là Lua không nhanh như C ++.