Question aux créateurs de protos : PAO

Bonjour,

S’il y a des auteurs de proto (ou de jeux finis, je prend aussi) parmi vous, j’aurais aimé vos retours sur le sujet suivant :

Comment gérez vous la mise à jour des graphismes de vos cartes au fur et à mesure de vos tests et de l’amélioration de votre design ? Comment vous organisez vous pour mettre à jour toutes vos cartes lorsqu’un petit symbole générique change de visuel ou de position par exemple ?

Et de même comment mettez vous à jour votre ou vos prototypes physiques en parallèle ? ainsi qu’un éventuel mod Tabletop Simulator ou Tabletopia ?

Je pose cette question naïvement car pour le projet sur lequel je travaille (actuellement 200 cartes, on sera très vite à 300 et les 500 sont pas impossibles avec une variante qui est actuellement en réflexion), on a commencé simplement avec des fichiers texte pour les effets de chaque carte et le graphiste qui met à jour les fichiers photoshop au fur et à mesure. Devant l’ampleur de la tâche et les sources d’erreurs, j’ai fini par développer des outils maison pour gérer la PAO de manière automatisée et ça change la vie : l’illustrateur n’a plus qu’à se soucier des symboles et des graphismes, et à réfléchir à un design que j’implémente ensuite dans mon code.

Toutes nos cartes sont définies par un ensembles de propriétés (prix, nom, effets, etc) et lors d’un équilibrage on change quelques valeurs dans les bons fichiers texte et on régénère les visuels.
De même un fichier de sauvegarde Tabletop Simulator est mis à jour si la composition des decks change, avec les visuels qui sont accessibles en ligne afin que TTS les charge facilement.
Enfin, on génère un pdf avec toutes les cartes, pions, plateaux, etc mis en page pour l’impression.

Un des avantages également pour notre jeu est qu’on a 3 decks qui sont identiques à une rotation de couleur de ressource près (pour le deck A une carte rouge sera bleue dans le deck B par exemple). On a donc un seul fichier où sont définies les cartes de ces 3 decks au lieu d’avoir du doublon.

En l’état le projet est absolument pas prêt à être utilisé par un tiers, mais la finalité est bien sûr d’en faire un projet open source « facilement » utilisable par des auteurs intéressés (il faut bien entendu quelques notions de programmation, c’est du Node.js). Aucune date prévisionnelle, car la priorité est donnée à notre jeu en lui même, mais j’aimerais me forcer un peu à rendre la chose plus générique.

Salut !
Moi je fait tout sur Indesign, les éléments génériques sont mis en Gabarit par « type » de carte / pion / tuiles, ensuite je modifie simplement les éléments qui doivent être mise à jour individuellement.
Ta méthode semble intéressante pour l’automatisation :slight_smile:

Merci pour ton retour. Et comment est ce que tu gère la mise à jour de ta ou tes version physiques ?

1 J'aime

Tout ? :sweat:

Non ça dépend, mais ça me faisait rire ce petit GIF :slight_smile:
Mais quand je suis sur les proto, il y a tellement de version, que je préfère tout recommencer pour ne pas me tromper plutôt que mélanger un morceau de version 1 avec version 2 etc… même s’il n’y a pas eu de modification entre les deux (sur l’élément que je vais changer).
Aussi, j’ai mis ce GIF, mais en réalité je ne jette rien, je les « mets de côté » pour y revenir en cas de besoin, doute ou pour voir « ce que ça donne » en modifiant certaine variante.

Mais bon, après c’est un plaisir de faire du proto et tout recommencer, donc ça ne me dérange pas :slight_smile:

Ca a l’air vachement bien ton truc fait maison.

De mon côté la base et les gabarits sont sur toshop, les diecuts etc c’est sous illustrator et voila.

A la base j’avais pas prévu de pousser autant le projet en question, mais du coup c’est plus forcément adapté (resortir et maj des fichiers en 4 bientot 5 langues c’est l’enfer et faut tout double checker).

Ah et j’ai mis en place un index sur google sheet avec toutes les cartes triées et les traductions cotte a cotte, ca a été un sacré gain de temps et un facilitant exceptionnel pour la traduction, la relecture et les mises a jour honnêtement.

Ici aussi je bosse en mode généré. Cartes définies dans un Excel, et je fait un rendu html (imprimable en pdf si besoin) en ayant une petite appli Web qui lit le fichier et fait le rendu.

Ça m’a permis d’aller plus loin aussi, en construisant le graphe de dépendances entre cartes, et en détectant des éventuelles erreurs ainsi.

La j’ai développé les règles du jeu sous forme d’api et la prochaine étape est de faire tourner des IAs pour avoir des stats sur la partie (combien de tours, combien de choix possibles à chaque tour, combien de points en moyenne… ) afin de faire un premier affinage d’équilibrage.

