Phát triển game trong Go? [đóng cửa]


40

Ngôn ngữ Go mới của Google vẫn còn ở giai đoạn sơ khai và vẫn chưa tìm thấy sự hỗ trợ hoặc sử dụng rộng rãi trong thế giới thực. Mặc dù vậy, nó có vẻ như là một thử nghiệm đầy hứa hẹn và tôi tự hỏi liệu nó có thể có tương lai trong phát triển trò chơi hay không. Tôi chưa thể tìm thấy nhiều cuộc thảo luận cụ thể về trò chơi về Đi nơi khác và hình dung một cuộc thảo luận CW có thể phù hợp.

Một vài suy nghĩ:

  • Theo golang.org , các chương trình Go "chạy gần như nhanh như mã C hoặc C ++ tương đương" - đủ nhanh?
  • Bộ sưu tập rác của Go có phù hợp với các trò chơi không?
  • Cần bao nhiêu công cụ tái tạo tinh thần để tạo ra các trò chơi trong vùng đất của những con khỉ đột đồng thời?
  • Go thường được gọi là ngôn ngữ "hệ thống", với phần mềm máy chủ được đưa ra làm ví dụ. Thật khó để không nghĩ đến các máy chủ trò chơi nhiều người chơi khi nghe điều này.

Suy nghĩ của bạn?


1
Tôi sẽ khuyên bất cứ ai không quen thuộc với GO thực sự theo liên kết trước khi trả lời thay vì chỉ trả lời dựa trên "những suy nghĩ" đã nói nếu câu trả lời của bạn chung chung và không cụ thể với ngôn ngữ này thì tôi đoán nó không thành vấn đề
lathomas64

1
Tôi tự hỏi nếu bạn có thể tạo trò chơi trong trò chơi (trò chơi): P
RCIX

4
Không chắc chắn nếu ' Go ' được coi là hoàn thành (sau đó lại là do con người vận hành). Nhưng không gian lưu trữ rất hạn chế (ít nhất là nếu sử dụng bảng quy định).
David C. Giám mục

@ DavidC.Bishop Hài hước ...
Brian Ortiz

1
Nếu bạn tạo một công cụ trò chơi cờ vây, bạn nên đảm bảo rằng bạn tận dụng những gì ngôn ngữ có thể làm, thay vì cố gắng sử dụng nó giống như cách bạn làm với ngôn ngữ "thông thường" hơn và sao chép những gì đã tồn tại.

Câu trả lời:


34

Tôi đưa ra câu hỏi của bạn:

  • Ngôn ngữ là rất nhiều đủ nhanh chóng. Ngôn ngữ Java chậm hơn được sử dụng để phát triển trò chơi. Ngay cả Python (pygame) cũng được sử dụng để phát triển trò chơi và nó chậm hơn đáng kể so với Java. Tất cả phụ thuộc vào loại trò chơi và mức độ xử lý của nó.
  • Bộ sưu tập rác nói chung không tốt cho trò chơi. Tuy nhiên, Go có một hệ thống thu gom rác đặc biệt tồi tệ (đánh dấu và quét) ngăn chặn thế giới trong khi nó dọn dẹp mọi thứ. Sẽ rất khó để đối phó và sẽ gây ra một cái gì đó của tốc độ khung hình dừng lại.
  • Một số lượng khá lớn của việc trang bị lại tinh thần là cần thiết để tạo ra các trò chơi với khỉ đột. Đồ họa và logic không thể đồng thời theo nghĩa truyền thống; nhưng ở cấp độ nhỏ hơn, các phần của logic là ứng cử viên tuyệt vời cho các con khỉ đột đồng thời (ví dụ: xử lý song song các quyết định AI, hệ thống hạt, v.v.)
  • Một máy chủ trò chơi nhiều người chơi thực sự có thể là một ứng cử viên tuyệt vời cho ngôn ngữ Go.

Theo ý kiến ​​của tôi, nếu bạn có một sự thôi thúc đủ mạnh mẽ để thử viết trò chơi bằng một ngôn ngữ, hãy thực hiện nó. Rõ ràng nếu bạn đang xem xét nó thì bạn có một đam mê để làm như vậy, và tại sao không theo đuổi đam mê đó thay vì buộc bản thân phải tuân theo quy tắc? Tôi có thể nói nhiều hơn nữa nhưng tôi đã nói rất nhiều trong câu trả lời của mình, "Ruby có phải là ngôn ngữ phù hợp để phát triển trò chơi không?"


