การพัฒนาเกมใน Go? [ปิด]

40

ภาษา Go ใหม่ของ Google ยังอยู่ในช่วงเริ่มต้นและยังไม่พบการใช้งานจริงหรือการสนับสนุนอย่างแพร่หลาย ถึงกระนั้นดูเหมือนว่าเป็นการทดลองที่มีแนวโน้มและฉันสงสัยว่ามันจะมีอนาคตในการพัฒนาเกมหรือไม่ ฉันไม่สามารถค้นหาการสนทนาเฉพาะของเกมที่อื่นได้มากและคิดว่าการสนทนา CW อาจเหมาะสม

ความคิดบางอย่าง:

ตามgolang.orgโปรแกรม Go "ทำงานเกือบเร็วเท่ากับรหัส C หรือ C ++" - เร็วพอใช่ไหม
การรวบรวมขยะของ Go นั้นเหมาะสมกับเกมหรือไม่
จำเป็นต้องมีเครื่องมือทางจิตใหม่เพื่อสร้างเกมในดินแดนแห่ง goroutines พร้อมกันหรือไม่
บ่อยครั้งที่เรียกว่า "ระบบ" - ภาษาระดับกับซอฟต์แวร์เซิร์ฟเวอร์ให้เป็นตัวอย่าง เป็นการยากที่จะไม่นึกถึงเซิร์ฟเวอร์เกมที่มีผู้เล่นหลายคนเมื่อได้ยินสิ่งนี้

ความคิดของคุณ?

go

— TSomKes
แหล่งที่มา

1

ผมจะแนะนำให้ทุกคนที่ไม่คุ้นเคยกับ GO จริงตามลิงค์ก่อนที่จะตอบเมื่อเทียบกับเพียงการตอบสนองบนพื้นฐานของการให้ "ความคิด" ที่ถูกกล่าวว่าถ้าคำตอบของคุณคือทั่วไปและไม่เฉพาะภาษานี้แล้วผมคิดว่ามันไม่สำคัญ

— lathomas64

1

ฉันสงสัยว่าคุณสามารถสร้างเกมได้หรือไม่ (เกม): P

— RCIX

4

ถ้าไม่แน่ใจว่า ' ไป ' ถือว่าเปลี่ยนฉบับสมบูรณ์ (แล้วอีกครั้งมันมนุษย์ดำเนินการ) แต่พื้นที่เก็บข้อมูลมี จำกัด มาก (อย่างน้อยถ้าใช้บอร์ดควบคุม)

— ดาวิดซี. บิชอป

@ DavidC.Bishop ตลก ...

— Brian Ortiz

1

หากคุณสร้างเอ็นจิ้นเกมแบบพกพาคุณควรตรวจสอบให้แน่ใจว่าคุณได้ใช้ประโยชน์จากภาษาที่สามารถทำได้แทนที่จะพยายามใช้มันในลักษณะเดียวกับที่คุณใช้ด้วยภาษา "ธรรมดา" มากกว่าเดิมและคัดลอกสิ่งที่มีอยู่แล้ว

34

ฉันใช้เวลากับคำถามของคุณ:

ภาษามีความรวดเร็วเพียงพอ ภาษาจาวาช้าลงใช้สำหรับการพัฒนาเกม แม้แต่ Python (pygame) ใช้สำหรับการพัฒนาเกมและมันช้ากว่า Java อย่างมาก ทุกอย่างขึ้นอยู่กับประเภทของเกมและความเข้มข้นของโปรเซสเซอร์
การรวบรวมขยะโดยทั่วไปนั้นไม่ค่อยดีสำหรับเกม อย่างไรก็ตาม Go มีระบบเก็บขยะที่ไม่ดีเป็นพิเศษ (ทำเครื่องหมายและกวาด) ซึ่งหยุดโลกในขณะที่ล้างสิ่งต่างๆ มันจะยากที่จะรับมือกับและจะทำให้บางสิ่งบางอย่างของ framerate หยุดและไป
จำเป็นต้องมีการปรับแต่งจิตใจในปริมาณที่เหมาะสมเพื่อสร้างเกมที่มี goroutines กราฟิกและตรรกะไม่สามารถเกิดขึ้นพร้อมกันในความหมายดั้งเดิม แต่ในระดับที่น้อยกว่าบางส่วนของตรรกะเป็นตัวเลือกที่ยอดเยี่ยมสำหรับ goroutines ที่เกิดขึ้นพร้อมกัน (เช่นการประมวลผลแบบขนานของการตัดสินใจของ AI, ระบบอนุภาค, ฯลฯ )
เซิร์ฟเวอร์เกมแบบผู้เล่นหลายคนอาจเป็นตัวเลือกที่ยอดเยี่ยมสำหรับภาษา Go

