Si tienes algo de experiencia en el mundo de programación real, entonces sin duda en algún momento usted ha tenido que recurrir a alguna solución rápida y sucia para resolver un problema o una característica de ejecución, mientras que un plazo se vencía. Los desarrolladores de juegos a menudo experimentan una terrible "crisis" (también conocido como "marcha de la muerte"), lo que ocurre en los últimos meses de un proyecto anterior a la fecha del lanzamiento del juego. El no poder cumplir el plazo puede significar a menudo que el proyecto se cancela o, peor aún, usted pierde su trabajo. Entonces, ¿qué tipo de trucos se usan cuando se encuentran debajo de la bomba, haciendo 12 horas + por día durante semanas?
A continuación se presentan algunas anécdotas clásicas y consejos - muchas gracias a Brandon Sheffield quien originalmente elaboró este artículo en Gamasutra. He reposteado algunas de sus historias y tambien tiene añadido un poco más de las nuevas fuentes. También he enlazado en cada historia a la página principal del autor o blog siempre que sea posible.
1. El antihéroe de programación - Noel Llopis
Yo estaba recién salido de la universidad, todavía húmeda detrás de las orejas, y estaba a punto entrar en la fase beta de mi primer proyecto profesional del juego - un título a finales de los años 90 para PC. Había sido un viaje en montaña rusa emocionante, ya que en los proyectos a menudo son así. Todo el contenido estaba dentro y el juego se ve bien. Había un problema: Estábamos muy por encima de nuestro presupuesto de la memoria.
Dado que la mayoría de memoria fue recogida por los modelos y texturas, se trabajó con los artistas para reducir la huella de la memoria del juego tanto como sea posible. Hemos reducido las imágenes, modelos y texturas diezmadas comprimido. A veces lo hicimos con el apoyo de los artistas, y, a veces encima de sus cadáveres.
Cortamos megabytes después de megabytes, y después de unos días de frenética actividad, llegamos a un punto en que sentía que no había nada que pudiéramos hacer. A menos que cortar un poco de mayor contenido, no había manera de que pudiéramos liberar memoria más. Exhausto, se evaluó el uso de nuestra memoria actual. Todavía estábamos 1,5 MB por encima del límite de memoria!
En este punto, uno de los programadores más experimentados del equipo, quien había sobrevivido a muchos años de desarrollo en los "buenos viejos tiempos", decidió tomar el asunto en sus propias manos. Él me llamó a su oficina, y se encamina por lo que me imaginaba sería otra agotadora sesión de la liberación de memoria.
En cambio, trajo a colación un archivo de origen y se refirió a esta línea:
static char buffer[1024*1024*2];
"¿Ves esto?" dijo. Y luego se elimina con una sola tecla. ¡Hecho!
Probablemente vio el horror de mis ojos, así que él me explicó que había dejado de lado esos dos megabytes de memoria al inicio del ciclo de desarrollo. Sabía por experiencia que siempre era imposible cortar contenido a los presupuestos de la memoria, y que muchos proyectos había estado a punto de fallar a causa de ella. Así que ahora, como una práctica regular, el siempre pone a un lado un bonito bloque de memoria para liberar cuando es realmente necesario.
Salió de la oficina y anunció que había reducido el consumo de memoria dentro de las limitaciones presupuestarias - se le brindó como el héroe del proyecto.
la práctica Tan horrorizado como yo estaba en ese entonces sobre tal "barbaridad", tengo que admitir que estoy calentando a la misma. No he entrado en el estado de ánimo en el que puede ponerla en uso todavía, pero puedo ver cómo a veces, cuando estás contra la pared, con un poco de memoria escondida para un día lluvioso puede marcar la diferencia. qué gracioso es ver como el tiempo y la experiencia, cambia todo.
2. Caché para arriba - Andrew Russell
Para mejorar el rendimiento cuando se están procesando las cosas en un ciclo cerrado, quieres hacer que los datos para cada repetición lo más pequeño posible, y lo más cerca posible entre sí en la memoria. Eso significa que el ideal es una matriz o un vector de objetos (no punteros) que contienen sólo los datos necesarios para el cálculo.
De esta manera, cuando la CPU obtiene los datos para la primera iteración del bucle, para las siguientes iteraciones muchas líneas de datos son cargados en la memoria caché de la misma.
Realmente no hay mucho que puedas hacer con el uso de pocas y mas rápidas instrucciones porque la CPU es lo más rápida que vas a conseguir, y el compilador no puede ser mejorado. La coherencia de caché es donde está - este artículo contiene un buen ejemplo de coherencia de caché para obtener un algoritmo que no se limita a ejecutar a través de los datos de forma lineal.
3. Planee sus distracciones - Jay Barnson
El Internet es una de las mejores herramientas que se han inventado, tanto para la mejora de la productividad y su destrucción. Twitter y los foros y blogs y sitios web institucionales puede ser muy motivacionales y educativos, pero también pueden ser una distracción que destruye por completo toda esperanza de conseguir cualquier cosa hecha. Una cosa que he hecho en el pasado que ha demostrado ser muy exitosa es ceñirse a un plan para cuando puedo pasar algunos minutos consultar el correo electrónico y Twitter, o jugar una partida rápida o algo así. Ya sea en la realización de una tarea, o después de un período de tiempo (por ejemplo una de cinco minutos por cada hora). De lo contrario, el único uso del navegador es para la lectura de las páginas de referencia del manual, si es necesario. De esa manera convertir una distracción potencial en una herramienta de motivación.
4. El daño colateral - Jim Van Verth (@ cthulhim)
No sé cómo muchos recuerdan la Fuerza 21, pero fue uno de los primeros de RTS (estrategia en tiempo real) en 3D que utiliza una cámara de seguimiento para observarsu pelotón actual. Hacia el final del proyecto que tenía un error extraño en donde la cámara se detendría siguiendo el pelotón - que sólo se quedaría donde estaba, mientras que el pelotón pasó y nada se movió. La causa aparente fue al azar porque no podíamos encontrar un caso de reproducción decente. Hasta que, finalmente, uno de los probadores se dio cuenta de que ocurrió con más frecuencia cuando un ataque aéreo se produjo cerca de sus vehículos. Con esa información yo era capaz deseguirle la pista.
Debido a que la cámara estaba usando la velocidad y la aceleración y era chocable, loderivado de nuestra clase PhysicalObject, que tenía esas características. También tenía otra característica: PhysicalObjects podría recibir daño. Los ataques aéreos hizobastante daño en un radio lo suficientemente grande que fueron literalmente "matar" ala cámara.
Hice arreglar el fallo, asegurando que las cámaras no podían recibir daño, pero sólo para estar seguro, que aumentó su armadura y puntos de vida a niveles ridículos. Creo que puedo decir con seguridad que tenía la cámara más dura en cualquier juego.
5. El ciego guiando al ciego - Mauricio Gomes
En la universidad había un equipo que hizo un juego flash FPS. Por alguna extraña razón, el programador, en lugar de comprobar si el personaje estaba chocando con la pared y dejar que ir allí, lo hizo a la inversa, él comprobó si había una pared, y sólo se permite que se mueva paralelo a ella!
Esto provocó un error extraño: en los cruces o uniones T en el nivel, en realidad no se podía cruzar, sólo recurren a la aprobación a la izquierda oa la derecha. La fecha límite se acercaba, y no tenían ni idea de cómo solucionarlo.
A continuación, el escritor del equipo solucionado el problema, dijo al artista que añadiera una animación de las manos tocando las paredes, y luego añadió en la historia de fondo que el personaje principal era ciego y tenía que tocar constantemente las paredes para saber a dónde iba.
6. No te gusto cuando estoy enojado - Waanders Nick
Una vez trabajé en THQ Relic Entertainment estudio en conjunto, que algunos recordarán como uno de los primeros juegos para la Xbox 360. Comenzamos con un motor de PC (único - subproceso), y tuvimos que convertirlo en un juego completo en una nueva generación de núcleos múltiples de la consola en unos 18 meses. Unos tres meses antes de su envío, que todavía estaban en curso en alrededor de 5 disparos en el 360. Obviamente este juego necesita alguna optimización enorme.
Cuando hice algunas mediciones de desempeño, se hizo evidente que tanto como el código fue lento y muy "PC", también hubo un montón de problemas en el lado del contenido. Algunos modelos eran demasiado detalladas, algunas sombras eran demasiado costosos, y algunas misiones sólo tenía a muchos chicos dando vueltas.
Es difícil convencer a un equipo de 100 personas que los programadores no puede limitarse a "arreglar" el rendimiento del motor, y que algunas de las maneras que la gente se había acostumbrado a trabajar necesitaba ser cambiado. La gente necesita entender que el rendimiento del juego era un problema de todos, y pensé que la mejor manera de hacerlo es con un poco de humor que tenía un poco de la verdad oculta detrás de él.
La solución me llevó una hora. Un programador de compañeros tomó cuatro fotos de mi cara, uno muy feliz, normal, un poco enojado uno, y uno donde estoy tirando de mi pelo. Pongo esta imagen en la esquina de la pantalla, y que estaba vinculada a la velocidad de fotogramas. Si el juego corría a más de 30 cuadros por segundo, me sentí muy feliz, si corriera por debajo de 20, yo estaba enojado.
Después de este cambio, la cuestión pasó de todo FPS, "¡Ah, los programadores se lo arreglaran". que, "Hmm, si pongo este modelo en, Nick va a estar enfadado! mejor que optimizar esta un poco primero." Inmediatamente la gente puede ver si un cambio que hicieron tuvo un impacto en la velocidad de fotogramas, y acabamos de enviar el juego a 30 fps.
7. No es un error, es una función! - Philip Tan
He trabajado en un juego de rol en el que estábamos tratando de conseguir los NPCs (personajes no jugadores) para detectar cuando usted estaba en el rango, camina hacia ti, y entablar una conversación con usted por la activación del sistema de diálogo.
Nos olvidamos de agregar el código para distinguir los PNJ (Personajes de la PC del jugador), por lo que íbamos a pie a la ciudad y todos los puntos de contacto estaría hablando unos con otros. Debido a que todo el código de la APN de IA usaba la plantilla de diálogo misma, que en realidad tiene un par de frases antes de que las conversaciones se hizo absurda. Y debido a que fue transmitido en carácter de diálogo, ud podia leer todo lo que decían si estaban en el rango.
Hemos decidido convertir ese error en una de las principales características.
8. Acciones sucias - Tim Randall (Desarrollador @ Encore)
El equipo de motor en Gremlin Interactive mantiene un guante en su oficina. Cuando alguien le preguntó por qué estaba allí, se les dijo que sólo se usaba cuando alguien estaba a punto de escribir algo de código muy sucio. No era tanto un caso de no querer dejar huellas dactilares, sino más bien que no quería tocar en realidad correcciones muy sucias!
A continuación se presentan algunas anécdotas clásicas y consejos - muchas gracias a Brandon Sheffield quien originalmente elaboró este artículo en Gamasutra. He reposteado algunas de sus historias y tambien tiene añadido un poco más de las nuevas fuentes. También he enlazado en cada historia a la página principal del autor o blog siempre que sea posible.
1. El antihéroe de programación - Noel Llopis
Yo estaba recién salido de la universidad, todavía húmeda detrás de las orejas, y estaba a punto entrar en la fase beta de mi primer proyecto profesional del juego - un título a finales de los años 90 para PC. Había sido un viaje en montaña rusa emocionante, ya que en los proyectos a menudo son así. Todo el contenido estaba dentro y el juego se ve bien. Había un problema: Estábamos muy por encima de nuestro presupuesto de la memoria.
Dado que la mayoría de memoria fue recogida por los modelos y texturas, se trabajó con los artistas para reducir la huella de la memoria del juego tanto como sea posible. Hemos reducido las imágenes, modelos y texturas diezmadas comprimido. A veces lo hicimos con el apoyo de los artistas, y, a veces encima de sus cadáveres.
Cortamos megabytes después de megabytes, y después de unos días de frenética actividad, llegamos a un punto en que sentía que no había nada que pudiéramos hacer. A menos que cortar un poco de mayor contenido, no había manera de que pudiéramos liberar memoria más. Exhausto, se evaluó el uso de nuestra memoria actual. Todavía estábamos 1,5 MB por encima del límite de memoria!
En este punto, uno de los programadores más experimentados del equipo, quien había sobrevivido a muchos años de desarrollo en los "buenos viejos tiempos", decidió tomar el asunto en sus propias manos. Él me llamó a su oficina, y se encamina por lo que me imaginaba sería otra agotadora sesión de la liberación de memoria.
En cambio, trajo a colación un archivo de origen y se refirió a esta línea:
static char buffer[1024*1024*2];
"¿Ves esto?" dijo. Y luego se elimina con una sola tecla. ¡Hecho!
Probablemente vio el horror de mis ojos, así que él me explicó que había dejado de lado esos dos megabytes de memoria al inicio del ciclo de desarrollo. Sabía por experiencia que siempre era imposible cortar contenido a los presupuestos de la memoria, y que muchos proyectos había estado a punto de fallar a causa de ella. Así que ahora, como una práctica regular, el siempre pone a un lado un bonito bloque de memoria para liberar cuando es realmente necesario.
Salió de la oficina y anunció que había reducido el consumo de memoria dentro de las limitaciones presupuestarias - se le brindó como el héroe del proyecto.
la práctica Tan horrorizado como yo estaba en ese entonces sobre tal "barbaridad", tengo que admitir que estoy calentando a la misma. No he entrado en el estado de ánimo en el que puede ponerla en uso todavía, pero puedo ver cómo a veces, cuando estás contra la pared, con un poco de memoria escondida para un día lluvioso puede marcar la diferencia. qué gracioso es ver como el tiempo y la experiencia, cambia todo.
2. Caché para arriba - Andrew Russell
Para mejorar el rendimiento cuando se están procesando las cosas en un ciclo cerrado, quieres hacer que los datos para cada repetición lo más pequeño posible, y lo más cerca posible entre sí en la memoria. Eso significa que el ideal es una matriz o un vector de objetos (no punteros) que contienen sólo los datos necesarios para el cálculo.
De esta manera, cuando la CPU obtiene los datos para la primera iteración del bucle, para las siguientes iteraciones muchas líneas de datos son cargados en la memoria caché de la misma.
Realmente no hay mucho que puedas hacer con el uso de pocas y mas rápidas instrucciones porque la CPU es lo más rápida que vas a conseguir, y el compilador no puede ser mejorado. La coherencia de caché es donde está - este artículo contiene un buen ejemplo de coherencia de caché para obtener un algoritmo que no se limita a ejecutar a través de los datos de forma lineal.
3. Planee sus distracciones - Jay Barnson
El Internet es una de las mejores herramientas que se han inventado, tanto para la mejora de la productividad y su destrucción. Twitter y los foros y blogs y sitios web institucionales puede ser muy motivacionales y educativos, pero también pueden ser una distracción que destruye por completo toda esperanza de conseguir cualquier cosa hecha. Una cosa que he hecho en el pasado que ha demostrado ser muy exitosa es ceñirse a un plan para cuando puedo pasar algunos minutos consultar el correo electrónico y Twitter, o jugar una partida rápida o algo así. Ya sea en la realización de una tarea, o después de un período de tiempo (por ejemplo una de cinco minutos por cada hora). De lo contrario, el único uso del navegador es para la lectura de las páginas de referencia del manual, si es necesario. De esa manera convertir una distracción potencial en una herramienta de motivación.
4. El daño colateral - Jim Van Verth (@ cthulhim)
Debido a que la cámara estaba usando la velocidad y la aceleración y era chocable, loderivado de nuestra clase PhysicalObject, que tenía esas características. También tenía otra característica: PhysicalObjects podría recibir daño. Los ataques aéreos hizobastante daño en un radio lo suficientemente grande que fueron literalmente "matar" ala cámara.
Hice arreglar el fallo, asegurando que las cámaras no podían recibir daño, pero sólo para estar seguro, que aumentó su armadura y puntos de vida a niveles ridículos. Creo que puedo decir con seguridad que tenía la cámara más dura en cualquier juego.
5. El ciego guiando al ciego - Mauricio Gomes
En la universidad había un equipo que hizo un juego flash FPS. Por alguna extraña razón, el programador, en lugar de comprobar si el personaje estaba chocando con la pared y dejar que ir allí, lo hizo a la inversa, él comprobó si había una pared, y sólo se permite que se mueva paralelo a ella!
Esto provocó un error extraño: en los cruces o uniones T en el nivel, en realidad no se podía cruzar, sólo recurren a la aprobación a la izquierda oa la derecha. La fecha límite se acercaba, y no tenían ni idea de cómo solucionarlo.
A continuación, el escritor del equipo solucionado el problema, dijo al artista que añadiera una animación de las manos tocando las paredes, y luego añadió en la historia de fondo que el personaje principal era ciego y tenía que tocar constantemente las paredes para saber a dónde iba.
6. No te gusto cuando estoy enojado - Waanders Nick
Una vez trabajé en THQ Relic Entertainment estudio en conjunto, que algunos recordarán como uno de los primeros juegos para la Xbox 360. Comenzamos con un motor de PC (único - subproceso), y tuvimos que convertirlo en un juego completo en una nueva generación de núcleos múltiples de la consola en unos 18 meses. Unos tres meses antes de su envío, que todavía estaban en curso en alrededor de 5 disparos en el 360. Obviamente este juego necesita alguna optimización enorme.
Cuando hice algunas mediciones de desempeño, se hizo evidente que tanto como el código fue lento y muy "PC", también hubo un montón de problemas en el lado del contenido. Algunos modelos eran demasiado detalladas, algunas sombras eran demasiado costosos, y algunas misiones sólo tenía a muchos chicos dando vueltas.
Es difícil convencer a un equipo de 100 personas que los programadores no puede limitarse a "arreglar" el rendimiento del motor, y que algunas de las maneras que la gente se había acostumbrado a trabajar necesitaba ser cambiado. La gente necesita entender que el rendimiento del juego era un problema de todos, y pensé que la mejor manera de hacerlo es con un poco de humor que tenía un poco de la verdad oculta detrás de él.
La solución me llevó una hora. Un programador de compañeros tomó cuatro fotos de mi cara, uno muy feliz, normal, un poco enojado uno, y uno donde estoy tirando de mi pelo. Pongo esta imagen en la esquina de la pantalla, y que estaba vinculada a la velocidad de fotogramas. Si el juego corría a más de 30 cuadros por segundo, me sentí muy feliz, si corriera por debajo de 20, yo estaba enojado.
Después de este cambio, la cuestión pasó de todo FPS, "¡Ah, los programadores se lo arreglaran". que, "Hmm, si pongo este modelo en, Nick va a estar enfadado! mejor que optimizar esta un poco primero." Inmediatamente la gente puede ver si un cambio que hicieron tuvo un impacto en la velocidad de fotogramas, y acabamos de enviar el juego a 30 fps.
7. No es un error, es una función! - Philip Tan
He trabajado en un juego de rol en el que estábamos tratando de conseguir los NPCs (personajes no jugadores) para detectar cuando usted estaba en el rango, camina hacia ti, y entablar una conversación con usted por la activación del sistema de diálogo.
Nos olvidamos de agregar el código para distinguir los PNJ (Personajes de la PC del jugador), por lo que íbamos a pie a la ciudad y todos los puntos de contacto estaría hablando unos con otros. Debido a que todo el código de la APN de IA usaba la plantilla de diálogo misma, que en realidad tiene un par de frases antes de que las conversaciones se hizo absurda. Y debido a que fue transmitido en carácter de diálogo, ud podia leer todo lo que decían si estaban en el rango.
Hemos decidido convertir ese error en una de las principales características.
8. Acciones sucias - Tim Randall (Desarrollador @ Encore)
El equipo de motor en Gremlin Interactive mantiene un guante en su oficina. Cuando alguien le preguntó por qué estaba allí, se les dijo que sólo se usaba cuando alguien estaba a punto de escribir algo de código muy sucio. No era tanto un caso de no querer dejar huellas dactilares, sino más bien que no quería tocar en realidad correcciones muy sucias!
No hay comentarios:
Publicar un comentario