DEVELOPMENT DIARY 2: THE PORTING PROCESS

The development of Ginger starts, as is usually the case in all multiplatform titles, with the PC version. Unity makes it quite easy to convert the game to each of the existing versions, although there are several things to keep in mind.

One of the vital aspects of good conversion is, of course, the technical one. It is necessary to be very clear about the differences between the hardware of each platform so that the game looks and works correctly, without any slowdowns or graphical errors; thanks to Unity, the ports between each platform is relatively simple, but you always have to polish the performance, adapt visual elements, add new menus, make sure that the way of showing graphics (which is usually different in each console) is adequate and you left nothing “lost in translation”… There are things that are fast on PC and slow on console or vice versa! You have to manage loading times, amount of resources required by each scene in the game, make sure the amount of elements on screen doesn’t affect the speed and/or gameplay)… In short, you have to manage all the resources at your fingertips so that each of the scenes in the game are displayed correctly and, of course, move at an acceptable and constant speed.

 

And that, only, as far as the look and feel of the game is concerned. There are a series of requirements imposed on the console that cannot be ignored in any case, such as console specific control systems: each action must be associated with each of the buttons and also be tagged on screen, depending on the system. It will also be necessary to program what the game will do if the controller is turned off, if a new control system is connected… Simple elements can become big problems when it comes to converting a game from PC to console.

 

Something as simple as the game save/load system also has to comply with a series of rules: it must be adapted to each of the systems following the guidelines imposed by each of the console companies; in most cases you can follow a template or develop a specific system, always complying with the rules.

 

For better or worse, each of the manufacturers offers some kind of style guide to which you have to adhere; each company imposes a series of technical and visual requirements to which you have to adjust each title, otherwise the last test before the game sees the light, the fateful quality control (or QA), may not be surpassed. Sometimes, updating the Unity engine is what causes the game to “break” at a certain point in time; if this happens, there’s no choice but to rewrite that part or otherwise program it so that the new version of the engine doesn’t ruin the experience. There are situations in which you have to remake much of the game by elements introduced in new versions of Unity… there is no choice there!

 

Needless to say, if the game doesn’t exceed the strict QA of each company… you’ll have to start again! It is necessary to correct the reason why the game has not passed the quality control and, once again, to pass the relevant tests in the manufacturer’s control. Doesn’t it now make more sense when a particular game is delayed by one or two months for no apparent reason?

 

While for Steam it’s enough with the quality control that is carried out, in a conscientious way, of course, from the development team or company that launches the game, each console manufacturer has its own QA department who verifies if the game follows that style book we mentioned, if all the menus are in place, if the graphical load doesn’t ruin the experience, if the game is not hung every now and then. Also, each console has a digital store for which you have to design a series of elements in order to comply with the rules… and let the game draw attention to itself so that it can be sold!

At this point you’ve probably already achieved a good number of trophies and/or achievements… Well, you have to include that in the console versions too: you have to define the requirements to get each one of the trophies, the amount of points given to the player with each achievement, etc…

And don’t think that the programmers’ work ends once all the quality controls have been surpassed and the game finally reaches the stores: the feedback of each user has to be taken into account and small bugs have to be fixed through updates and patches. We’ll tell you a secret: there’s no such thing as a perfect game… and the developer work never ends!

 


 

El desarrollo de Ginger arranca, como suele ser habitual en casi todos los títulos multiplataforma, con la versión para PC; Unity pone las cosas bastante fáciles a la hora de convertir el juego a cada una de las versiones existentes, aunque hay que tener varios elementos en cuenta.

Uno de los apartados vitales a la hora de realizar una buena conversión es, lógicamente, el técnico. Hay que tener muy claras las diferencias entre el hardware de cada plataforma para que el juego tenga el aspecto deseado y funcione correctamente, sin ralentizaciones ni fallos gráficos; gracias a Unity, el salto entre cada plataforma es relativamente sencillo, pero siempre hay que pulir el rendimiento, adaptar elementos visuales, añadir nuevos menús, asegurarnos de que la forma de mostrar los gráficos (que suele ser diferente en cada consola) es adecuada y no “se pierde” nada en la conversión… Hay algunas cosas que en PC son rápidas y en consola lentas… ¡y al contrario! Hay que gestionar correctamente los tiempos de carga, la cantidad de recursos que exige cada situación en el juego, que la cantidad de objetos en pantalla no suponga un lastre (y afecte a la velocidad y/o la jugabilidad)… En resumen, hay que gestionar todos los recursos a nuestro alcance para que cada una de las escenas del juego se muestren correctamente y, por supuesto, que se muevan a una velocidad aceptable y constante.

 