ในความคิดของฉันถ้าคุณมีแรงกระตุ้นพอที่จะลองเขียนเกมด้วยภาษา เห็นได้ชัดว่าหากคุณกำลังพิจารณาแล้วคุณมีความปรารถนาที่จะทำเช่นนั้นและทำไมไม่ปฏิบัติตามความหลงใหลนั้นแทนที่จะบังคับให้คุณปฏิบัติตามบรรทัดฐาน? ฉันสามารถพูดได้มากกว่านี้ แต่ฉันได้ตอบคำถามมากมายไปแล้วว่า "ทับทิมเป็นภาษาที่เหมาะสมสำหรับการพัฒนาเกมหรือไม่"

— Ricket
แหล่งที่มา

6

"ระบบรวบรวมขยะที่ไม่ดีโดยเฉพาะ (เครื่องหมายและกวาด)" เครื่องหมายและกวาดไม่หยุดโลกโดยเนื้อแท้ - Java มีตัวสะสมเครื่องหมายและกวาดพร้อมกันและ Lua ใช้ไร้เดียงสาเป็นเวลานาน - และความยาวของการหยุดชั่วคราวจำนวนมากสามารถควบคุมได้ผ่านระบบการกำเนิดอย่างระมัดระวัง ที่ถูกกล่าวว่าไปเป็นเครื่องหมายหยุดและกวาดโลก แต่อดีตไม่ใช่หลังเป็นปัญหาสำหรับเกม (เธรด Ruby มีการเรียกร้องแปลก ๆ เกี่ยวกับเรื่องนี้เช่นกัน)

1

