Mengembangkan game di Go? [Tutup]

40

Bahasa Google baru Go masih dalam tahap awal, dan belum menemukan penggunaan atau dukungan dunia nyata yang meluas. Meski begitu, sepertinya ini adalah eksperimen yang menjanjikan, dan saya ingin tahu apakah ini bisa memiliki masa depan dalam pengembangan game. Saya belum dapat menemukan banyak diskusi khusus game tentang Go di tempat lain, dan berpendapat bahwa diskusi CW mungkin tepat.

Beberapa pemikiran:

  • Menurut golang.org , program Go "berjalan hampir secepat kode C atau C ++ yang sebanding" - cukup cepat?
  • Apakah pengumpulan sampah Go cocok untuk game?
  • Berapa banyak mental re-tooling yang diperlukan untuk membuat game di tanah goroutine bersamaan?
  • Go sering disebut bahasa tingkat "sistem", dengan perangkat lunak server yang diberikan sebagai contoh. Sulit untuk tidak memikirkan server permainan multi-pemain saat mendengar ini.

Pikiran Anda?

go TSomKes
sumber
1
Saya akan menyarankan siapa pun yang tidak terbiasa dengan GO untuk benar-benar mengikuti tautan sebelum menjawab sebagai lawan hanya menanggapi berdasarkan "pemikiran" yang diberikan yang mengatakan jika jawaban Anda bersifat umum dan tidak spesifik untuk bahasa ini maka saya rasa itu tidak masalah
lathomas64
1
Saya ingin tahu apakah Anda dapat membuat game dalam permainan (game): P
RCIX
4
Tidak yakin apakah ' Go ' dianggap berbelok lengkap (sekali lagi itu dioperasikan manusia). Tetapi ruang penyimpanan sangat terbatas (setidaknya jika menggunakan papan peraturan).
David C. Bishop
@ DavidC.Bishop Lucu ...
Brian Ortiz
1
Jika Anda membuat mesin permainan go Anda harus memastikan Anda mengambil keuntungan dari apa yang bisa dilakukan oleh bahasa itu, alih-alih mencoba menggunakannya dengan cara yang sama Anda lakukan dengan bahasa yang lebih "konvensional" dan menyalin apa yang sudah ada.

Jawaban:

34

Saya menerima pertanyaan Anda:

  • Bahasanya cukup cepat. Bahasa Jawa yang lebih lambat digunakan untuk pengembangan game. Bahkan Python (pygame) digunakan untuk pengembangan game, dan secara signifikan lebih lambat dari Java. Itu semua tergantung pada jenis permainan dan seberapa intensif prosesor itu.
  • Pengumpulan sampah secara umum tidak baik untuk permainan. Namun, Go memiliki sistem pengumpulan sampah yang sangat buruk (mark-and-sweep) yang menghentikan dunia saat membersihkan barang-barang. Akan sulit untuk mengatasinya dan akan menyebabkan framerate berhenti-dan-pergi.
  • Diperlukan perbaikan mental yang memadai untuk membuat game dengan goroutine. Grafik dan logika tidak bisa bersamaan dalam arti tradisional; tetapi pada tingkat yang lebih kecil, bagian dari logika adalah kandidat yang bagus untuk goroutine bersamaan (misalnya pemrosesan paralel dari keputusan AI, sistem partikel, dll.)
  • Server permainan multi-pemain memang bisa menjadi kandidat yang bagus untuk bahasa Go.

Menurut pendapat saya, jika Anda memiliki keinginan yang cukup kuat untuk mencoba menulis game dengan bahasa, lakukanlah. Jelas jika Anda mempertimbangkannya maka Anda memiliki hasrat untuk melakukannya, dan mengapa tidak mengikuti hasrat itu alih-alih memaksa diri Anda untuk menyesuaikan diri dengan norma? Saya bisa mengatakan lebih banyak tetapi saya sudah mengatakan banyak dalam jawaban saya pertanyaan, "Apakah Ruby bahasa yang cocok untuk pengembangan game?"