1 J'aime

Who c’est cool ça, tu bosse sur quelles technos ?

Le projet est visible quelque part ?

1 J'aime

Niveau techno, j’ai

  • un microservice Java + spring boot (avec apache poi pour l’excel, jgrapht pour la construction du graphe entre cartes). Vu que c’est un projet perso sur lequel je travaille pas à plein temps, hyper important de pas perdre le fil de ce que je fais quand je reprends -> travailleeen BDDaavec cucumber.
  • le front-end est très simple pour le moment vu qu’e c’est surtout pour afficher/imprimer cartes et jetons : html5 + CSS3 + jquery (et less ).JJe réfléchi à le passer en angular histoire de me faire la main dessus, et je surtout de pouvoir faire du jeu via Web, dans une optique de playtest rapide.
    pour le rendu, un exemple de carte ou justement j’ai changé le layout en 1h de CSS, et y a plus qu’à tout réimprimer.

1 J'aime

Très chouette ! c’est un peu ce que j’ai en tête mais avec d’autres outils.

Tu es obligé de passer par ton front end pour générer tes visuels du coup ? Ou y’a du back capable de faire le taf ?

J’ai besoin d’un moteur de rendu html donc oui je dois passer par le navigateur. Après techniquement, ça peut aussi d’automatiser mais bon pour le moment c’est tellement loin dans ma liste de priorités :stuck_out_tongue:

Le côté automatisation est vraiment intéressant : je suis en train de bosser sur le fait de re-générer uniquement les cartes qui ont changé (git diff).

Même en l’état notre « workflow » est le suivant :

  1. Test (sur Tabletop Simulator, merci Covid)
  2. Correction dans le fichier texte pendant la partie
  3. Commande pour recréer les cartes + envois sur le serveur
  4. Éventuellement chargement de la carte modifiée sur Tabletop Simulator pendant la partie si la modification le justifie

Et bien sûr l’étape 3 c’est juste une unique ligne de commande.

C’est un soft que vous comptez vendre par la suite?

Nope, pour ma part je suis orienté libre et gratuit.

Le but c’est juste de le rendre assez propre, clair et documenté pour que le maximum de monde puisse l’utiliser simplement (peut être même avec une interface web qui sait, au lieu de ligne de commandes qui font peur).

Faire des sous c’est un truc de faible :smiley:

2 J'aimes

Ah top =)
En tout cas un soft comme cela m’intéresserait fortement, car c’est une sacrée perte de temps de tout re sortir a la mano sous photoshop.

Le but de ce topic était aussi de voir un peu s’il y a des gens qui comme toi seraient preneur. Ça peut m’encourager à bosser plus dessus. Mais il y a beaucoup de choses à faire encore pour rendre ça digeste.

À terme je verrais les choses comme ça :

  • Des fichiers (yaml par exemple) qui définissent les cartes / éléments à mettre en forme (série de propriétés de type prix, couleur, effets, titre, etc).
  • Un ou des fichiers (au choix javascript pour pouvoir y mettre du code, json ou yml en utilisant uniquement des fonctionnalités déjà prévues du type : lire le prix de la carte et faire un symbole avec la valeur au centre avec telle typo, mettre le titre en taille 20 sauf s’il est trop long alors taille 16, etc).
  • Un ensemble d’assets graphiques, fonts, etc

Avec des possibilités de mise en forme de textes et de calques classiques (position absolue, centré, aligné horizontal / vertical, groupe d’éléments de taille variable qui s’alignent les uns par rapport aux autres, etc …).

En vue de propotypage on peut très bien revoir nos besoins à la baisse pour avoir des cartes « lisibles » à défaut de « magnifiques ».

La limite peut être sur la complexité de l’impact d’une propriété de carte sur sa mise en place (par exemple, si une carte est de type créature mais verte mais que son prix est inférieur à 3 alors le cadre change de couleur : ben non faites plus simple :P). Mais pour le reste il sera possible d’ajouter « à la main » des éléments visuels ou textuel pour n’importe quelle carte (symbole « attaque de feu en bas à gauche »).

Par exemple un exemple :

Un de mes cartes est définie ainsi (fichier yaml):

  • name: « Frappe chirurgicale »
    id: ‹ ARC6 ›
    color: red
    effects:
    - price: {green: 1, blue: 1}
    type: trash
    effect: « Placez le clone actif sur une case objectif vide du même plateau. »
    - price: {green: 1, blue: 1, red: 1}
    type: burn
    effect: « Placez le clone ciblé sur une case vide du même plateau. »

Elle a donc un nom, une couleur, un identifiant unique et 2 effets qui chacun ont un prix, un type et un texte.
Les visuels générés (recto et verso car le dos de chaque carte dépend de son type et de sa couleur) :

C’est encore très basique mais l’idée est là.

3 J'aimes