Principios de programación de los primeros días del programa

Cuando se trata de desarrolladores de juegos, el cofundador John Romero es uno de los más influyentes. En la GDC Europe en Colonia, Alemania, Romero repasó algunos de los principios clave de programación a los que el estudio Doom se adhirió en la década de 1990.

Pero estén advertidos: Romero dijo que algunos de estos principios suenan locos para los estándares de hoy en día. Estas pautas son producto de su tiempo, pero en los 90, funcionaban para la identificación. El estudio fue capaz de crear 28 juegos en cinco años y medio con menos de 10 desarrolladores, produciendo títulos tan importantes como Commander Keen, Doom, Quake y otros.

No hay prototipos, siempre se mantiene el código de envío constante. Pulido sobre la marcha.

Hoy en día, el consejo común es hacer un prototipo, un prototipo, un prototipo. Consigue algo jugable, y encuentra la diversión. Pero para la identificación, Romero dijo que la compañía no tenía tiempo para hacer un prototipo. Los juegos que hizo el estudio eran de pequeño alcance y fáciles de visualizar en la mente del equipo, así que pasaron de la idea directamente al producto. «Hoy en día, con cualquier gran proyecto, vas a necesitar un prototipo», dijo.

Un juego llamado Quake: La lucha por la justicia fue el único juego que el equipo descartó, dijo Romero. Trabajaron en él durante dos semanas (era un RPG) antes de decidir tirarlo y seguir adelante. No volverían al universo de Quake hasta cuatro años después.

Es increíblemente importante que tu juego siempre pueda ser dirigido por tu equipo. A prueba de balas tu motor, proporcionando fallos de carga por defecto.

Romero repetidamente enfatizó la importancia de encontrar formas de aumentar la eficiencia, incluyendo asegurarse de que el juego pueda ser ejecutado por su equipo.
Mantenga su código absolutamente simple. Sigue mirando tus funciones y descubre cómo puedes simplificarlo aún más.

Una vez más, la simplificación es importante. No sólo en el código, sino también en el diseño del juego y en los procesos de producción.
Las grandes herramientas ayudan a hacer grandes juegos. Dedica el mayor tiempo posible a las herramientas.

«Somos nuestro mejor equipo de pruebas, y nunca debemos permitir que nadie más experimente errores o vea el fracaso del juego», dijo Romero. «No malgastes el tiempo de los demás. Prueben a fondo antes de comprobar su código».

Añadió: «En cuanto ves un error, lo arreglas. No sigas adelante. Si no arreglas tus errores, tu nuevo código se construirá sobre una base de código de errores y asegurará una base inestable».
Utiliza un sistema de desarrollo superior al de tu objetivo para desarrollar tu juego.

Aunque el objetivo de Doom era el MS-DOS, Romero dijo que Doom fue desarrollado bajo el sistema operativo más avanzado NextStep, que fue el predecesor del OS X.
Escribe tu código sólo para este juego, no para un juego futuro. Vas a escribir un nuevo código más tarde porque serás más inteligente.

Reutilizar el código de un juego a otro no tenía sentido para un equipo que se dedicaba a la optimización para la situación en cuestión. (Y, por supuesto, no había ninguna unidad o motor irreal para licenciar.)

La programación es una forma de arte creativo basada en la lógica. Cada programador es diferente.

¡Se explica por sí mismo! Durante una sesión de preguntas y respuestas, un desarrollador de juegos en ciernes preguntó si Romero se había quemado alguna vez debido al furioso ritmo de desarrollo del juego. Romero explicó el tipo de programador que es… le encanta programar tanto que nunca se quemó. Y otra cosa a tener en cuenta: Hubo mucho trabajo antes de que el juego más famoso de id, Doom. Wolfenstein fue su juego número 87; Doom fue su juego número 90, dijo.