Super Funcard Maker

Afin d'obtenir un tel niveau de multiplateforme, je pense utiliser les technologies du web, qui l'ont l'avantage de pouvoir aussi fonctionner en tant que logiciel desktop grâce à Electron. (C'est ce qu'utilise Slack et VS Code notamment). Mais avec une architecture comme celle ci-dessous, il sera tout à fait possible d'utiliser une autre libraire pour créer l'interface graphique.

Composants

Une funcard est un empilement de composants, c'est à dire un élément graphique réutilisable dont on fournit les paramètres.
Exemples : ligne de texte, texte multiligne, image, forme colorée, symboles (manas), etc...

Chaque composant définit les paramètres dont il a besoin et leur définit aussi une valeur par défaut.

Ah oui, petit détail cool, parmi les paramètres de composants, on pourra mettre comme valeur d'autres composants, comme ça il sera possible de composer des composants et ainsi créer des composants complexes.

Le plus important, c'est que chaque composant ait une documentation complète et détaillée.

Il sera défini pour chaque composant une interface graphique pour piloter ses paramètres.

Certains composants seront des composants de layout : leur seule utilité sera de disposer correctement les composants qui le composent, afin de créer des mises en pages complexes.
Exemple: Le titre pourra être comprimé si le coût de mana est trop long

Renderer

Il s'agit de la fonction qui à partir de la liste des composants et de leurs paramètres génèrera l'image.

Le renderer va parcourir tous les composants dans l'ordre et générer à partir de ça un rendu.
J'imagine ça avec l'éventualité d'avoir plusieurs renderers : un pour générer une image (en utilisant Imagemagick, la technologie que j'utilise sur le Funcard Maker 2), un qui peut générer un fichier Photoshop, un qui peut générer une carte interactive, etc... Tout est possible au final.

Bien entendu, cela signifie que chaque renderer doit implémenter une fonction de rendu pour chaque composant qui existe, sinon si une implémentation manque, il faudra émettre un avertissement et afficher à la place un composant générique défini par le renderer (genre "technical difficulties, please stand by" comme à la télé xD).

Il faut aussi que chaque renderer implémente les attributs des composants (c'est comme ça que je vais appeler les paramètres qu'on retrouve dans chaque composant). En revanche la manière de les interpréter va vraiment dépendre du renderer, donc c'est un sujet à traiter au cas par cas.

Un renderer pourra définir des options de rendu qui permettront d'utiliser le renderer de manière alternative, pour y altérer le rendu final.
Exemples : une option pour générer une miniature de 150ko, une autre pour générer chaque composant dans un fichier séparé, etc...

Enfin, le renderer imagemagick sera un peu particulier car il sera utilisé dans l'interface pour générer l'aperçu. D'ailleurs ce sera le seul disponible au début.
(À moins de créer un autre renderer HTML-CSS permettant de générer un aperçu avec un moins bonne fidélité mais plus rapide à exécuter.)

PS : Je prévois d'utiliser Imagemagick, mais je ne suis jamais à l'abri de découvrir une technologie plus performante.

Assets

Ce sont les ressources graphiques utilisées pour générer la carte.
Le renderer aura besoin de ces assets pour faire son travail, et ces assets sont liés à la carte. Mais comme il s'agit de fichiers potentiellement gros, il vaut mieux les lier plutôt que les incorporer directement dans le fichier.

Il faut gérer deux cas d'utilisation : pour le offline, on peut soit utiliser un chemin absolu (`C:\Users\...\illus.png`), soit un chemin relatif à la carte (`./illus.png`). Cela voudra dire qu'une carte sera composée d'un répertoire comprenant la définition des composants de la carte et tous ses assets (et potentiellement ses rendus si on le souhaite).

Si un asset est introuvable au moment du rendu, alors un asset générique et explicite sera chargé à la place, et un message d'avertissement sera émis.

L'autre cas c'est le online. On peut pas demander à l'utilisateur d'uploader ses assets à chaque rendu, ce sera trop long. Il faut alors les stocker en ligne de manière temporaire, comme c'est le cas avec le Funcard Maker 2. Le fichier aura alors le nom que le serveur lui aura donné (qui sera très certainement différent de celui du fichier qu'a uploadé l'utilisateur), et il faut pouvoir lui redemander un fichier manquant en précisant son nom original, si le fichier hébergé vient à expirer.

Ah, y'a un troisième cas, c'est celui où l'asset en question fait partie du SFM (les différents fonds officiels, les manas, etc, seront directement inclus dans le logiciel). Dans ce cas la référence vers ce fichier sera fait à partir d'un mot clé défini par le logiciel (et documentés).

