mayo 23, 2008

El Software y los errores


Sin caer en el egocentrismo, o al menos lo intento, he de decir que crear Software, sea de la clase que sea, es una de las actividades más complejas que he visto... o al menos más propensas a error.

Cuando un desarrollador está codificando, cada una de las líneas que crea es una posibilidad más de equivocarse, se puede decir que si se escriben cientos de lineas de código diariamente, la posibilidad de que te equivocarse es bastante alta pasados unos cuantos días, no digamos años!.

Si pensamos que crear un juego lleva años de trabajo por decenas de programadores, la posibilidades de ocurran bugs son tan altas que siempre hay errores en el código. Esto es algo que hay que aceptar, lo que hay que intentar es corregirlos a posteriori de la forma más eficientemente posible, no queda otra.

Pues bien, uno de los departamentos que tienen más importancia en la creación de un juego (y de un producto en general) es QA (Quality Assurance) o "aseguramiento de la calidad" dicho en un Español un poco cutre control de calidad (gracias Jabatus :P).

Normalmente esta gente son probadores natos de la aplicación o del juego, y reportan los errores encontrados de una forma lo suficientemente clara como para que el desarrollador pueda replicar el bug y corregirlo (es una disciplina para la que se necesita ser muy organizado y probar sistemáticamente, nada sencillo).
Últimamente he leído en más de un sitio (mis amigos de AkihabaraBlues, por ejemplo), que los estudios prefieren lanzar los juegos aunque tengan errores y después sacar parches para corregirlo a esperarse a hacer las cosas bien y sacar los productos muchos más finos.Yo no estoy de acuerdo con ese punto de vista.

Cada vez son mayores los desarrollos y cada vez más complejos los juegos, por lo que es practicamente imposible que unos cuantos probadores den con la misma cantidad de errores que van a encontrar los usuarios en la calle, simplemente es impracticable en un periodo razonable de tiempo.
El problema en realidad, es que los juegos son tan complejos y se pueden dar tal cantidad de situaciones distintas, que es muy difícil asegurar que se hayan probado la mayoría de situaciones posibles, y por lo tanto no se puede estar seguro de la calidad del producto.

Sin embargo, cuando el juego está en la calle se tienen miles o cientos de miles, o en los mejores casos hasta millones de probadores reportando en BLOGS, Vídeos en YouTube y cualquier otro medio cuales son los fallos más gordos en un juego. Es entonces cuando los estudios pueden corregirlos.

4 comentarios:

Jabatus dijo...

¿Control de calidad, puede ser? Suena mejor :D

Y no, lo que se discute no es si un juego puede o no estar libre de errores, que, como cualquier aplicación es casi (...) imposible.

Lo que se discute es que como es posible que un juego salga al mercado sin estar terminado. Porque vale, errores puede haber, pero muchos son garrafales. No es lo mismo un error (o varios, puntuales) que cientos de ellos, muchos de los cuales te impiden progresar en el juego. Y eso es un problema de mercado; tú deberías saber cuanto cuesta (económicamente) desarrollar cualquier tipo de aplicación.

A las empresas desarrolladoras no les interesa mantener más tiempo del estrictamente necesario a los desarrolladores trabajando en un mismo proyecto que, a medio plazo, dejará de generar ingresos.
Rotación...de eso se trata, y, uno de los puntos fuertes de las discusiones que comentas es que esto es algo fácilmente subsanable con la banda ancha que hace unos años no existía, o no estaba tan extendida.

Un saludo, y muy buen blog ;)

JmSlay dijo...

Hola jabatus,
Muchas gracias...
En realidad creo que en este caso se pueden encontrar ejemplos en las que por un lado no se haya terminado bien el producto (como tu bien dices) y otros ejemplos en los que hacer un testeo de un juego sea suficientemente complejo como para que los Bugs que se cuelan sean perfectamente comprensibles.

Existen errores como en el caso de Assasins Creed (para mi, una gran decepción) en los que en determindas plataformas el juego tenia mayores BUGs que en otras, eso probablemente sea porque no se ha probado igual en todas las plataformas el producto. Y aquí entraríamos en el debate de si juegos en distintas plataformas son realmente (como quieren hacer creer algunos estudios) productos distintos desarrollados por equipos distintos o realmente son "casi el mismo" producto desarrollado por casi el mismo equipo.
Creo que los costes en esta generacion son tan desorbitados que en algunos casos hay que sacar el producto porque no hay más tiempo, ni dinero para seguir refinandolo, aunque quiero pensar que no siempre es así.

Dagarin dijo...

Acabo de descubrir tu blog por casualidad y de entrada felicitarte por el. Estupendo, si señor.

Respecto a este post, quizás porque lo leo algo mas tarde de su publicación, para mi un claro ejemplo de lo que dice Jabatus es el Alone in the Dark, que acabo de dar por imposible hace unos dias. Insufrible la cantidad de bugs, el pésimo control y la horrorosa camara del juego. En cambio, hay fases que se ven mucho mas depuradas, pero otras son simplemente bocetos de lo que los programadores estoy seguro que hubiesen querido.

Y creo que toda la culpa la tiene el maldito marketing, el dinero y los plazos. Ya había sufrido varios retrasos y creo que algún directivo simplemente dijo "compiladlo y a copiar, esté como este. No admitimos mas retrasos". Un par de meses mas de desarrollo y el juego hubiera sido estupendo, pero no podían esperar mas.

Es una lastima. Quizás porque fui programador durante 13 años entiendo que un programa infalible es imposible. Entiendo los bugs de assasins, del GTA y de todos los juegos de ese estilo. Cuando se trata de un mundo tan abierto y con tantas posibilidades es practicamente imposible contemplar todas las variables, pero lanzar juegos inacabados si me parece un delito.

Un saludo.
(www.dagarin.com)

JmSlay dijo...

Hola Dagarin, muchas gracias por los comentarios.

Solamente las empresas con las cuentas muy saneadas pueden permitirse el lujo de sacar un juego "When Is Done", como hace Blizzard por ejemplo.
El caso es que incluso en los magníficos juegos de Blizzard, que tienen suficiente tiempo para hacer las cosas bien, no es de extrañar los "Patches" posteriores para mejorar el juego o corregir Bugs.
El caso de Alone In The Dark, tienes toda la razón, es el típico en el que entre el Hype, las falsas expectativas y el pobre resultado final una vez con el juego en las manos, se cargan lo que podría haber sido y no fué...

En ese caso los Bugs insufribles, como tu dices, y la jugabilidad prácticamente nula hacen que el juego no sea mas que una versión Alfa (ni Beta) venida a más, muy probablemente por que alguien decidió que ya no había ni un dolar más para desarrollo, efecto directo de desarrollos con costos astronómicos. Una pena.