El software es la pieza fundamental que encaja en el hardware moderno. Muchos sistemas sacan partido de las prestaciones que da el hardware específico de las computadoras actuales y entonces como resultado vemos programas francamente espectaculares. Entre los programas que más llaman la atención son los videojuegos, los cuales tienen su propia lógica.
Muchas veces hay que escribir rutinas en ensamblador (el lenguaje anterior al de máquina), porque la respuesta del sistema debe ser inmediata. Hacer por ejemplo, un juego en donde el usuario debe disparar su arma presionando alguna tecla del teclado o botón del joystick, debe responder inmediatamente, porque la acción que está ocurriendo lo requiere. Así, programar videojuegos es toda una ciencia y también un arte.
Por ello es interesante ver lo que dice el cofundador de iD Software, John Romero, creador de programas como Doom o Quake, al respecto de los principios de programación que deben regir esta actividad si se quiere tener éxito.
Cabe señalar que el éxito de iD Software no puede ponerse en duda, pues en su momento hicieron programas que se vendieron como pan caliente y probaron que con un equipo pequeño se pueden lograr maravillas si se trabaja con disciplina y siguiendo algunas de las que bien podrían considerarse “mejores prácticas” las cuales, hoy en día quizás podrían ponerse en tela de juicio. Pero veamos que dice Romero:
- No haga prototipos. Solamente escriba el juego. Púlalo en la medida que va haciendo el desarrollo. No espere pulirlo después. Mantenga constantemente código que pueda ser enviado [para poderse ejecutar].
- Envíos continuos e integración. Es increíblemente importante que su juego pueda ser jugado por su propio equipo. Haga sus mecanismos a prueba de errores. Dé puntos de default cuando ocurre un error de carga.
- No rompa el desarrollo. Mantenga si código absolutamente simple. Siempre vea sus funciones y busque simplificarlas. Use tiempo para simplificar su código.
- Grandes herramientas hacen los grandes juegos. Use tanto como pueda las herramientas de desarrollo.
- Sea su propio equipo de pruebas. Nosotros somos nuestro propio y mejor equipo de pruebas y no deberíamos permitir nunca que otros experimentaran bugs o vieran que el juego se “congela” o se “bloquea”. No haga perder el tiempo a los demás. Pruebe siempre tanto como pueda antes de verificar su código. Tan pronto como vea un bug, corríjalo. No continúe si no ha hecho esto. Si no se corrigen los errores, el nuevo código estará sobre una base con errores y esto llevará a un sistema inestable evidentemente.
- Use un sistema de desarrollo superior al objetivo del desarrollo. Esto fue muy importante en los años 90s del siglo pasado, cuando las computadoras en promedio eran mucho más lentas (y baratas) que los sistemas de alto poder.
- Escriba su código para este juego. No escriba su código pensando en un juego futuro. Más tarde escribirá nuevo código usando la experiencia anterior, lo que lo hará más inteligente.
- No escriba muchas bibliotecas. Encapsule la funcionalidad para asegurar la consistencia del diseño. Esto minimiza los errores y ahorra tiempo en el diseño. Así habrá menos partes movibles.
- Trate de codificar transparentemente. Dígale a su líder cómo pretender resolver su tarea actual y busque retroalimentación y consejo. No trate la programación de un juego como si cada programador fuese una caja negra. El proyecto se puede descarrilar por las pausas o retrasos.
- Comuníquese. La programación es una forma de arte creativo basado en la lógica. Cada programador es diferente y escribirá código de forma diferente. Lo que importa es la salida. Respete las diferencias y enfóquese en los resultados.
Referencias: Blog.felipe.rs