Sviluppare giochi in Go? [chiuso]


40

La nuova lingua Go di Google è ancora agli inizi e deve ancora trovare un uso o supporto diffuso nel mondo reale. Anche così, sembra un esperimento promettente e mi chiedo se potrebbe avere un futuro nello sviluppo del gioco. Non sono stato in grado di trovare molte discussioni specifiche del gioco su Vai altrove e ho pensato che una discussione in CW potesse essere appropriata.

Alcuni pensieri:

  • Secondo golang.org , i programmi Go "funzionano quasi con la stessa velocità del codice C o C ++ comparabile" - abbastanza velocemente?
  • La raccolta dei rifiuti di Go è adatta ai giochi?
  • Quanta rielaborazione mentale è necessaria per creare giochi nella terra di goroutine simultanee?
  • Go viene spesso chiamato un linguaggio di livello "sistemi", con il software server fornito come esempio. È difficile non pensare ai server di gioco multiplayer quando si sente questo.

I vostri pensieri?


1
Consiglierei a chiunque non abbia familiarità con GO di seguire effettivamente il link prima di rispondere anziché semplicemente rispondere in base ai "pensieri" dati che vengono detti se la tua risposta è generica e non specifica per questa lingua, quindi suppongo che non abbia importanza
lathomas64,

1
Mi chiedo se riesci a creare giochi in corso (il gioco): P
RCIX

