61
Traducciones y Proyectos / Re: Aventuras con sólo voces en ScummVM
« en: Diciembre 22, 2010, 16:24:01 pm »
Al parecer, no existen problemas técnicos insalvables para introducir textos en los juegos que no lo tienen. El problema es más de esfuerzo (son pocos y ya están muy ocupados) que de implementación. Voy a intentar explicar un poco lo que yo estoy entendiendo de la discusión sobre el tema en ScummVM:
De entrada, hay que tener en cuenta que estamos hablando de ScummVM, es decir, los juegos ya no funcionan con el motor con el que fueron desarrollados, sino con una implementación autónoma de ese motor desarrollado por ScummVM. Se puede hacer cualquier cosa con ellos con la suficiente paciencia.
Se estaría hablando de no tocar ni uno sólo de los scripts ni de los archivos de datos de los juegos. Los vídeos serían los mismos, sin recodificar, las voces serían las mismas, sin doblar. Todo quedaría inalterable. La transcripción de los textos se incorpora a través del motor. No es como el curro que te metiste tú, basado en modificar los scripts. En este caso no les haría falta conocer el contenido íntegro de los cripts, sólo añadir una orden en respuesta a su lectura.
Cuando el script ordena al motor que reproduzca una voz (que es un tramo de un archivo de datos identificado por una ID que cambia de un motor a otro), el motor podría ordenar que simultáneamente apareciese un texto en pantalla. A la ID del diálogo X que ordena el script leído por el motor, el propio motor le incorpora el display de un texto (cuyos datos vendrían en un archivo generado por ScummVM, y potencialmente en diversos idiomas). Por lo tanto, se haría al margen de los archivos de datos y al margen de los scripts.
Pero no todo es tan fácil, tiene diversas complicaciones obvias.
Para empezar, cada motor tiene sus circunstancias y su manera de leer los datos, no existe una solución universal (a nivel de programación, me refiero, el resultado visual sí puede ser prácticamente el mismo). Ello supone que este sistema se tendría que ir implementando motor a motor. No parece ser un obstáculo determinante, tan sólo lo haría progresar más despacio.
Además, requiere un trabajo enorme de transcripción, inasumible por los desarrolladores de ScummVM. Yo he sugerido requerir el apoyo de la comunidad de ScummVM, que es muy grande y nadie puede hacer nada realmente útil para el proyecto sin tener conocimientos muy avanzados de programación. Yo creo que ahí se podría obtener el respaldo necesario. Otra cosa es que el equipo de ScummVM, que está muy jerarquizado y "profesionalizado", esté dispuesto a hacer partícipe a cualquiera de su trabajo. Yo creo que lo mejor sería hacerlo de manera paralela sin mezclar a transciptores con desarrolladores.
La verdad es que me ha sorprendido gratamente la predisposición a al menos discutirlo, da la impresión de que no les parece mala idea. Ahora, que puedan encajarlo en su programa de trabajo para el futuro, es algo que deciden ellos.
EDIT: Por cierto, desde hoy ya funciona la opción textos+voces en Space Quest IV y Freddy Pharkas (que no tiene nada que ver con todo lo anterior).
De entrada, hay que tener en cuenta que estamos hablando de ScummVM, es decir, los juegos ya no funcionan con el motor con el que fueron desarrollados, sino con una implementación autónoma de ese motor desarrollado por ScummVM. Se puede hacer cualquier cosa con ellos con la suficiente paciencia.
Se estaría hablando de no tocar ni uno sólo de los scripts ni de los archivos de datos de los juegos. Los vídeos serían los mismos, sin recodificar, las voces serían las mismas, sin doblar. Todo quedaría inalterable. La transcripción de los textos se incorpora a través del motor. No es como el curro que te metiste tú, basado en modificar los scripts. En este caso no les haría falta conocer el contenido íntegro de los cripts, sólo añadir una orden en respuesta a su lectura.
Cuando el script ordena al motor que reproduzca una voz (que es un tramo de un archivo de datos identificado por una ID que cambia de un motor a otro), el motor podría ordenar que simultáneamente apareciese un texto en pantalla. A la ID del diálogo X que ordena el script leído por el motor, el propio motor le incorpora el display de un texto (cuyos datos vendrían en un archivo generado por ScummVM, y potencialmente en diversos idiomas). Por lo tanto, se haría al margen de los archivos de datos y al margen de los scripts.
Pero no todo es tan fácil, tiene diversas complicaciones obvias.
Para empezar, cada motor tiene sus circunstancias y su manera de leer los datos, no existe una solución universal (a nivel de programación, me refiero, el resultado visual sí puede ser prácticamente el mismo). Ello supone que este sistema se tendría que ir implementando motor a motor. No parece ser un obstáculo determinante, tan sólo lo haría progresar más despacio.
Además, requiere un trabajo enorme de transcripción, inasumible por los desarrolladores de ScummVM. Yo he sugerido requerir el apoyo de la comunidad de ScummVM, que es muy grande y nadie puede hacer nada realmente útil para el proyecto sin tener conocimientos muy avanzados de programación. Yo creo que ahí se podría obtener el respaldo necesario. Otra cosa es que el equipo de ScummVM, que está muy jerarquizado y "profesionalizado", esté dispuesto a hacer partícipe a cualquiera de su trabajo. Yo creo que lo mejor sería hacerlo de manera paralela sin mezclar a transciptores con desarrolladores.
La verdad es que me ha sorprendido gratamente la predisposición a al menos discutirlo, da la impresión de que no les parece mala idea. Ahora, que puedan encajarlo en su programa de trabajo para el futuro, es algo que deciden ellos.
EDIT: Por cierto, desde hoy ya funciona la opción textos+voces en Space Quest IV y Freddy Pharkas (que no tiene nada que ver con todo lo anterior).