STL para juegos, sí o no? [cerrado]

Cada lenguaje de programación tiene su biblioteca estándar de contenedores, algoritmos y otras cosas útiles. Con lenguajes como C #, Java y Python, es prácticamente inconcebible usar el lenguaje sin su lib estándar.

Sin embargo, en muchos juegos de C ++ en los que he trabajado, no utilizamos el STL en absoluto, utilizamos una pequeña fracción o utilizamos nuestra propia implementación. Es difícil saber si esa fue una decisión acertada para nuestros juegos, o simplemente por ignorancia de la STL.

Entonces ... ¿el STL encaja bien o no?

Cuando trabajaba en el desarrollo profesional de juegos, STL era demasiado inmaduro e hinchado. Pero eso fue hace> 10 años.

Ahora trabajo en simulación militar, que tiene requisitos de rendimiento aún más estrictos (como la velocidad de fotogramas nunca puede ir por debajo de algunos FPS). En la simulación militar, STL se usa en todo el lugar.

Algunas de las personas que le dicen que no use STL usan el argumento de que no siempre es la solución perfecta o incluso la mejor para el problema. Pero esa no es una respuesta a la pregunta. La pregunta debería ser: ¿hay algo inherentemente incorrecto con el uso de STL en los juegos? Yo diría que no, la mayoría de las veces, STL es una mejor implementación que la que un usuario inventaría por su cuenta.

Solo asegúrate de saber cómo usar el STL y úsalo en tu juego. Lea algunos libros y mire el código de implementación en el STL que está utilizando.

Diría que, desde la parte superior de mi cabeza, es una mejor idea usar el STL a menos que sepa exactamente por qué no quiere usarlo.

Esto es lo que pasa con el STL: está desarrollado por personas que son más inteligentes que usted. Eso no pretende ser ofensivo ni nada, es solo que el STL es desarrollado por personas cuyo trabajo es realmente construir el STL. Será casi tan rápido como la plataforma lo permita y, en general, será mucho más robusto que una solución casera (y esto debería ser una gran preocupación si no más que preocuparse por la velocidad bruta, porque su juego necesita robustez un poco más de lo que necesita velocidad; este último no tiene sentido sin el primero).

Las quejas de que la STL impone una "visión estrecha del mundo" me parecen un poco tontas. Son contenedores. Tienen un conjunto limitado de operaciones porque los contenedores tienen conjuntos limitados de operaciones. ¿Qué haces que no concuerda con esto?

He visto muy pocas razones para no usar el STL para juegos.

Para los problemas de asignación de memoria, muchas personas no lo saben, pero puede escribir asignadores personalizados para sus clases de contenedor STL. Los asignadores son básicamente clases de políticas que pasa a sus plantillas para determinar cómo se realizan las asignaciones. Con estos, generalmente puede solucionar cualquier problema de memoria que sea problemático en su plataforma de elección.

Por supuesto, si está utilizando el STL y está haciendo cosas tontas como mapas de cadenas a tipos grandes, sin puntero, entonces tiene mayores problemas en su mano.

El STL predeterminado tiene un buen número de problemas que dificultan su uso con juegos, especialmente cuando se trata de la alineación de la memoria.

Una variante personalizada como EA STL está especialmente diseñada para juegos y puede obtener un rendimiento de memoria y una usabilidad de consola mucho mejores. Se convirtió en código abierto en 2016, bajo una cláusula BSD-3, con un repositorio en GitHub .

Esto es lo que Mike Acton (Director de motores en Insomniac Games of Spyro the Dragon, Ratchet & Clank y Resistance) tuvo que decir sobre esto cuando se le preguntó aquí . Tenga en cuenta que se le preguntó sobre STL y Boost en general en relación con el uso en el desarrollo del juego.

STL / Boost, ¿pertenece a gamedev? Si solo partes de él, ¿cuáles?

Estás preguntando acerca de dos cosas diferentes aquí, ¿verdad? STL y Boost, por separado. Pero realmente, mi respuesta es la misma: no hay nada de malo en ninguno de los dos, pero desaconsejo su uso. El uso de cualquiera alienta a las personas a adaptar una solución a un problema en lugar de encontrar una solución a un problema. La solución siempre debe ser apropiada para los datos disponibles y las restricciones del hardware, etc. Tanto STL como Boost tienen una visión extremadamente estrecha del "mundo" y su uso apropiado es limitado. Realmente, los desaliento porque conducen a los programadores por la dirección equivocada de inmediato, a menudo digo que si sientes que necesitas cualquiera de los dos, probablemente no entiendas realmente el problema.