6
"một hệ thống thu gom rác đặc biệt xấu (đánh dấu và quét)" vốn dĩ không ngăn chặn thế giới - Java có một trình thu thập đánh dấu và quét đồng thời, và Lua đã sử dụng một công cụ ngây thơ trong một thời gian dài - và rất nhiều độ dài của tạm dừng có thể được kiểm soát thông qua một hệ thống thế hệ cẩn thận. Điều đó đang được nói, Go điểm dừng chân của thế giới. Nhưng cái trước, không phải cái sau, là vấn đề cho các trò chơi. (Chủ đề Ruby cũng có một số tuyên bố kỳ lạ về điều này.)

1
Hệ thống Go GC hiện tại dường như là một thứ gì đó của một trình giữ chỗ: "Việc triển khai hiện tại là một trình thu thập đánh dấu và quét đơn giản nhưng một sự thay thế đang hoạt động" ( golang.org/doc/go_lang_faq.html#garbage_collection ). Các lựa chọn thay thế đã được thảo luận; Tôi không biết về bất kỳ quyết định vững chắc nào về vấn đề này.
TSomKes

1
Joe, cảm ơn vì đã làm rõ! Tôi đã không nhận thức được điều đó. Và vâng TSomKes, tôi đã thấy điều đó, vì vậy chúng tôi có thể giữ hy vọng rằng Go sẽ thực hiện một trình thu gom rác tốt hơn vào một lúc nào đó.
Ricket

4
Lưu ý rằng câu trả lời trên đã hết hạn khi nói đến trình thu gom rác Go hiện tại. Đây là một trò chơi bóng hoàn toàn khác với Go 1.5. Tôi tự hỏi bao nhiêu mối quan tâm này vẫn còn.
Jonas

3
Và dường như với phiên bản 1.8, GC sẽ được giảm xuống còn 100s đồng thời dừng lại trên thế giới. Groups.google.com/forum/#!topic/golang-dev/Ab1sFeoZg_8
Dolanor

17

Tôi đã viết một công cụ nhỏ trong Go cho OSX (sử dụng OpenGl cho cửa sổ đồ họa). Tôi có một số kinh nghiệm với các công cụ trò chơi C ++ ( http://morganjeff.weebly.com/ ) và quyết định dùng thử Go sau khi đọc về một số tính năng mà nó cung cấp.

Kể từ phiên bản Go 1.1, hỗ trợ cho hầu hết các tính năng tôi cần để viết một công cụ trò chơi (thực sự là một lõi trò chơi như một công cụ gợi ý các biên tập viên và những gì không) bao gồm:

  • Ràng buộc chức năng thành viên (đối với hệ thống nhắn tin)
  • Reflection được tích hợp sẵn (hữu ích cho việc tuần tự hóa, hỗ trợ công cụ bên ngoài, v.v.)
  • Các giao diện (để thực hiện hành vi đa hình cho các hệ thống, thành phần, v.v.)

Một số lợi ích khi sử dụng Go (cho một dự án lớn):

  • Kiểm tra được tích hợp vào ngôn ngữ (bao gồm kiểm tra điểm chuẩn và một số xác nhận)
  • Các ví dụ rất dễ thêm vào ngôn ngữ (và chúng được biên dịch cho chính xác)
  • Mã cụ thể của kiến ​​trúc rất dễ thêm (thông qua các quy ước đặt tên tệp)
  • Hồ sơ được xây dựng theo ngôn ngữ
  • phiên bản nhập sẵn tích hợp (cho phép thêm các tệp nhị phân lớn vào kho lưu trữ riêng biệt từ nguồn, trong khi vẫn giữ phiên bản và cập nhật)

Một số lợi ích của việc sử dụng Go nói chung:

  • Dễ dàng cấu trúc lại mã
  • Go hỗ trợ phân luồng (không giống như C ++ xếp lớp trên cùng)
  • tốc độ biên dịch siêu nhanh làm giảm nhu cầu hỗ trợ ngôn ngữ kịch bản
  • hệ thống gõ tĩnh (giao diện được thỏa mãn thông qua gõ vịt hay còn gọi là ngầm)
  • nhiều giá trị trả về, tham số được đặt tên, thuộc tính struct được gắn thẻ
  • công cụ và tài liệu tích hợp tuyệt vời
  • ngôn ngữ được quản lý

Một số nhược điểm của việc sử dụng Go:

  • Không có macro hoặc mẫu
  • Không có thư viện hỗ trợ các ngôn ngữ trưởng thành hơn
  • ngôn ngữ được quản lý (được liệt kê hai lần trên mục đích)
  • KHÔNG CÓ IDE

Có nhiều cách để có được bộ nhớ thô (nhập "không an toàn") và tôi sẽ liên kết một bài viết cho thấy cách chương trình đi có thể được định hình cho bộ nhớ và tốc độ. Nói chung, Go cho rằng đó là một chữ C hiện đại có vẻ rất đúng. Tôi nghĩ rằng nó được thiết kế "thông minh" (vì nhiều lý do hơn tôi đã đề cập) và quan trọng hơn, nó được ghi chép lại. Một công cụ được thiết kế trong Go sẽ khác một chút so với một công cụ được thiết kế trong C ++ (một thứ tôi vẫn đang làm quen), nhưng công cụ Go giải quyết được rất nhiều vấn đề chưa thực sự được giải quyết trong C ++ (cụ thể là song song, sự phức tạp của ngôn ngữ C ++ và việc sử dụng sai tính kế thừa).

Đây là bài viết tôi đã hứa: http://blog.golang.org/2011/06/profiling-go-programs.html

-Jeff


hãy dùng thử Sublime với GoSublime, nó thực sự giống như một IDE và nó phản ứng mạnh hơn nhiều so với nhiều IDE (nếu không phải tất cả) cho Java.
Arne

1
bạn có thể chỉ định ý của bạn bằng cách "phiên bản nhập khẩu tích hợp" không, tôi chỉ nhận ra thẻ phiên bản của ngôn ngữ cờ vây.
Arne

@jmorgan có thay đổi quan điểm nào kể từ Go 1.2 và xem Go 1.3 thay đổi sắp tới không?
ylluminate

@Arne: Gọi tốt! Tôi thực sự thích GoSublime, rất nhiều. Điều tôi muốn nói không có IDE là để có được trình gỡ lỗi trực quan, bạn phải sử dụng gogdb (một công cụ tuyệt vời), nhưng nó không đẹp như studio hình ảnh. Đây là những gì tôi muốn nói về gói phụ thuộc và versioning: golang.org/cmd/go/... golang.org/cmd/go/#hdr-Import_path_syntax
jmorgan

@ylluminate: Tôi thành thật nghĩ rằng Go đang ngày càng tốt hơn. Bây giờ nó đi kèm với một gói bảo hiểm thử nghiệm, vì vậy bạn có thể nhanh chóng xem những gì đã thử nghiệm và những gì không. Tôi đã thấy rằng có một bộ kiểm tra đàng hoàng tại chỗ giúp cuộc sống của tôi dễ dàng hơn rất nhiều ... vì vậy đây là một tính năng lớn đối với tôi. Go 1.3 có vẻ như sẽ có những cải tiến về kích thước nhị phân và tốc độ thời gian chạy (cụ thể là trình thu gom rác), vì vậy điều đó thật tuyệt.
jmorgan

4

Một điều khác để suy nghĩ là vì Go vẫn còn tương đối mới, có thể không có ràng buộc cho rất nhiều thư viện phổ biến được sử dụng trong phát triển trò chơi.


Chắc chắn là như vậy. Ví dụ: tôi đã bắt gặp hai dự án Go / SDL, một trong số đó dường như đã bị bỏ rơi. Tôi đã tìm thấy một số ít các trò chơi (tương đối nhỏ) sử dụng một trong số chúng.
TSomKes

1
Bạn chắc chắn nên kiểm tra github.com/go-gl không phải SDL mà là một lựa chọn tốt nếu bạn sử dụng OpenGl. Đối với các vectơ có github.com/Jragonmiris/mathgl , nhưng tôi đã tìm thấy lỗi ở đó. Go make rất dễ dàng để bọc thư viện C, không cần makefiles. Bạn cũng có thể nhập tệp tiêu đề C và sử dụng trực tiếp chức năng của chúng.
Arne

0

Không sử dụng Go để phát triển một trò chơi, nó sẽ chỉ là một con hải âu quanh cổ bạn. Chuỗi công cụ để phát triển trò chơi mở rộng sâu sắc hơn nhiều so với ngôn ngữ mà bạn viết những thứ mà bạn sẽ tìm thấy chướng ngại vật ở mỗi lượt mà sẽ không có ở đó nếu bạn chỉ đi với thứ gì đó được thiết lập.

Đừng hiểu lầm tôi, tôi thích chơi với các ngôn ngữ mới, nhưng nếu bạn đang cố gắng làm cho các trò chơi chọn một ngôn ngữ có cộng đồng và hỗ trợ và bạn sẽ tốt hơn nhiều.


9
Mặt khác, nếu bạn chỉ định sử dụng công cụ mã hóa cứng trong một dự án độc lập nhỏ để chơi với một ngôn ngữ mới, thì việc lo lắng về "chuỗi công cụ" sẽ bị đánh giá quá cao.

2
Tôi phải phản đối ở điểm này. Hầu hết những thứ liên quan đến phát triển trò chơi không liên quan gì đến ngôn ngữ. Đặt câu hỏi về OpenGL không có gì để làm thời tiết bạn lập trình trong C C ++ Go hoặc thậm chí Java. Và bằng cách nào bạn đang nói về toolchain? Và tại sao nó không tương thích để đi?
Arne
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.