Y eso, únicamente, en lo que respecta al “feeling” del juego. Hay una serie de requerimientos impuestos en consola que no se pueden obviar en ningún caso, como por ejemplo la adaptación de los controles a los mandos de consola: hay que asociar cada acción a cada uno de los botones y “etiquetarlos”, dependiendo del sistema al que adaptemos el juego, para que el usuario no se líe. También será necesario programar lo qué hará el juego si se apaga el mando, si se conecta un nuevo sistema de control… Elementos “cotidianos” y simples se pueden llegar a convertir en grandes problemas a la hora de convertir un juego a consola.

 

Algo tan sencillo como el sistema con el que se guarda y se carga la partida también tiene que cumplir una serie de normas: debe estar adaptado a cada uno de los sistemas siguiendo las pautas impuestas por cada uno de los “fabricantes”; en la mayoría de los casos se puede seguir una especie de plantilla o desarrollar un sistema de guardado y cargado propio, pero siempre dentro de las normas de cada consola.

 

Y es que, por suerte o por desgracia, cada uno de los fabricantes ofrece una especie de “libro de estilo” al que hay que ceñirse; cada compañía impone una serie de requisitos técnicos y visuales al que hay que ajustar cada título, de lo contrario, la última prueba antes de que el juego vea la luz, el fatídico control de calidad (o QA, por sus siglas en inglés) puede no ser superada. En ocasiones, la actualización del motor Unity es lo que provoca que el juego “se rompa” en un determinado momento; si esto ocurre, no queda más remedio que reescribir esa parte o programarla de otra forma para que la nueva versión del motor no acabe con la experiencia de juego. Hay situaciones en las que hay que rehacer gran parte del juego por elementos introducidos en nuevas versiones de Unity… ¡no queda más remedio!

Ni que decir tiene que si el juego no supera el estricto QA de cada compañía… ¡a la casilla de salida! Hay que corregir el motivo por el que el juego no ha pasado el control de calidad y, hecho esto, volver a pasar las pruebas pertinentes en el control del fabricante. ¿A que ahora tiene más sentido cuando un juego determinado se retrasa uno o dos meses sin motivo aparente?

 

Mientras que para Steam es suficiente con el control de calidad que se realiza, de forma concienzuda, por supuesto, desde el equipo de desarrollo o compañía que lanza el juego, cada fabricante de consola tiene su propio departamento de QA en el que se verifica si el juego sigue ese “libro de estilo” que mencionamos, si todos los menús están en su sitio, si la carga gráfica no acaba con la experiencia, si el juego no se cuelga cada dos por tres… Y hasta que no se pasa ese control, el juego no puede lanzarse o ponerse a la venta en cada una de las tiendas digitales. Y esa es otra: cada consola posee una tienda para la que hay que diseñar una serie de elementos con el objetivo de cumplir las normas… ¡y que el juego llame la atención para que se venda!

A estas alturas seguro que ya has conseguido una buena cantidad de trofeos y/o logros… Pues eso también hay que introducirlo en las versiones de consola: hay que definir los requisitos para conseguir cada uno de los trofeos, la cantidad de puntos que da al jugador cada logro, etc.

 

Y no creáis que el trabajo de los programadores termina una vez se superan todos los controles de calidad y el juego llega finalmente a las tiendas: el feedback de cada uno de los usuarios ha de tenerse en cuenta y hay que arreglar pequeños fallos a través de actualizaciones y parches. Os contaremos un secreto: no existe el juego perfecto… ¡y el trabajo de los programadores no termina nunca!

Published
Categories Dev Diary News

Comments

No Comments

Leave a Reply