ระบบ Go GC ในปัจจุบันดูเหมือนจะเป็นตัวยึดตำแหน่ง: "การใช้งานปัจจุบันเป็นตัวรวบรวมเครื่องหมายและกวาดแบบธรรมดา แต่การแทนที่อยู่ในผลงาน" ( golang.org/doc/go_lang_faq.html#garbage_collection ) ตัวเลือกการเปลี่ยนได้รับการกล่าวถึง; ฉันไม่ได้ตระหนักถึงการตัดสินใจของ บริษัท ในเรื่องนี้

— TSomKes

1

โจขอบคุณสำหรับการชี้แจง! ฉันไม่ทราบว่า และใช่ TSomKes ฉันเห็นว่าดังนั้นเราจึงสามารถรักษาความหวังของเราไว้ได้ว่าโกจะดำเนินการเก็บขยะที่ดีขึ้นในบางจุด

— Ricket

4

โปรดทราบว่าคำตอบข้างต้นล้าสมัยเมื่อพูดถึงตัวรวบรวมขยะในปัจจุบัน มันเป็นเกมบอลที่แตกต่างกับ Go 1.5 ฉันสงสัยว่าความกังวลนี้ยังคงอยู่เท่าไหร่

— Jonas

3

และดูเหมือนว่าเมื่อใช้ 1.8 การ GC จะลดลงเป็น100μsของการหยุดโลกพร้อมกัน groups.google.com/forum/#!topic/golang-dev/Ab1sFeoZg_8

— Dolanor

17

ฉันเขียนเอนจิ้นเล็ก ๆ ใน Go for OSX (โดยใช้ OpenGl สำหรับหน้าต่างกราฟิก) ฉันมีประสบการณ์เกี่ยวกับเอ็นจิ้นเกม C ++ ( http://morganjeff.weebly.com/ ) และตัดสินใจลองใช้ Go หลังจากอ่านเกี่ยวกับฟีเจอร์บางอย่างที่มีให้

ในฐานะที่เป็นของ Go 1.1 ปล่อยไปได้รับการสนับสนุนสำหรับคุณสมบัติส่วนใหญ่ที่ฉันต้องการในการเขียนโปรแกรมเกม (จริงๆแกนเกมเป็นเครื่องมือที่แนะนำบรรณาธิการและสิ่งที่ไม่ได้) รวมถึง:

การผูกฟังก์ชันของสมาชิก (สำหรับระบบการส่งข้อความ)
Reflection มีอยู่แล้วภายใน (มีประโยชน์สำหรับการทำให้เป็นอนุกรมการสนับสนุนเครื่องมือภายนอก ฯลฯ )
อินเทอร์เฟซ (สำหรับการนำพฤติกรรม polymorphic ไปใช้กับระบบส่วนประกอบ ฯลฯ )

ประโยชน์บางประการของการใช้งาน Go (สำหรับโครงการขนาดใหญ่):

การทดสอบสร้างขึ้นในภาษา (ซึ่งรวมถึงการทดสอบเกณฑ์มาตรฐานและการยืนยันบางส่วน)
ตัวอย่างง่ายต่อการเพิ่มภาษา (และพวกเขาจะรวบรวมเพื่อความถูกต้อง)
โค้ดเฉพาะสถาปัตยกรรมนั้นง่ายต่อการเพิ่ม (ผ่านการตั้งชื่อไฟล์)
การสร้างโปรไฟล์สร้างขึ้นเป็นภาษา
การกำหนดเวอร์ชันการนำเข้าในตัว (อนุญาตให้เพิ่มไบนารีขนาดใหญ่ไปยังที่เก็บแยกต่างหากจากแหล่งที่มาในขณะที่ยังคงเวอร์ชันและเป็นปัจจุบัน)

ประโยชน์บางประการของการใช้งาน Go โดยทั่วไป:

รหัส refactor ง่าย
รองรับการทำเกลียว (ต่างจาก C ++ ซึ่งอยู่ด้านบน)
ความเร็วในการรวบรวมที่รวดเร็วเป็นพิเศษช่วยลดความต้องการการสนับสนุนภาษาสคริปต์
ระบบการพิมพ์แบบคงที่ (อินเทอร์เฟซที่พึงพอใจผ่านการพิมพ์เป็ด aka โดยนัย)
ค่าที่ส่งคืนหลายพารามิเตอร์ที่มีชื่อแท็กแอตทริบิวต์ struct
เครื่องมือและเอกสารในตัวที่ยอดเยี่ยม
ภาษาที่จัดการ

ข้อเสียของการใช้ Go:

ไม่มีมาโครหรือเทมเพลต
ไม่มีห้องสมุดที่รองรับภาษาที่เป็นผู้ใหญ่มากกว่านี้
ภาษาที่มีการจัดการ (มีวัตถุประสงค์สองรายการ)
ไม่มี IDE

มีหลายวิธีในการรับหน่วยความจำแบบ raw (นำเข้า "ไม่ปลอดภัย") และฉันจะเชื่อมโยงบทความที่แสดงว่าโปรแกรม go สามารถทำโปรไฟล์สำหรับหน่วยความจำและความเร็วได้อย่างไร โดยสรุป Go อ้างว่ามันเป็น C ที่ทันสมัยดูเหมือนจริงมาก ฉันคิดว่ามันออกแบบ "ฉลาด" (ด้วยเหตุผลมากกว่าที่ฉันพูดถึง) และที่สำคัญกว่านั้นคือมีการบันทึกไว้อย่างดี เครื่องยนต์ที่ได้รับการออกแบบใน Go จะแตกต่างจากเครื่องยนต์ที่ออกแบบใน C ++ (สิ่งที่ฉันยังคุ้นเคยอยู่) แต่เครื่องยนต์ Go แก้ปัญหามากมายที่ไม่ได้รับการแก้ไขใน C ++ (เช่นขนาน ความซับซ้อนของภาษา C ++ และการใช้มรดกอย่างไม่ถูกต้อง)

นี่คือบทความที่ฉันสัญญา: http://blog.golang.org/2011/06/profiling-go-programs.html

เจฟฟ์

— jmorgan
แหล่งที่มา

ลองประเสริฐกับ GoSublime มันให้ความรู้สึกเหมือนเป็น IDE และมีปฏิกิริยามากกว่า IDE (ถ้าไม่ใช่ทั้งหมด) สำหรับ Java

— Arne

1

คุณสามารถระบุสิ่งที่คุณหมายถึงโดย "การนำเข้าเวอร์ชันในตัว" ฉันแค่ตกใจกับแท็กเวอร์ชันของภาษาที่ไปเอง

— Arne

@jmorgan เปลี่ยนแปลงมุมมองใด ๆ ตั้งแต่ Go 1.2 และเห็นการเปลี่ยนแปลงที่กำลังจะเกิดขึ้นของ Go 1.3

— ylluminate

@Arne: โทรดี! ฉันชอบ GoSublime มาก ๆ สิ่งที่ฉันหมายถึงสำหรับ IDE ไม่มีคือการได้รับ debugger ภาพคุณต้องใช้ gogdb (ซึ่งเป็นเครื่องมือที่ดี) แต่มันไม่ดีเท่า Visual Studio นี่คือสิ่งที่ฉันหมายถึงเกี่ยวกับการขึ้นต่อกันของแพ็คเกจและการกำหนดเวอร์ชัน: golang.org/cmd/go/… golang.org/cmd/go/#hdr-Import_path_syntax

— jmorgan

@ylluminate: ฉันคิดว่า Go นั้นดีขึ้นเรื่อย ๆ ตอนนี้มาพร้อมกับแพคเกจการทดสอบเพื่อให้คุณสามารถดูสิ่งที่ทดสอบและสิ่งที่ไม่ ฉันพบว่าการมีชุดทดสอบที่เหมาะสมทำให้ชีวิตของฉันง่ายขึ้นมาก ... ดังนั้นนี่จึงเป็นคุณสมบัติที่ยิ่งใหญ่สำหรับฉัน Go 1.3 ดูเหมือนว่าจะมีการปรับปรุงขนาดไบนารี่และความเร็วรันไทม์ (โดยเฉพาะตัวเก็บขยะ) ดังนั้นมันจึงยอดเยี่ยม

— jmorgan

4

สิ่งอื่นที่ควรพิจารณาคือเนื่องจาก Go ยังค่อนข้างใหม่อาจไม่มีการผูกมัดกับไลบรารีทั่วไปจำนวนมากที่ใช้ในการพัฒนาเกม

— บ๊อบซอมเมอร์
แหล่งที่มา

กรณีที่แน่นอน ตัวอย่างเช่นฉันเจอโครงการ Go / SDL สองโครงการซึ่งหนึ่งในนั้นดูเหมือนจะถูกทอดทิ้ง ฉันได้พบกับเกมไม่กี่เกมที่ค่อนข้างเล็กซึ่งใช้ทั้งสองเกม

— TSomKes

1

คุณควรตรวจสอบgithub.com/go-glไม่ใช่ SDL แต่เป็นทางเลือกที่ดีถ้าคุณใช้ OpenGl สำหรับเวกเตอร์มีgithub.com/Jragonmiris/mathglแต่ฉันพบข้อบกพร่องที่นั่น Go go เป็นเรื่องง่ายมากที่จะห่อไลบรารี่ C ไม่จำเป็นต้องใช้ makefiles เลย คุณสามารถนำเข้าไฟล์ส่วนหัว C และใช้ฟังก์ชั่นได้โดยตรง

— Arne

0

อย่าใช้ Go เพื่อพัฒนาเกมมันจะเป็นอัลบาทรอสรอบคอของคุณ Toolchain สำหรับการพัฒนาเกมมีความลึกมากกว่าภาษาที่คุณเขียนในสิ่งที่คุณจะพบกับอุปสรรคในทุก ๆ ทางที่จะไม่อยู่ที่นั่นถ้าคุณไปกับบางสิ่งที่สร้างขึ้น

อย่าเข้าใจฉันผิดฉันชอบเล่นกับภาษาใหม่ ๆ แต่ถ้าคุณพยายามทำให้เกมเลือกภาษาที่มีชุมชนและการสนับสนุนและคุณจะดีขึ้นมาก

— แอรอนเบรดี้
แหล่งที่มา

9

ในทางกลับกันถ้าคุณเพิ่งจะทำ hardcode ในโปรเจ็กต์อินดี้เล็ก ๆ เพื่อเล่นกับภาษาใหม่ความกังวลเกี่ยวกับ "toolchain" นั้นเกินจริง

2

ฉันต้องไม่เห็นด้วยที่นี่ เนื้อหาส่วนใหญ่ที่เกี่ยวข้องกับการพัฒนาเกมไม่มีส่วนเกี่ยวข้องกับภาษา การถามคำถามเกี่ยวกับ OpenGL ไม่จำเป็นต้องสนใจโปรแกรมของคุณใน C C ++ Go หรือแม้แต่ Java แล้วคุณกำลังพูดถึงเรื่อง Toolchain อะไร? และทำไมมันไม่ควรไป?

— Arne