Desarrollando juegos en Go? [cerrado]

40

El nuevo lenguaje Go de Google todavía está en pañales, y aún no ha encontrado un uso o soporte generalizado en el mundo real. Aun así, parece un experimento prometedor, y me pregunto si podría tener un futuro en el desarrollo de juegos. No he podido encontrar mucha discusión específica sobre el juego de Ir a otra parte, y pensé que una discusión de CW podría ser apropiada.

Algunos pensamientos:

  • Según golang.org , los programas Go "se ejecutan casi tan rápido como un código C o C ++ comparable", ¿lo suficientemente rápido?
  • ¿La recolección de basura de Go es adecuada para juegos?
  • ¿Cuántas herramientas mentales son necesarias para crear juegos en la tierra de goroutines concurrentes?
  • Con frecuencia, Go se denomina lenguaje de "sistemas", con el software del servidor como ejemplo. Es difícil no pensar en servidores de juegos multijugador al escuchar esto.

¿Tus pensamientos?

go TSomKes
fuente
1
Aconsejaría a cualquiera que no esté familiarizado con GO que siga el enlace antes de responder, en lugar de responder simplemente en función de los "pensamientos" que se dicen si su respuesta es genérica y no específica de este idioma, entonces supongo que no importa
lathomas64
1
Me pregunto si puedes hacer juegos en
marcha
44
No estoy seguro de si ' Go ' se considera que se completa (entonces, de nuevo, es operado por humanos). Pero el espacio de almacenamiento es muy limitado (al menos si se usa una placa de regulación).
David C. Bishop
@ DavidC.Bishop Funny ...
Brian Ortiz
1
Si crea un motor de juego go, debe asegurarse de aprovechar lo que el lenguaje puede hacer, en lugar de tratar de usarlo de la misma manera que lo haría con un lenguaje más "convencional" y copiar lo que ya existe.

Respuestas:

34

Mi opinión sobre sus preguntas:

  • El lenguaje es bastante rápido. El lenguaje Java más lento se usa para el desarrollo de juegos. Incluso Python (pygame) se usa para el desarrollo de juegos, y es significativamente más lento que Java. Todo depende del tipo de juego y de la intensidad del procesador.
  • La recolección de basura en general no es muy buena para los juegos. Sin embargo, Go tiene un sistema de recolección de basura particularmente malo (marcar y barrer) que detiene el mundo mientras limpia cosas. Será difícil lidiar con él y provocará una especie de framerate de stop-and-go.
  • Una cantidad decente de actualización mental es necesaria para crear juegos con goroutines. Los gráficos y la lógica no pueden ser concurrentes en el sentido tradicional; pero en un nivel más pequeño, partes de la lógica son excelentes candidatos para goroutinas concurrentes (por ejemplo, procesamiento paralelo de decisiones de IA, sistemas de partículas, etc.)
  • Un servidor de juego multijugador puede ser un gran candidato para el lenguaje Go.

En mi opinión, si tienes un impulso lo suficientemente fuerte como para intentar escribir juegos con un idioma, hazlo. Obviamente, si lo estás considerando, entonces tienes pasión por hacerlo, y ¿por qué no seguir esa pasión en lugar de obligarte a cumplir con la norma? Podría decir mucho más, pero ya dije mucho en mi respuesta a la pregunta: "¿Es Ruby un lenguaje adecuado para el desarrollo de juegos?"