También he notado que la mayoría de los desarrolladores de juegos profesionales se esfuerzan más hacia C que C ++.

Si se encuentra reescribiendo algo que ya existe en el STL, por cualquier motivo, deténgase . Usa el STL.

El STL se ha optimizado durante años de análisis y tiempo, y es una apuesta segura que probablemente no va a escribir algo que sea más eficiente. Eso no quiere decir que deba usar STL donde una solución más simple sea posible (es decir, use una matriz cuando tenga una cantidad conocida de cosas, no una lista stl ::), pero si está escribiendo su propia implementación de un mapa ( la estructura de datos básica, no un mapa mundial del juego), lo estás haciendo mal.

¿Es STL una buena opción para los juegos? Seguro. Los juegos son piezas complejas de software, el STL proporciona características que ayudan a gestionar la complejidad, por lo que es bueno.

¿Es un buen ajuste para su plataforma? No necesariamente. Si está escribiendo para una consola, debe tener mucho cuidado con el uso de memoria y caché. El STL no hace esto muy fácil.

Creo que con demasiada frecuencia confundimos los "juegos" con los "juegos en tiempo real de alto rendimiento que se ejecutan en hardware integrado o a medida", pero es importante hacer una distinción. Si está escribiendo un juego de Windows que no intenta ejecutarse en pantalla completa a una velocidad constante de 60 fps, entonces no hay razón para evitar las herramientas que le brinda la biblioteca estándar.

Sé que es muy tarde para la fiesta, pero el tiempo cambia y las respuestas permanecen. C ++ 11 tiene cambios bastante radicales, muchos de los cuales son para aumentar el rendimiento de C ++ y la biblioteca estándar. Parece que aquellos que no usan STL o Boost, tienden a no mantenerse al día con los nuevos estándares tampoco, dejando que las soluciones caseras no tengan mejoras importantes, por supuesto, este no es siempre el caso.

He usado STL en todos los proyectos desde mediados de los 90 hasta hoy, con la excepción de un corto tiempo en EA. Creo que el lado anti STL tenía algunas razones marginalmente racionales para no usarlo. Esos se han ido en gran medida. Los asignadores personalizados son una solución, el uso de la reserva es otra, y no pasar cosas por valor es un tercero, pero estos son bastante simples y cualquier programador debería saberlo. Sin embargo, lo más importante es el uso de algoritmos. Los escritores de compiladores saben exactamente lo que hace for_each () y pueden optimizar el código. Eso no puede ocurrir con un bucle de inicio. for_each () en un objeto const es aún mejor. Microsoft optimiza para cada uno de muchas maneras, incluida la serialización. También tienen la biblioteca AMP que tiene parallel_for_each (). Si tiene la oportunidad, hable con los ingenieros del compilador sobre esto. Los compiladores de consola van a optimizar lo que se usa, así que ' es un problema de huevo y gallina. Microsoft se está volviendo muy pesado con C ++ 11 y el próximo XBox no será diferente. No tengo idea sobre PS4, todavía no tenemos una.

Los asignadores personalizados son una forma de manejar el problema de memoria, pero otra opción (a menudo pasada por alto) es usar new y delete basado en clases. Se pueden obtener enormes aumentos de rendimiento de esta manera.

La noción de que Boost y STL tienen una visión estrecha de la resolución de problemas es pura locura. Estoy sorprendido de cuántas cosas en STL y Boost se pueden personalizar a través de rasgos y políticas. Busque una cadena independiente de mayúsculas y minúsculas como ejemplo.

Con respecto a los tiempos de enlace largos y la hinchazón de código, la nueva plantilla externa debería ayudar con esto. En general, encuentro que los tiempos de compilación largos provienen del exceso de acoplamiento y el mal uso de pch.

La razón más convincente para usar STL en lugar de homepun es que hay millones de personas que pueden ayudarlo con STL. Como siempre, no optimices prematuramente y prueba, prueba, prueba.

Este es un tema candente en el desarrollo de juegos. Yo personalmente no lo recomiendo, excepto quizás por EASTL como se mencionó anteriormente. Tengo dos problemas principales con STL (técnicamente "The C ++ Standard Library", ya que STL ya no es el nombre) en los juegos. 1) La asignación de memoria dinámica a menudo desperdicia mucho tiempo de ejecución en los juegos cuando se usa STL. 2) El uso de STL fomenta un enfoque de matriz de estructuras para la arquitectura del juego, mientras que un enfoque de estructura de matrices es mucho más amigable con la caché.