Ricket
sumber
6
"sistem pengumpulan sampah yang sangat buruk (mark-and-sweep)" mark-and-sweep tidak secara inheren menghentikan dunia - Jawa memiliki kolektor tanda-dan-sapuan bersamaan, dan Lua menggunakan naif untuk waktu yang lama. - dan banyak panjang jeda dapat dikontrol melalui sistem generasi yang hati-hati. Yang sedang berkata, Go's adalah stop-the-world mark and and sweep. Tapi yang pertama, bukan yang terakhir, adalah masalah untuk game. (Utas Ruby memiliki beberapa klaim aneh tentang ini juga.)
1
Sistem Go GC saat ini tampaknya menjadi semacam placeholder: "Implementasi saat ini adalah kolektor tanda-dan-sapu polos tetapi penggantinya sedang dalam pengerjaan" ( golang.org/doc/go_lang_faq.html#garbage_collection ). Opsi penggantian telah dibahas; Saya tidak mengetahui adanya keputusan tegas tentang masalah ini.
TSomKes
1
Joe, terima kasih sudah menjelaskan! Saya tidak menyadarinya. Dan ya TSomKes, saya memang melihat itu, jadi kita bisa terus berharap bahwa Go akan menerapkan pengumpul sampah yang lebih baik di beberapa titik.
Ricket
4
Perhatikan bahwa jawaban di atas ketinggalan zaman ketika menyangkut pengumpul sampah Go saat ini. Ini adalah permainan bola yang sepenuhnya berbeda dengan Go 1.5. Saya bertanya-tanya seberapa besar kekhawatiran ini.
Jonas
3
Dan tampaknya dengan go 1.8, GC akan dikurangi menjadi 100μs dari stop-the-world bersamaan. groups.google.com/forum/#!topic/golang-dev/Ab1sFeoZg_8
Dolanor
17

Saya telah menulis mesin kecil di Go for OSX (menggunakan OpenGl untuk jendela grafis). Saya memiliki pengalaman dengan mesin game C ++ ( http://morganjeff.weebly.com/ ) dan memutuskan untuk mencoba Go setelah membaca tentang beberapa fitur yang ditawarkannya.

Pada rilis Go 1.1 go memiliki dukungan untuk sebagian besar fitur yang saya butuhkan untuk menulis mesin gim (benar-benar inti gim sebagai mesin yang menyarankan editor dan yang tidak) termasuk:

  • Penjilidan fungsi anggota (untuk sistem pengiriman pesan)
  • Refleksi sudah terpasang (berguna untuk serialisasi, dukungan alat eksternal, dll)
  • Antarmuka (untuk menerapkan perilaku polimorfik untuk sistem, komponen, dll)

Beberapa manfaat menggunakan Go (untuk proyek besar):

  • Pengujian dibangun ke dalam bahasa (ini termasuk tes benchmark dan beberapa pernyataan)
  • Contoh mudah ditambahkan ke bahasa (dan dikompilasi untuk kebenaran)
  • Kode spesifik arsitektur mudah ditambahkan (melalui konvensi penamaan file)
  • Profil dibuat untuk bahasa
  • versi bawaan impor (memungkinkan untuk menambahkan binari besar ke repositori terpisah dari sumber, sambil tetap versi dan mutakhir)

Beberapa manfaat menggunakan Go secara umum:

  • Kode refactor mudah
  • Go mendukung threading (tidak seperti C ++ yang melapisinya di atas)
  • kecepatan kompilasi super cepat mengurangi kebutuhan akan dukungan bahasa scripting
  • sistem pengetikan statis (antarmuka dipenuhi melalui pengetikan bebek alias secara implisit)
  • beberapa nilai balik, parameter bernama, atribut struct yang ditandai
  • alat dan dokumentasi bawaan yang hebat
  • bahasa yang dikelola

Beberapa kerugian menggunakan Go:

  • Tidak ada makro atau template
  • Tidak memiliki dukungan perpustakaan untuk bahasa yang lebih matang
  • bahasa yang dikelola (terdaftar dua kali dengan sengaja)
  • TIDAK ADA IDE

Ada beberapa cara untuk mendapatkan memori mentah (impor "tidak aman") dan saya akan menautkan artikel yang menunjukkan bagaimana program go dapat diprofilkan untuk memori dan kecepatan. Semua dalam semua, klaim Go bahwa itu adalah C modern tampaknya sangat benar. Saya pikir itu "cerdas" dirancang (untuk banyak alasan daripada yang saya sebutkan) dan, yang lebih penting, itu didokumentasikan dengan baik. Mesin yang dirancang di Go akan sedikit berbeda dari mesin yang dirancang di C ++ (sesuatu yang saya masih terbiasa), tetapi mesin Go memecahkan banyak masalah yang tidak benar-benar diselesaikan di C ++ (yaitu paralelisme, kompleksitas bahasa C ++, dan penyalahgunaan pewarisan).

Inilah artikel yang saya janjikan: http://blog.golang.org/2011/06/profiling-go-programs.html

-Jeff

jmorgan
sumber
coba Sublime dengan GoSublime, itu benar-benar terasa seperti IDE, dan itu jauh lebih reaktif daripada banyak (jika tidak semua) IDE untuk Java.
Arne
1
Anda dapat menentukan apa yang Anda maksud dengan "versi bawaan impor", saya hanya kagum dengan tag versi bahasa go itu sendiri.
Arne
@jmorgan ada perubahan perspektif sejak Go 1.2 dan melihat Go 1.3 perubahan yang akan datang?
menerima
@ Andre: Panggilan bagus! Saya sangat suka GoSublime, banyak. Apa yang saya maksudkan tanpa IDE adalah bahwa untuk mendapatkan debugger visual Anda harus menggunakan gogdb (yang merupakan alat yang hebat), tetapi itu tidak sebagus visual studio. Inilah yang saya maksud tentang dependensi dan pembuatan versi paket: golang.org/cmd/go/… golang.org/cmd/go/#hdr-Import_path_syntax
jmorgan
@iluminate: Jujur saya pikir Go semakin baik. Sekarang hadir dengan paket cakupan pengujian, sehingga Anda dapat dengan cepat melihat apa yang diuji dan apa yang tidak. Saya telah menemukan bahwa memiliki test suite yang layak di tempat membuat hidup saya jauh lebih mudah ... jadi ini adalah fitur besar bagi saya Go 1.3 sepertinya akan ada peningkatan ukuran biner dan kecepatan runtime (khususnya pengumpul sampah), jadi itu hebat.
jmorgan
4

Hal lain yang perlu dipikirkan adalah karena Go masih relatif baru, mungkin belum ada binding untuk banyak perpustakaan umum yang digunakan dalam pengembangan game.

Bob Somers
sumber
Yang pasti terjadi. Sebagai contoh, saya telah menemukan dua proyek Go / SDL, salah satunya tampaknya telah ditinggalkan. Saya telah menemukan beberapa game (relatif kecil) yang menggunakan salah satunya.
TSomKes
1
Anda pasti harus memeriksa github.com/go-gl itu bukan SDL tetapi alternatif yang baik jika Anda menggunakan OpenGl. Untuk vektor ada github.com/Jragonmiris/mathgl , tapi saya menemukan bug di sana. Go membuat sangat mudah untuk membungkus pustaka C, tidak perlu membuat file sama sekali. Anda juga dapat mengimpor file header C dan menggunakan fungsinya secara langsung.
Arne
0

Jangan gunakan Go untuk mengembangkan game, itu hanya akan menjadi elang laut di leher Anda. Toolchain untuk pengembangan game meluas jauh lebih dalam dari sekedar bahasa yang Anda tuliskan sehingga Anda akan menemukan hambatan di setiap kesempatan yang tidak akan ada jika Anda hanya pergi dengan sesuatu yang sudah mapan.

Jangan salah paham, saya suka bermain dengan bahasa baru, tetapi jika Anda mencoba membuat game memilih bahasa yang memiliki komunitas dan dukungan dan Anda akan jauh lebih baik.

Aaron Brady
sumber
9
Di sisi lain, jika Anda hanya akan melakukan hardcode pada proyek indie kecil untuk bermain dengan bahasa baru, mengkhawatirkan "toolchain" terlalu dibesar-besarkan.
2
Saya harus tidak setuju di sini. Sebagian besar hal yang terkait dengan pengembangan game tidak ada hubungannya dengan bahasa. Mengajukan pertanyaan tentang OpenGL tidak ada hubungannya dengan cuaca yang Anda programkan di C C ++ Go atau bahkan Java. Dan omong-omong, toolchain apa yang Anda bicarakan? Dan mengapa itu tidak cocok untuk pergi?
Arne