Các ngôn ngữ lập trình chức năng có phù hợp với lập trình đồ họa không?

Question

Chỉ cần rất tò mò về điều này, từ kinh nghiệm của riêng tôi, tất cả các chương trình đồ họa có vẻ liên quan đến C hoặc C++. Giống như Direct10X. Ngôn ngữ lập trình chức năng có cung cấp một số loại thư viện đồ họa để phát triển trò chơi điện tử không?

Answer 1

Bạn có thể sử dụng các ngôn ngữ chức năng để lập trình đồ họa/trò chơi giống như bất kỳ ngôn ngữ nào khác.

Nó chỉ là một trò chơi đơn giản, nhưng tôi đã viết Ironclad: Steam Legions trong Clojure như một bài tập trong lập trình chức năng để phát triển trò chơi.

Dưới đây là một số bài học tôi đã học/quan sát chung về việc sử dụng Clojure cho lập trình trò chơi:

• Bạn cần phải cẩn thận về hiệu suất như các trò chơi có thể rất khắt khe và các ngôn ngữ chức năng làm áp đặt một số chi phí chung. Clojure chắc chắn là "đủ tốt" cho hầu hết các trò chơi, nhưng bạn cần phải biết các thủ thuật để giữ cho mã của bạn được tối ưu hóa. Ví dụ, ngôn ngữ chức năng có thể nhận được một chút GC-nặng sản xuất rất nhiều đối tượng tạm thời. Bạn cần phải tìm hiểu những thủ thuật để tránh điều này (ví dụ, sử dụng giảm theo một cách mà tránh tạo các đối tượng chuỗi mới, hoặc tận dụng artithmetic nguyên thủy)

• mutability rất hữu ích trong trò chơi. Ví dụ, nếu bạn đang làm bất cứ điều gì với vật lý hoặc hoạt hình trơn tru, bạn thường có rất nhiều đối tượng với vị trí thay đổi liên tục. Bạn có thể mô phỏng điều này với cấu trúc dữ liệu chức năng/không thay đổi nhưng nếu bạn quan tâm đến hiệu suất thì đó không phải là một ý tưởng hay. Do đó nó có giá trị tìm hiểu làm thế nào để có được dữ liệu có thể thay đổi trong ngôn ngữ chức năng của bạn ngay cả khi nó không phải là thành ngữ (ví dụ trong Clojure bạn có thể sẽ muốn tận dụng mảng Java)

• Bất biến cấu trúc dữ liệu dai dẳng thực sự lần lượt ra cũng rất hữu ích trong trò chơi. Trong Ironclad, toàn bộ trạng thái trò chơi được lưu trữ trong một cấu trúc dữ liệu bất biến duy nhất. Điều này cho phép một số thủ thuật thú vị như chụp nhanh hiệu quả trạng thái trò chơi/hoàn tác tức thì/chạy ngược thời gian.

• Clojure là tuyệt vời cho kịch bản trò chơi. Bản chất động cùng với việc biên dịch thời gian chạy và khả năng xác định các DSL tùy ý bằng các macro là một chiến thắng lớn. Trong thực tế, ngay cả khi tôi đang viết một trò chơi bằng ngôn ngữ OOP như Java, tôi sẽ xem xét nghiêm túc việc sử dụng Clojure (hoặc một Lisp khác) để viết kịch bản.

• Clojure là tuyệt vời cho phát triển tương tác. Tôi thường thấy mình chạy trò chơi trong một cửa sổ trong khi hack mã đang chạy trong REPL cùng với. Thật thú vị khi thay đổi cấu trúc dữ liệu trò chơi và ngay lập tức thấy hiệu ứng! This awesome video cũng cung cấp cho bạn một hương vị của những gì có thể với sự phát triển theo phong cách Clojure.