Templates

Les templates sont des cartes pré-configurées : une série de composants avec des paramètres et des assets. Le format de fichier et de répertoire décrivant un template sera identique à celui d'une carte.

Les paramètres de la carte viendront se fusionner à ceux définis dans le template, puis dans ceux par défaut de chaque composant, pour donner au final les données qui seront envoyées au renderer.

Pour pouvoir effectuer ce travail de fusion, le template définit pour chacun de ses composants un identifiant unique au sein de cette carte.
Les paramètres de la carte définira alors le template comme son parent et utilisera l'identifiant de chaque composant comme repère pour savoir où fusionner chaque composant.

Cela veut dire que n'importe quelle carte peut devenir un template ! Le SFM permettra donc de sauvegarder une carte en tant que template pour être réutilisé par la suite.

Cela veut aussi dire qu'il sera aussi possible de chaîner les templates, en créant un template à partir d'un autre qui a été créé à partir d'un autre, etc... Il faudra juste faire attention à prévenir des boucles de chaînage (pas compliqué).

Il faut toutefois prévoir un système de z-index permettant d'insérer des composants entre deux autres grâce à un des attributs du composant.
(Je fais la distinction entre les attributs qui ont une fonction quelque soit le composant, et les paramètres, que chaque composant définit individuellement).

Note : je ne prévois pas que l'interface permette de faire ça, mais en théorie il sera possible pour un carte de définir de nouveaux composants qui ne figurent pas dans le template.

Attention : le système de template décrit ci-dessus a un défaut : la carte ne pourra pas être ouverte dans le SFM si le template n'est pas présent. Et si le template d'origine a subi des modifications, elles seront répercutées sur la carte. Pour se prémunir de ce problème, il faudrait pouvoir enregistrer la carte avec une copie de toute la chaine de template. Cela peut constituer un type d'export de données permettant d'obtenir une carte avec tous ses assets et toutes ses définitions. Cela serait aussi pratique pour les graphistes souhaitant utiliser certains éléments de carte indépendamment sur un autre logiciel, sans passer par un rendu.

Si le coeur vous en dit, on pourra prévoir une interface graphique pour créer des templates. Mais bon ce sera un peu compliqué et selon moi c'est clairement pas la priorité, car les créateurs de templates représentent à mon avis une toute petite partie du public, et ils auront les compétences nécessaires pour écrire directement le fichier, sans avoir à recourir à une interface graphique.
Cela dit dans un premier temps, on peut proposer aux créateurs de templates un éditeur de texte pour rédiger le template et qui proposera une aperçu en temps-réel pour que tout ça soit moins fastidieux.

Set