Ricket
fuente
66
"un sistema de recolección de basura particularmente malo (marcar y barrer)" marcar y barrer no detiene intrínsecamente al mundo: Java tiene un recolector concurrente de marcar y barrer, por ejemplo, y Lua usó uno ingenuo durante mucho tiempo - y gran parte de la pausa se puede controlar mediante un cuidadoso sistema generacional. Dicho esto, Go's es una marca y barrido para detener el mundo. Pero el primero, no el último, es el problema de los juegos. (El hilo de Ruby también tenía algunas afirmaciones extrañas sobre esto.)
1
El sistema actual de Go GC parece ser algo así como un marcador de posición: "La implementación actual es un simple recolector de marca y barrido, pero un reemplazo está en proceso" ( golang.org/doc/go_lang_faq.html#garbage_collection ). Se han discutido las opciones de reemplazo; No tengo conocimiento de ninguna decisión firme sobre el asunto.
TSomKes
1
Joe, gracias por aclarar! No estaba al tanto de eso. Y sí, TSomKes, lo vi, así que podemos mantener nuestras esperanzas de que Go implementará un mejor recolector de basura en algún momento.
Ricket
44
Tenga en cuenta que la respuesta anterior no está actualizada cuando se trata del recolector de basura Go actual. Es un juego de pelota completamente diferente con Go 1.5. Me pregunto qué tan preocupante sigue siendo esto.
Jonas
3
Y parece que con go 1.8, el GC se reducirá a 100 μs de stop-the-world simultáneo. groups.google.com/forum/#!topic/golang-dev/Ab1sFeoZg_8
Dolanor
17

He escrito un pequeño motor en Go para OSX (usando OpenGl para la ventana de gráficos). Tengo algo de experiencia con los motores de juegos C ++ ( http://morganjeff.weebly.com/ ) y decidí probar Go después de leer sobre algunas de las características que ofrece.

A partir de la versión Go 1.1, go tiene soporte para la mayoría de las características que necesitaba para escribir un motor de juego (realmente un núcleo del juego como motor sugiere editores y qué no) incluyendo:

  • Enlace de función miembro (para el sistema de mensajería)
  • Reflection está integrado (útil para la serialización, soporte de herramientas externas, etc.)
  • Interfaces (para implementar comportamiento polimórfico para sistemas, componentes, etc.)

Algunos de los beneficios de usar Go (para un proyecto grande):

  • Las pruebas están integradas en el lenguaje (esto incluye pruebas de referencia y algunas afirmaciones)
  • Los ejemplos son fáciles de agregar al idioma (y se compilan para su corrección)
  • El código específico de arquitectura es fácil de agregar (a través de convenciones de nomenclatura de archivos)
  • La creación de perfiles está integrada en el idioma.
  • versiones integradas de las importaciones (permite agregar grandes binarios a un repositorio separado de la fuente, mientras lo mantiene versionado y actualizado)

Algunos beneficios de usar Go en general:

  • Código fácil de refactorizar
  • Go admite subprocesos (a diferencia de C ++ que lo superpuso en capas)
  • La velocidad de compilación súper rápida reduce la necesidad de soporte de lenguaje de script
  • sistema de tipeo estático (las interfaces se satisfacen mediante tipeo de pato también conocido implícitamente)
  • múltiples valores de retorno, parámetros con nombre, atributos de estructura etiquetados
  • excelentes herramientas y documentación incorporadas
  • lenguaje administrado

Algunas desventajas de usar Go:

  • Sin macros ni plantillas.
  • No tiene el soporte de la biblioteca de idiomas más maduros
  • lenguaje administrado (enumerado dos veces a propósito)
  • NO IDE

Hay formas de obtener memoria sin procesar en go (importación "insegura") y vincularé un artículo que muestra cómo se puede perfilar un programa go para memoria y velocidad. En general, la afirmación de Go de que es una C moderna parece muy cierta. Creo que está diseñado "inteligentemente" (por muchas más razones de las que mencioné) y, lo que es más importante, está bien documentado. Un motor diseñado en Go será un poco diferente a un motor diseñado en C ++ (algo a lo que todavía me estoy acostumbrando), pero el motor Go resuelve muchos problemas que no se resuelven realmente en C ++ (es decir, paralelismo, la complejidad del lenguaje de C ++ y el mal uso de la herencia).

Aquí está el artículo que prometí: http://blog.golang.org/2011/06/profiling-go-programs.html

-Jeff

jmorgan
fuente
pruebe Sublime con GoSublime, realmente se siente como un IDE, y es mucho más reactivo que muchos (si no todos) IDEs para Java.
Arne
1
¿puede especificar qué quiere decir con "versiones integradas de las importaciones"? Solo estoy al tanto de la etiqueta de versión del lenguaje go en sí.
Arne
@jmorgan ¿alguna perspectiva cambia desde Go 1.2 y viendo los próximos cambios de Go 1.3?
iluminar el
@Arne: ¡Buena llamada! Realmente me gusta mucho GoSublime. Lo que quise decir sin IDE es que para obtener un depurador visual debes usar gogdb (que es una gran herramienta), pero no es tan bueno como el estudio visual. Esto es lo que quise decir sobre dependencias de paquetes y versiones: golang.org/cmd/go/… golang.org/cmd/go/#hdr-Import_path_syntax
jmorgan
@ iluminados: Sinceramente, creo que Go está mejorando cada vez más. Ahora viene con un paquete de cobertura de prueba, para que pueda ver rápidamente qué se prueba y qué no. Descubrí que tener un conjunto de pruebas decente en el lugar hace que mi vida sea mucho más fácil ... así que esta es una gran característica para mí. Go 1.3 parece que habrá mejoras en el tamaño binario y la velocidad de ejecución (específicamente el recolector de basura), así que eso es genial.
jmorgan
4

Algo más en lo que pensar es que, dado que Go todavía es relativamente nuevo, es posible que todavía no haya enlaces para muchas de las bibliotecas comunes utilizadas en el desarrollo de juegos.

Bob Somers
fuente
Definitivamente el caso. Por ejemplo, me he encontrado con dos proyectos Go / SDL, uno de los cuales parece haber sido abandonado. He encontrado un puñado de juegos (relativamente pequeños) que usan cualquiera de ellos.
TSomKes
1
Definitivamente deberías visitar github.com/go-gl , no es SDL pero es una buena alternativa si usas OpenGl. Para los vectores hay github.com/Jragonmiris/mathgl , pero encontré errores allí. Go Make es súper fácil de envolver bibliotecas C, no hay necesidad de makefiles en absoluto. También puede importar archivos de encabezado C y usar sus funciones directamente.
Arne
0

No uses Go para desarrollar un juego, solo será un albatros alrededor de tu cuello. La cadena de herramientas para el desarrollo de juegos se extiende mucho más allá del lenguaje en el que escribes cosas en las que encontrarás obstáculos a cada paso que simplemente no estarán allí si solo vas con algo establecido.

No me malinterpretes, me encanta jugar con nuevos idiomas, pero si estás tratando de hacer que los juegos elijan un idioma que tenga comunidad y apoyo, estarás mucho mejor.

Aaron Brady
fuente
9
Por otro lado, si solo va a codificar cosas en un pequeño proyecto independiente para jugar con un nuevo idioma, preocuparse por la "cadena de herramientas" está sobrevalorada.
2
Tengo que estar en desacuerdo aquí. La mayoría de las cosas relacionadas con el desarrollo de juegos no tienen nada que ver con el lenguaje. Hacer preguntas sobre OpenGL no tiene nada que ver con el tiempo que programe en C C ++ Go o incluso Java. Y por cierto, ¿de qué cadena de herramientas estás hablando? ¿Y por qué debería ser incompatible ir?
Arne