Dans cet article, je vais partager comment j'ai introduit mon jeu Flash Frog Fractions sur la plateforme moderne. En conséquence, j'ai créé un portage partiellement automatisé sur Unity en utilisant Haxe. Le message intéressera tous ceux qui essaient de mettre à niveau leur base de code vers Flash. Le message contiendra des spoilers sur la structure de Frog Fractions: Game of the Decade Edition et son DLC Hop's Iconic Cap .
Après que Frog Fractions 2 n'a pas réussi à me rendre riche, j'ai passé environ un an à travailler sous contrat et à dessiner / prototyper . Puis ma femme est tombée enceinte et j'ai décidé qu'il était temps de trouver un vrai travail pour pouvoir subvenir aux besoins de ma famille. Avant le début de GDC 2018, jea publié un tweet sur la recherche d'un emploi , dans l'espoir de trouver les bonnes personnes à la conférence. J'ai été interviewé dans plusieurs endroits, mais le plus important était que j'ai pu trouver des financements pour mon prochain projet.
Le projet était comme ceci: cachez le prochain jeu Frog Fractions dans Frog Fractions 1 et vendez-le sur Steam.
Frog Fractions est d'environ 13k lignes de code dans Actionscript 3 et est construit à l'aide du compilateur Flex. J'ai pensé qu'après avoir ajouté un nouveau contenu remasterisé, le volume triplerait, pour atteindre environ 40 000 lignes de code. (Et mon estimation s'est avérée assez précise - il s'est avéré 28k code C # et 3k lignes de scripts pour les cinématiques / arbres de dialogue en plus du jeu original.)
J'ai envisagé plusieurs options possibles pour la suite des travaux:
- 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 , .
Je tiens à souligner ici que toutes ces approches étaient basées sur le fait que Frog Fractions était essentiellement un programme que j'ai écrit pour compiler en SWF. Je ne peux pas juger comment ma solution est applicable à votre jeu, s'il s'agit d'une chronologie d'animation Flash, dont l'interactivité est fournie par des scripts.
J'ai demandé des conseils sur la façon d'aller de l'avant, et le plus utile m'a été donné par Lars Duset, qui a entre autres dit que Haxe avait un backend C # et que sa plate-forme cible pourrait être Unity. Il m'a également conseillé de créer d'abord un workflow et de porter un petit projet en l'utilisant.
(Note à moi-même: ajoutez Lars Doucet au générique du jeu. Je ne pouvais pas imaginer à quel point il a eu un impact sur le projet avant de relire notre correspondance.)
Après une semaine d'expérimentation, j'ai pu lancer Frog Infarctions (un jeu sur lequel j'ai écrit le game jam de 0 heure de Sosa Sosovski) dans l'éditeur Unity. Le résultat n'était pas idéal, mais c'était suffisant pour comprendre la faisabilité de la mise en œuvre, j'ai donc commencé à travailler sur le projet principal.
C'est ainsi que mon flux de travail s'est avéré. Ces opérations doivent être effectuées une fois:
- Utilisez as3hx pour convertir le code d'AS3 en Haxe.
- Si nécessaire, nettoyez manuellement le code as3hx généré.
Après cela, effectuez de manière itérative les opérations suivantes:
- Portez votre base de code vers Haxe pour utiliser l'API Unity au lieu de l'API Flash.
- C#- Haxe Haxe C#. Haxe, UnityEngine.dll, API hx. Assembly-Csharp.dll C#, .
- Unity.
La première semaine de travail a été très fastidieuse, vous avez dû nettoyer les expressions que as3hx marquait comme incohérentes, corriger les erreurs du compilateur qu'il avait ajoutées et gérer les appels d'E / S. La correction de bogues dans Haxe n'est pas parfaite, il y avait donc environ 30 erreurs à chaque fois que j'essayais de construire, peu importe à quel point j'ai essayé, donc je n'avais aucune idée de la fin de la compilation jusqu'à ce que tout soit compilé sans erreurs. En outre, il me semble que as3hx est un traducteur de recherche et de remplacement, et non un véritable transpilateur avec traduction vers et depuis AST, car il semble ajouter des erreurs telles que placer le code du mauvais côté des parenthèses lorsque dans mon le contrôle de flux utilise un style d'accolade spécifique.
Cela fait, j'ai une base de code Haxe qui se compile avec succès vers une cible C #. Après cela, je n'ai jamais touché au code AS3. (Sauf pour le processus d'exportation des ressources graphiques décrit ci-dessous.) À ce stade, j'ai décidé d'abandonner Haxe et de travailler simplement en C #, mais bien que la sortie de as3hx soit assez similaire au code d'origine, tout en conservant le style d'accolade, l'ordre du code et les commentaires, la sortie de Haxe est C # n'est évidemment pas destiné à l'œil humain. Donc à partir de maintenant, si je n'ai pas créé de nouvelles scènes, j'ai édité le code Haxe et je l'ai compilé en C #.
À ce stade, le code a été compilé et exécuté dans le moteur Unity, mais sans E / S. L'étape suivante consistait à recréer tout le code d'E / S à l'aide de l'API Unity. Cela et la conversion des ressources ont pris environ quatre mois, principalement parce qu'il existe de nombreux types de ressources différents dans Frog Fractions:
- Graphiques vectoriels dessinés dans l'éditeur Flash. Je l'ai rendu en 4k, forçant AIR à construire le jeu original, mais ne faisant rien de plus que de rendre les images d'animation et de les écrire dans des fichiers PNG. Ensuite, à l'aide d'un TexturePacker, je les ai assemblés en feuilles de sprite.
- , 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.
Tout dans le remaster, à l'exception des shaders plein écran et de la lecture vidéo, et la plupart de la nouvelle histoire est rendue à l'aide d'appels Graphics.DrawMesh, et non en tant qu'objets dans le graphique de scène Unity. La question est donc de savoir si Unity est vraiment la solution idéale pour ce projet?
Alors que Craig Tympani et moi étions en train de choisir le moteur de Glittermitten Grove , nous avons opté pour Unity en raison de son bon support multiplateforme, car FNApas encore prêt, et parce que construire son propre moteur est un excellent moyen de ne jamais terminer une partie. En fin de compte, alors que j'étais attristé par le faible support 2D dans Unity, cela nous a permis de sortir des versions pour Mac et Linux presque sans problèmes, ce qui à mon avis est un énorme succès. (Vraisemblablement, le support 2D dans Unity s'est amélioré depuis 2015, mais je ne l'ai pas étudié. Graphics.DrawMesh fonctionne bien pour moi. Peut-être que même FNA a maintenant un pipeline de traitement des ressources de travail!)
Pour ce projet, j'ai choisi Unity principalement par inertie - Je ne voulais pas prendre la peine d'étudier un nouveau moteur, car je devais mettre en œuvre le projet de recherche décrit ci-dessus; Unity prend en charge toutes les plates-formes sur lesquelles je voulais porter le jeu, y compris les consoles.
Oh, et puis j'ai créé un jeu supplémentaire! Je parlerai probablement de ce processus créatif dans un autre article, ici je mentionnerai seulement que j'ai monté une scène de transition dans Haxe et écrit le reste du nouveau jeu en C #. De plus, j'ai apporté des modifications importantes au menu principal dans la base de code Haxe. Par conséquent, il me semble qu'il est tout à fait possible, après le portage sur Haxe, de continuer à publier des mises à jour de code tout en développant sur Haxe.
J'ai également apporté quelques optimisations au code d'origine. Le code AS3 a été délibérément écrit sans efficacité parce que j'essayais d'éviter de rechercher un «code sans défaut». Par exemple, je ne pouvais pas croire que je pourrais m'en tirer en allouant un Vector2 pour le tas sur chaque opération arithmétique! Le résultat a bien fonctionné sur les ordinateurs de 2012, mais les parties les moins performantes après la double transpilation ont causé une charge importante, donc pour bien fonctionner sur les PC modernes, j'ai dû réécrire une partie du code en C # natif.
Il est également intéressant de noter que si je n'avais pas prévu d'augmenter considérablement la taille du jeu original et que j'essayais simplement de l'empêcher de mourir avec Flash, alors OpenFL, AIR ou Ruffle serait probablement un choix plus intelligent.
Lâcher le jeu, c'était comme lui dire au revoir. J'ai aimé travailler dans Flash. À l'époque, c'était le meilleur moyen de montrer vos jeux aux gens avec le moins d'efforts et il semblait qu'ils vivraient pour toujours - SWF des années 90 fonctionne toujours parfaitement dans le dernier lecteur Flash, même si des décennies se sont écoulées. Regarder le monde essayer de passer au HTML5 alors qu'il n'était clairement pas encore prêt était atroce. (Et franchement, les choses empirent au lieu de s'améliorer . Je pense que le navigateur ne sera plus jamais une plate-forme jouable tant que les propriétaires des deux navigateurs les plus populaires auront leurs propres magasins d'applications pour téléphones.) qu'il voulait vendre un nouveau jeu, mais aussi par désir sincère de garder sa part de l'histoire du jeu. Merci de revenir la voir avec moi!