Un set de cartes est simplement un ensemble de cartes avec des propriétés communes. On pourra définir pour un set des paramètres pour les composants (qui viendront s'intégrer juste entre les paramètres de la carte et les paramètres du template), des assets et des templates.

Le SFM fournira un ensemble de fonctionnalités permettant le traitement par lots afin de gérer d'un coup toutes les cartes d'un set.

Cartes Recto-Verso

Perso, j'ai tendance à voir les cartes multifaces comme un funset où l'on fait un rendu de chaque carte les unes à côté des autres sur la même image...
Me trompe-je ???

Une carte recto-verso peut être vue comme un template de set, c'est à dire un set préconfiguré avec deux cartes ayant un template de carte différent.

Bon, si on considère une carte multiface comme un mini-set, ça veut dire qu'en faisant un set de cartes dont certaines sont multifaces, on a un set de sets. Si certains d'entre vous adorent l'imbrication, je pense que là vous êtes servis.

Command Line Interface

J'en avais parlé un peu plus haut, mais l'avantage d'une telle architecture est que l'implémentation du renderer, de la gestion des templates et des paramètres des composants ne dépend pas de l'interface.
On peut donc concevoir plusieurs interfaces utilisateur indépendantes pour piloter ces éléments et générer des funcards.

J'ai déjà parlé de deux d'entre elles : une interface Web online (hébergée sur un serveur) et une interface Web desktop (qui fonctionnera en local sur l'ordinateur). Mais j'avais aussi parlé d'une interface en ligne de commande au début. Ah, et pour faire fonctionner les applis web, il faudra un serveur, et je pensais faire un serveur Node.js proposant une API REST qui sera utilisée en ligne comme en local, mais qu'on peut aussi exposer à des interfaces tierces.

En bref, des outils ouverts à toutes les possibilités !

Plugins

Comment rendre cela plus ouvert encore ? En proposant simplement d'étendre les fonctionnalités du SFM via des plugins !

Un plugin pourra définir de nouveaux composants (avec leur fonction de rendu avec le renderer principal et leur interface), ou de nouveaux renderers (il faudra implémenter tous les composants existants).

Un tel système aura très certainement des problèmes du genre : « J'ai un plugin avec un renderer pour Photoshop, mais il ne gère pas mon autre plugin qui ajoute tel composant »
Mais hélas je crois qu'on ne peut rien faire contre ça avec une telle architecture, car les différents renderers seront fatalement incompatibles entre eux.

Pour contourner ce problème, il faudrait utiliser le renderer imagemagick par défaut si le renderer n'implémente pas le composant, et que chaque nouveau renderer soit capable de gérer un composant qui a été rendu comme une image png. C'est possible, mais cela reste une rustine et ça casse un peu l'intérêt de la chose. (Mais bon, on aura une belle image à la fin quoi qu'il arrive, c'est peut-être ça le plus important.)

Le problème de la compatibilité des plugins est selon moi LE casse-tête de ce projet, ça est le fait de pouvoir charger des plugins dynamiquement lors du runtime, alors que ces plugins peuvent nécessiter de nouvelles technologies qui fonctionnent en dehors d'Electron.
(Là je parle aux vrai qui savent comment tout ça fonctionne.)

Sinon dans le doute, si on n'arrive pas à charger les plugins dynamiquement, cette architecture reste modulaire par essence, ce qui sera toujours un meilleur confort de développement.

Modules

Pour illustrer tout le découpage modulaire du Super Funcard Maker, je propose de former plusieurs repositories :

- sfm-core gèrera la façon dont se composent les sets, templates et composants avec la fusion des paramètres, l'import et l'export, ... Enfin toutes les opérations qu'on retrouvera à l'identique quelque soit le type de carte ou de set créé. Il définira aussi un ensemble de composants génériques.

- sfm-renderer-imagemagick sera le renderer principal, et il implémentera tous les composants définis dans sfm-core. Si j'ai choisi de placer le renderer des composants génériques dans un module séparé, c'est parce que les interfaces graphiques n'auront aucune raison de contenir un renderer, allégeant ainsi le code de ces interfaces.

- sfm-mtg-plugin sera le plugin dédié aux composants et aux templates de Magic the Gathering. En quelque sorte, sans lui le Super Funcard Maker ne propose aucun contenu directement utilisable.

- sfm-server sera le serveur Node.js hébergeant l'API REST qui pilote le renderer et le noyau.

- sfm-frontend sera l'interface Web multiplateforme générique du Super Funcard maker. Elle utilisera sfm-server pour piloter les fonctionnalités du noyau et du renderer, et contiendra les définition d'interface de chaque composant.

- sfm-dektop sera le paquetage Electron qui contient sfm-front et sfm-server, avec une couche permettant d'intégrer l'interface à un environnement desktop.

- sfm-online sera une web-app conçue à partir de sfm-front, faite pour fonctionner sur navigateur internet.

- sfm-cli sera l'interface en ligne de commande permettant de piloter le noyau et le renderer.

Chacun de ces repositories sera aussi un module js distribué via NPM.

Le plugin Magic the Gathering

Ça c'est LA star du SFM ! Sans ce plugin fourni dans le Super Funcard Maker, il n'y a théoriquement aucun template disponible.

En plus des templates, ce plugin va définir de nombreux composants propres aux cartes Magic. Mais le plus important c'est certainement le composant Mana, qui permettra de générer des mana personnalisés avec des chiffres, des lettres ou des images. Bien entendu tous les manas officiels seront pré-configurés avec des sniplets (ces "{u}{r}{u/w}" très connus des funcardeurs) qui seront transformés automatiquement s'ils sont détectés dans du texte.

Pour faire cette détection, nous allons simplement faire en sorte que le composant Texte réagisse à la présence des caractères "{}" qui serviront à insérer du contenu graphique. L'intérieur des accolades sera une définition de composant, soit à un sniplet à quoi correspondra une définition de composant. Les sniplets seront définis dans les templates.

Pour le tout le reste, je pense que des composants génériques feront parfaitement l'affaire.

Voilà

Bah globalement là c'est fini je crois, j'ai quand même déjà bien parlé ^^

Bon, voilà pour l'essentiel des idées fonctionnelles et techniques. J'ai écrit tout ça dans le but de vous donner envie de participer au projet, soit en tant que développeur (franchement ce serait super cool), soit en tant que testeur (cool aussi, on en aura besoin). Même si pour le moment, rien n'est développé, donc il n'y a rien à tester.