Depende. ¿Qué tan grande es el proyecto, qué plataforma (s) y cuál es la línea de tiempo?

Si está trabajando en un proyecto grande, en plataformas con recursos limitados, con una línea de tiempo y un presupuesto significativos, entonces puede ahorrarse muchos problemas al evitar el infierno inevitable que se verá en una base de código de línea de medio millón que es lleno de STL, no puede mantener una velocidad de fotogramas por encima de 30, come suficiente RAM para adaptarse a varios activos más y tarda 2 horas en construirse.

Sin embargo, en otras situaciones, STL e incluso Boost pueden ser muy útiles cuando se aplican adecuadamente. He trabajado en títulos que usaban una selección de STL / Boost, y era un sueño absoluto para codificar: ¡menos errores / fugas y un código fácil de mantener significa más tiempo para codificar nuevas funciones divertidas! Especialmente para proyectos de pasatiempo, es una gran victoria en el departamento de motivación.

¡Sepa cuándo cambiar el rendimiento por conveniencia!

En mi humilde opinión, diría que es una buena opción ya que STL ya funciona bien y está optimizado para las tareas para las que está hecho. Además, estás trabajando en un juego, así que usa las herramientas que tienes a mano para que tu vida sea más fácil y tu código sea menos propenso a errores.

¿Por qué molestarse en reinventar la rueda cuando puede estar trabajando en otra cosa como la IA del juego, la experiencia del usuario o mejor aún? prueba y depuración?

STL está absolutamente bien para usar en juegos, siempre y cuando lo entiendas bien. Nuestro motor hace un uso bastante extenso y nunca ha sido un problema. No tengo ninguna experiencia con el desarrollo de consolas, lo que puede ser una historia completamente diferente, pero es compatible con todas las plataformas de PC (Windows / Mac / Linux).

Lo más importante es comprender cuáles son las fortalezas y debilidades de cada tipo de contenedor y elegir el contenedor correcto para el trabajo que está haciendo.

Mi antiguo empleador pasó de usar un conjunto robusto de clases de contenedores personalizados a STL. Los tiempos de construcción aumentaron y la facilidad de depuración disminuyó, ambos de manera bastante significativa. Si hubiéramos estado comenzando desde cero, STL (quizás mejor usado) probablemente habría tenido sentido, pero nunca me quedó claro que ganamos algo al cambiar a STL que justificara arrojar código de trabajo, rápido y depurable.

Para mis proyectos personales, si STL encaja o no depende del proyecto. Si estoy tratando de hacer un trabajo optimizado de acceso a memoria y caché basado en datos al estilo Mike Acton, al menos pensaré en rodar mis propias estructuras de datos personalizadas. Si estoy creando prototipos de algunos algoritmos o juegos y no me importa el rendimiento, la escalabilidad, la plataforma de destino, etc., automáticamente tomaré STL.

Mis 2 centavos en esto es que el STL funciona bien. He estado desarrollando un motor de juego 3D (no de calidad AAA, pero lo suficientemente avanzado: tipos de entidades con secuencias de comandos, renderizador diferido, física de Bullet integrada) para PC y aún no he visto que los contenedores se conviertan en el principal cuello de botella. El uso incorrecto de la API 3D y los algoritmos deficientes han sido los mejores objetivos (¡determinados por el perfil!) Cada vez que entro e intento obtener un poco más de rendimiento.

He creado juegos con STL y me gusta, y parece funcionar bien.

¡Buena pregunta! Una pregunta más específica es cuáles son algunos requisitos comunes que tendría un juego que no se pueden cumplir con STL y Boost.

En mi experiencia, las limitadas limitaciones de memoria del hardware de la consola hacen que cualquier tipo de contenedor de tamaño dinámico sea una mala idea, independientemente de cuán inteligente sea su asignador personalizado. Los contenedores que no tienen límites deliberados alientan a los programadores a escribir código que no limite los límites de sus conjuntos de datos. Dependiendo de innumerables variables que son difíciles de rastrear, puede exceder sus limitaciones de memoria. Tengo el presentimiento de que esta es una de las principales causas de inestabilidad en los juegos modernos.

Además, el uso excesivo de plantillas puede conducir a tiempos de compilación muy largos en una base de código grande, y aumentará el tamaño de su ejecutable para que ya no encaje en la caché de, por ejemplo, un núcleo auxiliar en una ps3.