4
Non sono sicuro che ' Go ' sia considerato completo (quindi di nuovo è gestito dall'uomo). Ma lo spazio di archiviazione è molto limitato (almeno se si utilizza una scheda di regolamentazione).
David C. Bishop,

@ DavidC.Bishop Funny ...
Brian Ortiz,

1
Se crei un motore di gioco, dovresti assicurarti di sfruttare ciò che la lingua può fare, invece di provare a usarlo come faresti con un linguaggio più "convenzionale" e copiare ciò che già esiste.

Risposte:


34

La mia opinione sulle tue domande:

  • La lingua è abbastanza veloce. Il linguaggio Java più lento viene utilizzato per lo sviluppo del gioco. Anche Python (pygame) viene utilizzato per lo sviluppo di giochi ed è significativamente più lento di Java. Tutto dipende dal tipo di gioco e dall'intensità del processore.
  • La raccolta dei rifiuti in generale non è molto buona per i giochi. Tuttavia, Go ha un sistema di raccolta dei rifiuti particolarmente difettoso (mark-and-sweep) che ferma il mondo mentre pulisce le cose. Sarà difficile da affrontare e provocherà una sorta di framerate stop-and-go.
  • È necessaria una discreta quantità di ritocco mentale per creare giochi con goroutine. Grafica e logica non possono essere concorrenti nel senso tradizionale; ma a un livello inferiore, parti della logica sono ottimi candidati per goroutine simultanee (ad es. elaborazione parallela di decisioni AI, sistemi di particelle, ecc.)
  • Un server di gioco multiplayer può davvero essere un ottimo candidato per la lingua Go.

Secondo me, se hai un forte bisogno di provare a scrivere giochi con una lingua, provaci. Ovviamente se lo stai prendendo in considerazione, hai una passione per farlo, e perché non seguire quella passione invece di forzarti a conformarti alla norma? Potrei dire molto di più, ma ho già detto molto nella mia risposta alla domanda: "Ruby è un linguaggio adatto allo sviluppo del gioco?"


6
"un sistema di raccolta dei rifiuti particolarmente cattivo (mark-and-sweep)" mark-and-sweep non arresta intrinsecamente il mondo - Java ha ad esempio un collector mark-and-sweep simultaneo e Lua ne ha usato uno ingenuo per molto tempo - e gran parte della durata della pausa può essere controllata tramite un attento sistema generazionale. Detto questo, Go's è stop-the-world mark-and-sweep. Ma il primo, non il secondo, è il problema dei giochi. (Il thread di Ruby aveva anche alcune strane affermazioni su questo.)

1
L'attuale sistema Go GC sembra essere una sorta di segnaposto: "L'implementazione attuale è un semplice raccoglitore, ma un rimpiazzo è in lavorazione" ( golang.org/doc/go_lang_faq.html#garbage_collection ). Sono state discusse le opzioni di sostituzione; Non sono a conoscenza di alcuna decisione ferma in merito.
TSomKes,

1
Joe, grazie per il chiarimento! Non ne ero a conoscenza. E sì, TSomKes, l'ho visto, quindi possiamo mantenere le nostre speranze che Go realizzerà un migliore bidone della spazzatura a un certo punto.
Ricket,

4
Si noti che la risposta di cui sopra non è aggiornata quando si tratta dell'attuale Garbage Collector. È un gioco con la palla completamente diverso con Go 1.5. Mi chiedo quanto sia ancora preoccupante.
Jonas,

3
E sembra che con go 1.8, il GC sarà ridotto a 100μs di stop-the-world simultanei. groups.google.com/forum/#!topic/golang-dev/Ab1sFeoZg_8
Dolanor

17

Ho scritto un piccolo motore in Go for OSX (usando OpenGl per la finestra grafica). Ho una certa esperienza con i motori di gioco C ++ ( http://morganjeff.weebly.com/ ) e ho deciso di provare Go dopo aver letto alcune delle funzionalità che offre.

A partire dalla versione Go 1.1 go ha il supporto per la maggior parte delle funzionalità di cui avevo bisogno per scrivere un motore di gioco (in realtà un nucleo di gioco come un motore suggerisce editor e cosa no) tra cui:

  • Associazione funzioni membro (per il sistema di messaggistica)
  • Reflection è integrato (utile per serializzazione, supporto di strumenti esterni, ecc.)
  • Interfacce (per implementare comportamenti polimorfici per sistemi, componenti, ecc.)

Alcuni dei vantaggi dell'utilizzo di Go (per un grande progetto):

  • I test sono integrati nel linguaggio (questo include test di benchmark e alcune asserzioni)
  • Gli esempi sono facili da aggiungere alla lingua (e sono compilati per correttezza)
  • Il codice specifico dell'architettura è facile da aggiungere (tramite convenzioni di denominazione dei file)
  • La profilazione è integrata nella lingua
  • controllo delle versioni integrato delle importazioni (consente di aggiungere file binari di grandi dimensioni a un repository separato dall'origine, mantenendolo aggiornato e aggiornato)

Alcuni vantaggi dell'utilizzo di Go in generale:

  • Codice facile da refactoring
  • Go supporta il threading (diversamente dal C ++ che lo ha sovrapposto)
  • una velocità di compilazione super veloce riduce la necessità di supporto del linguaggio di scripting
  • sistema di tipizzazione statica (le interfacce sono soddisfatte tramite la tipizzazione duck in modo implicito)
  • più valori di ritorno, parametri denominati, attributi di struttura con tag
  • ottimi strumenti e documentazione integrati
  • lingua gestita

Alcuni aspetti negativi dell'utilizzo di Go:

  • Nessuna macro o modello
  • Non ha il supporto libreria di lingue più mature
  • lingua gestita (elencata due volte apposta)
  • NESSUN IDE

Esistono modi per ottenere memoria raw in go (import "non sicuro") e collegherò un articolo che mostra come un programma go può essere profilato per memoria e velocità. Tutto sommato, l'affermazione di Go che è una C moderna sembra molto vera. Penso che sia progettato "in modo intelligente" (per molte più ragioni di quelle che ho menzionato) e, cosa più importante, è ben documentato. Un motore progettato in Go sarà un po 'diverso da un motore progettato in C ++ (qualcosa a cui mi sto ancora abituando), ma il motore Go risolve molti problemi che non sono realmente risolti in C ++ (vale a dire parallelismo, la complessità del linguaggio C ++ e l'uso improprio dell'eredità).

Ecco l'articolo che ho promesso: http://blog.golang.org/2011/06/profiling-go-programs.html

-Jeff


prova Sublime con GoSublime, sembra davvero un IDE ed è molto più reattivo di molti (se non tutti) IDE per Java.
Arne,

1
puoi specificare cosa intendi per "controllo delle versioni integrato delle importazioni", sono solo diffidente nei confronti del tag della versione della stessa lingua.
Arne,

@jmorgan eventuali cambiamenti di prospettiva da Go 1.2 e vedere i cambiamenti imminenti di Go 1.3?
illuminerà il

@Arne: buona chiamata! GoSublime mi piace davvero molto. Quello che volevo dire senza IDE è che per ottenere un debugger visivo devi usare gogdb (che è un ottimo strumento), ma non è bello come Visual Studio. Ecco cosa intendevo per dipendenze dei pacchetti e controllo delle versioni: golang.org/cmd/go/… golang.org/cmd/go/#hdr-Import_path_syntax
jmorgan

@ylluminate: Onestamente penso che Go stia migliorando sempre di più. Ora viene fornito con un pacchetto di copertura di prova, in modo da poter vedere rapidamente cosa è stato testato e cosa no. Ho scoperto che avere una discreta suite di test in atto rende la mia vita molto più semplice ... quindi questa è una grande caratteristica per me. Go 1.3 sembra che ci saranno miglioramenti nelle dimensioni binarie e nella velocità di runtime (in particolare il Garbage Collector), quindi è fantastico.
jmorgan,

4

Qualcos'altro a cui pensare è che dato che Go è ancora relativamente nuovo, potrebbero non esserci vincoli per molte delle librerie comuni utilizzate nello sviluppo del gioco.


Sicuramente il caso. Ad esempio, mi sono imbattuto in due progetti Go / SDL, uno dei quali sembra essere stato abbandonato. Ho trovato una manciata di giochi (relativamente piccoli) che usano uno di essi.
TSomKes,

1
Dovresti assolutamente dare un'occhiata a github.com/go-gl non è SDL ma una buona alternativa se usi OpenGl. Per i vettori c'è github.com/Jragonmiris/mathgl , ma ho trovato dei bug lì. Go make è semplicissimo da avvolgere nelle librerie C, non c'è bisogno di makefile. È inoltre possibile importare file di intestazione C e utilizzare direttamente le loro funzioni.
Arne,

0

Non usare Go per sviluppare un gioco, sarà solo un albatro attorno al collo. La toolchain per lo sviluppo del gioco si estende molto più in profondità del solo linguaggio in cui scrivi le cose che troverai ostacoli ad ogni turno che semplicemente non ci saranno se vai solo con qualcosa di stabilito.

Non fraintendetemi, adoro giocare con nuove lingue, ma se stai cercando di fare in modo che i giochi scelgano una lingua che ha una community e un supporto e starai molto meglio.


9
D'altra parte, se stai solo programmando cose su un piccolo progetto indipendente per giocare con una nuova lingua, preoccuparti della "toolchain" è sopravvalutato.

2
Non sono d'accordo qui. Molte cose legate allo sviluppo del gioco non hanno nulla a che fare con il linguaggio. Fare domande su OpenGL non ha nulla da fare per il tempo programmato in C C ++ Go o persino Java. E a proposito di quale toolchain stai parlando? E perché dovrebbe essere incompatibile andare?
Arne,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.