En esta publicación, compartiré cómo llevé mi juego Flash Frog Fractions a la plataforma moderna. Como resultado, creé un puerto parcialmente automatizado en Unity usando Haxe. La publicación será de interés para cualquiera que intente actualizar su código base a Flash. La publicación contendrá spoilers sobre la estructura de Frog Fractions: Game of the Decade Edition y su DLC Hop's Iconic Cap .
Después de que Frog Fractions 2 no lograra hacerme rico, pasé aproximadamente un año trabajando por contrato y haciendo bocetos / prototipos . Luego, mi esposa quedó embarazada y decidí que era hora de encontrar un trabajo real para poder mantener a mi familia. Antes del inicio de GDC 2018, yopublicó un tweet sobre la búsqueda de trabajo , con la esperanza de encontrar a las personas adecuadas en la conferencia. Me entrevistaron en varios lugares, pero lo más importante fue que pude encontrar financiación para mi próximo proyecto.
El proyecto era así: esconde el próximo juego de Frog Fractions dentro de Frog Fractions 1 y véndelo en Steam.
Frog Fractions tiene aproximadamente 13k líneas de código en Actionscript 3 y está construido usando el compilador Flex. Pensé que después de agregar nuevo contenido de remasterización, el volumen se triplicaría, a aproximadamente 40k líneas de código. (Y mi estimación resultó ser bastante precisa: resultó en 28k de código C # y 3k de líneas de scripts para escenas de corte / árboles de diálogo además del juego original).
Consideré varias opciones posibles para seguir trabajando:
- AS3 Adobe AIR. , :
- Frog Fractions 640x480. . 2012 , , 2020 Steam .
- Flex , 10k , . 40k ? ( , , .)
- Flash . AIR 2020 ? (, ! .)
- , - . , Scaleform (The Banner Saga, Road Not Taken), , Scaleform - 2020 . (, 2018 Autodesk Scaleform, — UI.)
- Flash VM -. Flash , . Ruffle. , ?
- C#/Unity. .
- : Flash, , Unity. , «-» . , , , Unity, Windows. ( , , , TCP- . Flash , , Unity, .)
- Haxe OpenFL. as3hx AS3 Haxe, OpenFL Flash API. OpenFL , .
Quiero enfatizar aquí que todos estos enfoques se basaron en el hecho de que Frog Fractions era esencialmente un programa que escribí para compilar en SWF. No puedo juzgar cómo mi solución es aplicable a su juego, si es una línea de tiempo de animación Flash, cuya interactividad es proporcionada por scripts.
Pedí consejos sobre cómo avanzar, y el más útil me lo dio Lars Duset, quien, entre otras cosas, dijo que Haxe tiene un backend C # y su plataforma de destino podría ser Unity. También me aconsejó que primero creara un flujo de trabajo y trasladara un pequeño proyecto usándolo.
(Nota para mí mismo: agregue a Lars Dusset a los créditos del juego. No podía imaginar el impacto que tuvo en el proyecto hasta que releí nuestra correspondencia).
Después de una semana de experimentar, pude ejecutar Frog Infarctions (un juego que escribí en el juego de 0 horas de Sosa Sosovski) en el editor de Unity. El resultado no fue perfecto, pero fue suficiente para comprender la viabilidad de la implementación, así que comencé a trabajar en el proyecto principal.
Así es como resultó mi flujo de trabajo. Estas operaciones deben realizarse una vez:
- Utilice as3hx para convertir el código de AS3 a Haxe.
- Si es necesario, limpie manualmente el código as3hx generado.
Después de eso, realice iterativamente las siguientes operaciones:
- Transfiera su base de código a Haxe para usar la API de Unity en lugar de la API de Flash.
- C#- Haxe Haxe C#. Haxe, UnityEngine.dll, API hx. Assembly-Csharp.dll C#, .
- Unity.
La primera semana de trabajo fue muy tediosa, tenías que limpiar las expresiones que as3hx marcaba como inconsistentes, corregir los errores del compilador que agregaba y lidiar con las llamadas de E / S. Corregir errores en Haxe no es perfecto, por lo que hubo alrededor de 30 errores cada vez que intenté compilar, sin importar cuánto lo intenté, por lo que no tenía idea de qué tan cerca estaba de finalización hasta que todo se compiló sin errores. Además, me parece que as3hx es un traductor de búsqueda y reemplazo y no un transpilador real con traducción hacia y desde AST, porque parece agregar errores como colocar el código en el lado equivocado del paréntesis cuando está en mi El control de flujo utiliza un estilo específico de corchetes.
Una vez hecho esto, obtuve un código base de Haxe que se compila con éxito en un objetivo C #. Después de eso, nunca toqué el código AS3. (Excepto por el proceso de exportación de activos gráficos que se describe a continuación). En este punto, decidí deshacerme de Haxe y simplemente trabajar en C #, pero aunque la salida de as3hx es bastante similar al código original con el estilo de paréntesis, el orden del código y los comentarios conservados, C # obviamente no está diseñado para el ojo humano. Entonces, de ahora en adelante, si no creaba nuevas escenas, editaba el código Haxe y lo compilaba en C #.
En este punto, el código se compiló y ejecutó en el motor de Unity, pero sin E / S. El siguiente paso fue recrear todo el código de E / S utilizando la API de Unity. Esto y la conversión de recursos tomó alrededor de cuatro meses, principalmente porque hay muchos tipos de recursos diferentes en Frog Fractions:
- Gráficos vectoriales dibujados en el editor de Flash. Lo rendericé como 4k, haciendo que AIR construyera el juego original, pero sin hacer nada más que renderizar los cuadros de animación y escribirlos en archivos PNG. Luego, usando un TexturePacker, los ensamblé en hojas de sprites.
- , Flash Shape API. Flash , , Photoshop . . Unity . , , 9-slices, .
- SVG, OpenClipArt.org. , , .
- , Flickr. preserve details Photoshop, , 4k- , .
- . , . , 4k. , , — !
- . Flash- , Marching-Cubes . 4k, , . , .
- , .
- . 2015 Unboxing Story Unity API . 2018 . !
- . .wav .
- MP3 64kbps mono, , , Amazon S3, , OST.
Todo en el remaster, excepto los sombreadores de pantalla completa y la reproducción de video, y la mayor parte de la nueva historia se procesa usando llamadas Graphics.DrawMesh, no como objetos en el gráfico de escena de Unity. Entonces, la pregunta es, ¿Es Unity realmente la opción adecuada para este proyecto?
Mientras Craig Tympani y yo elegíamos el motor para Glittermitten Grove , nos decidimos por Unity debido a su buen soporte multiplataforma, porque FNAaún no está listo, y porque construir tu propio motor es una excelente manera de nunca terminar un juego. Al final, aunque me entristeció el pobre soporte 2D en Unity, nos permitió lanzar versiones para Mac y Linux casi sin problemas, lo que en mi opinión es un gran éxito. (Es de suponer que el apoyo 2D en la Unidad ha mejorado desde 2015, pero no he estudiado. Graphics.DrawMesh bien funciona para mí. Tal vez incluso FNA ahora tiene una canalización de procesamiento de recursos de trabajo!)
Para este proyecto, he elegido la Unidad principalmente por inercia - No quería molestarme en estudiar un nuevo motor, porque tenía que implementar el proyecto de investigación descrito anteriormente; Unity es compatible con todas las plataformas a las que quería portar el juego, incluidas las consolas.
¡Ah, y luego creé un juego adicional! Probablemente hablaré sobre este proceso creativo en otra publicación, aquí solo mencionaré que armé una escena de transición en Haxe y escribí el resto del nuevo juego en C #. Además, hice cambios significativos en el menú principal dentro del código base de Haxe. Por lo tanto, me parece que es bastante posible, después de la migración a Haxe, continuar lanzando actualizaciones de código haciendo desarrollo en Haxe.
También realicé algunas optimizaciones en el código original. El código AS3 se escribió deliberadamente sin tener en cuenta la eficiencia porque estaba tratando de evitar luchar por un "código impecable". Por ejemplo, ¡no podía creer que pudiera salirse con la suya asignando un Vector2 para el montón en cada operación aritmética! El resultado resultante funcionó bien en las computadoras de 2012, pero las partes con peor rendimiento después de la doble transpilación causaron una carga significativa, por lo que para trabajar bien en las PC modernas tuve que reescribir parte del código en C # nativo.
También vale la pena señalar que si no hubiera planeado expandir significativamente el tamaño del juego original y solo estuviera tratando de evitar que muera junto con Flash, entonces OpenFL, AIR o Ruffle probablemente serían una opción más inteligente.
Lanzar el juego fue como despedirse de ella. Disfruté trabajando en Flash. En ese momento, era la mejor manera de mostrar sus juegos a las personas con el menor esfuerzo y parecía que iban a vivir para siempre: SWF de los años 90 todavía funciona perfectamente en el último reproductor Flash, a pesar de que han pasado décadas. Ver cómo el mundo intentaba pasar a HTML5 cuando claramente no estaba preparado para ello era insoportable. (Y, francamente, las cosas empeoran en lugar de mejorar . Creo que el navegador nunca volverá a ser una plataforma jugable mientras los propietarios de los dos navegadores más populares tengan sus propias tiendas de aplicaciones para teléfonos). Creé un remaster en parte debido a esto. que quería vender un juego nuevo, pero también por un deseo sincero de mantener su parte en la historia del juego. ¡Gracias por volver conmigo!