Sin embargo, para el desarrollo solo para PC, creo que STL y Boost son muy buenos. Si bien las soluciones de casos generales no siempre son ideales, a menudo son lo suficientemente buenas. Su primera solución a un problema casi nunca es ideal, y usted mejora o reemplaza las deficiencias hasta que sea lo suficientemente bueno.

El STL es un buen ajuste para su juego si el STL es un buen ajuste para su juego.

Al igual que con todas las elecciones de tecnología realizadas durante el desarrollo, debe sopesar los pros y los contras: ¿rodar mi propia biblioteca me dará un uso de memoria, rendimiento y productividad más beneficiosos que simplemente usar el STL? Posiblemente; aunque es igual de fácil crear una vectorimplementación que use más memoria, sea más lenta y requiera grandes cantidades de mantenimiento para seguir funcionando en comparación con lo que ya existe.

Las personas no deben evitar usar el STL en sus juegos porque otras personas evitan usar el STL en los juegos; deben evitar usarlo si han sopesado todas sus opciones y realmente creen que otra implementación mejorará la calidad de su producto.

Como con la mayoría de las preguntas, la respuesta nunca es "sí o no", blanco o negro. STL es una buena opción para algunos problemas, usarlo para esos problemas debería estar bien. Es un error suponer que es inútil, pero también es un error suponer que es apropiado usarlo en cada situación.

El mayor problema a tener en cuenta cuando se usa STL en el desarrollo del juego es la asignación de memoria. Los asignadores predeterminados de STL no parecen encajar bien en las estrategias de asignación preferidas para el desarrollo del juego. Por supuesto, se pueden usar asignadores personalizados, pero esto hace que la idea sea menos atractiva si está considerando agregar STL a una base de código que no sea STL.

Agregue a esto que si su base de código no es STL, es posible que no tenga a nadie lo suficientemente familiarizado con STL o los conceptos de plantilla para implementar los asignadores personalizados correctamente.

Creo que esta discusión se puede resumir de la siguiente manera:

código específico de aplicación mediocremente escrito <código de propósito general bien escrito <código específico de aplicación bien escrito

Cualquiera cuya solución local caiga en la categoría 3 seguramente sabe la respuesta a la pregunta original para su problema particular. El STL cae en la categoría 2. Así que para alguien que tiene que hacer la pregunta, "debería yo utilizar la STL", la respuesta es probablemente sí.

STL está bien para usar en una PC, ya que su avanzado sistema de memoria virtual hace que la necesidad de una asignación cuidadosa de la memoria sea un poco menos crucial (aunque aún se debe tener mucho cuidado). En una consola, con recursos de memoria virtual limitados o inexistentes y costos de pérdida de memoria caché exorbitantes, probablemente esté mejor escribiendo estructuras de datos personalizadas que tengan patrones de asignación de memoria predecibles y / o limitados. (Y ciertamente tampoco te equivocarás haciendo lo mismo en un proyecto de juego de PC).

Creo que esta pregunta es realmente una pregunta no formulada más grande: ¿debería usar X en mi Y ? Y la única forma de responder realmente es probarlo usted mismo. Por cada persona que encuentre que diga que X funciona muy bien, encontrará a alguien que diga que es horrible. Y ambos tienen razón: para su proyecto.

Lo mejor del software, a diferencia de la mayoría de las otras disciplinas, es que siempre puedes cambiar las cosas más adelante si descubres que no funciona de la manera que te gustaría. ¿Descubres más tarde que STL no te funciona en este proyecto? Sácalo, pon algo más en su lugar. ¿No te gusta cómo dividiste los deberes entre tus objetos? Refactorizador ¿No te gusta que hayas usado objetos? Reemplácelos con métodos C rectos. ¿No le gusta que todo se almacene en estructuras y métodos para manipularlos? Reemplácelos con objetos C ++.

Yo digo no a la STL. Mi razón es bastante simple:

1. No necesitas el STL para escribir juegos. Ni siquiera los grandes.
2. STL aumenta dramáticamente su tiempo de compilación.
3. El tiempo de compilación grande conduce a menos iteraciones sobre su desarrollo.

Considero que el recuento de iteraciones es de la mayor importancia, por lo que me mantengo alejado del STL y de cualquier otra técnica de desarrollo que ralentice las iteraciones (como la arquitectura por el bien o los lenguajes de script que deben compilarse).

Las iteraciones costosas conducen a enormes equipos de desarrollo de personas que intentan hacer las cosas con muy poca realidad. Lo he visto y escuchado, y uno de los culpables parece ser los tiempos de compilación para bibliotecas de plantillas.