• Trong Clojure ít nhất bạn sẽ thường muốn sử dụng các thư viện Java cho đồ họa, ví dụ: Swing cho 2D hoặc LWJGL cho 3D. Trong một số trường hợp các trình bao bọc cho những thứ này đã tồn tại, tuy nhiên tôi thấy dễ dàng sử dụng chúng trực tiếp từ Clojure.Sau khi tất cả, Java interop cũng đơn giản như (.methodName object arg1 arg2)

Tóm lại, tôi nghĩ rằng ngôn ngữ chức năng là sự lựa chọn hoàn toàn tốt cho sự phát triển trò chơi, với ngoại lệ của trò chơi rất năng chuyên sâu mà bạn vẫn có khả năng được tốt hơn với C/C++ để có quyền kiểm soát trực tiếp hơn phần cứng.

Answer 2

Đây là một chuỗi tốt về chủ đề: (4 phần) Purely Functional Retrogames. Bạn có thể sử dụng phương pháp này trong Clojure và sử dụng các thư viện trò chơi Java bên dưới để thao tác đồ họa.

Answer 3

Có lẽ không ai quan tâm đến câu hỏi này năm tuổi, có lẽ thậm chí không phải là người hỏi ban đầu. Nhưng với tư cách là một anh chàng đồ họa thời gian cũ của Lisp, tôi muốn cân nhắc. Tiêu đề đề cập đến “lập trình đồ họa”, sau đó câu hỏi hỏi về các thư viện để phát triển game. Đáng chú ý là lập trình đồ họa bao gồm nhiều chủ đề không liên quan đến lập trình trò chơi. (Ví dụ, việc trực quan hóa dữ liệu trong Clojure sẽ là một ví dụ về "ngôn ngữ lập trình chức năng thích hợp cho lập trình đồ họa" nhưng không phải là lập trình game.) Ngoài ra còn có sự khác biệt giữa các ngôn ngữ dựa trên chức năng (như Lisp). các hiệu ứng phụ được cho phép) và các ngôn ngữ hoàn toàn có chức năng với các kiểu dữ liệu không thay đổi (như Haskell hoặc Clojure).

Chắc chắn có hệ thống đồ họa dựa trên Lisp được viết theo kiểu "đa mô hình", nghĩa là, không hoàn toàn là chức năng/không thay đổi. Ví dụ, tôi đã làm việc tại Symbolics vào đầu những năm 1980, khi chúng tôi sản xuất một trong những hệ thống “tạo nội dung số” đầu tiên (như Maya hoặc AutoCAD) hoàn toàn trong Lisp. Luận án MS năm 1978 của tôi là về một ngôn ngữ dựa trên Lisp-specific-langauge cho hoạt ảnh thủ tục được gọi là ASAS. Chúng tôi đã sử dụng điều đó ở công ty 3-I (Information International Inc.) để thực hiện công việc CGI rất sớm cho các hiệu ứng đặc biệt trong phim truyện, bao gồm cả TRON của năm 1982. Cuối cùng, studio trò chơi Naughty Dog đã lập trình logic trò chơi của một số chức danh (Crash Bandicoot, Jak và Daxter series) với một ngôn ngữ được lấy cảm hứng từ Scheme gọi là Game Oriented Assembly Lisp (GOAL).

Phát biểu về những nỗ lực hiện đại hơn, và nghiêm chỉnh thêm chức năng/ngôn ngữ bất biến: “LambdaCube 3D là Haskell giống như hoàn toàn chức năng miền ngôn ngữ cụ thể cho các lập trình (đơn vị xử lý đồ họa) GPU.”

Trong bài phát biểu của John Carmack tại Quakecon 2013, ông đã nói rộng rãi (khoảng 30 phút) về sở thích và thử nghiệm của mình với các ngôn ngữ thuần túy để phát triển trò chơi. Quan điểm của ông dường như là có những lợi ích rõ ràng khi sử dụng lập trình chức năng, nhưng có một số thách thức, và rằng ông đã không đi đủ xa xuống con đường đó để có một ý kiến ​​mạnh mẽ. Ông nói về thử nghiệm với cả Haskell và Lisp. Chủ đề này là từ 1: 17: 00-1: 49: 00 trong số video này.