GuieA_7 a écrit 704 commentaires

Merci pour le résumé !

Et du coup mon premier commentaire reste vrai ; même sans prendre en compte les limitations intrinsèques de SVG, on n'a malheureusement pas d'éditeur d'animation comparable à ce qu'avait Flash il y a 25 ans (Flash a par exemple été utilisé pour les séries d'animation d'Ankama ; c'est impensable de faire ça à la main avec un éditeur de texte vous imaginez bien).

Je suppose que c'est de l'humour, mais je vais quand même répondre dans le doute.
Si on me demande comment je fais mes dessins en SVG, les gens s'attendent à un petit tutoriel Inkscape, pas à ce que je leur montre qu'ils peuvent créer un fichier SVG avec leur éditeur de texte préféré.

Pardon ; je n'avais pas compris car il semble qu'on ne voit les commentaires qu'en étant connecté au site. Je ne te cache pas que ça me gène un peu de devoir créer un compte pour voir un commentaire.

Oh sympa !

On voit que c'est fait avec des objets rigides et animés façon "marionnette de papier" avec un squelette (ce qui est aussi une façon de faire que pas mal de gens utilisaient avec Flash).

Je serai curieux de savoir comment il a fait ; je ne serai pas étonné que ce soit en codant les animations à la main (ce qui est viable pour une "petit" truc comme ça—mais clairement pas à la porté de tout le monde).

Pour faire des animations telles qu'on pouvaient les faire avec Flash malheureusement pas vraiment.
Ça fait longtemps que Inkscape a enlevé la gestion des animations de sa roadmap, donc on peut afficher un SVG statique dans le navigateur, et mettre des animations CSS (translations, rotation, homothétie) sur cette image entière. Alors le résultat peut être sympathique (ça faire genre un autocollant qui se déplace), mais :

• à moins qu'un logiciel (libre) permette de générer de manière graphique de telles animations CSS (si c'est le cas je suis preneur), ça va rapidement devenir une purge à écrire à la main (par exemple si tu as plusieurs personnages qui se déplacent dans un décor, s'arrêtent, repartent etc…).
• si tu veux faire des animations sur des nœuds (courbe de Bézier toussa) de ton image (genre pour animer le bras d'un personnage), là ça devient compliqué. Il faut sortir le JavaScript, et évidemment faire ce genre d'animations sans outil visuel va vite devenir infernal (c'est pour ça qu'on a des logiciel d'animation, et pas juste des logiciels qui font des images fixes et on anime à la main derrière).

Tu peux évidemment dans Inkscape dupliquer ton image pour faire tes N frames, mais :

• comme il n'y a pas de gestion des animations, si tu corriges un truc dans une frame faut le reporter dans tes duplications, tu n'as pas d'aperçu de l'animation… Bref, c'est horrible.
• tu obtiendrais au final une animation avec un nombre fixe d'images, pas une animation vectorielle (pas dramatique, mais Flash fait ça).

Donc pas très comparable avec Flash (et je le déplore).

J'avais testé OpenToonz, et de souvenir on peut faire des courbes de Bézier, et animer tout ça, mais c'est pensé en frames pareil, et c'est plutôt fait pour pondre de la vidéo en sortie (ce n'est pas un mal, mais ce n'est pas tout à fait ce dont on parle).

Synfig en revanche avait l'air de viser ça (des animations vectorielles) ; je l'avais testé y a très longtemps (au moins 10 ans) et ce n'était clairement pas utilisable. J'espère que ça a changé (faudra que je lui redonne sa chance).

Si tu faisais dans Blender un truc dans le style d'une animation 2D à la Spine, comment l'intégrerais-tu dans le jeu ensuite ? Comme un modèle 3D ?

(tu sais probablement une bonne partie de tout ça, mais ça pourrait être utile à une personne tiers au débat)

• Cela fait longtemps que les moteurs 2D utilisent en fait des primitives 3D (gérée par le hardware) afin d'être performants et faire des effets facilement. À l'époque des consoles 8/16 bits les sprites étaient une primitive graphique matériel (taille en pixel limitée/imposée, nombre limité à l'écran, nombre limité par ligne etc…) ; de nos jours on colle des images "haute" résolution sur un polygone 3D face à l'écran, et on peut alors lui appliquer différents effets (rotation, zoom, shaders…). C'est plus ancien que ça, mais ça se voit biens dans des jeux comme les derniers Rayman 2D (Origins & Legends ; dans lesquels on voit parfois des éléments en 3D classique aussi d'ailleurs).
• Je n'ai pas étudié la question en profondeur (et Spine étant proprio je ne l'ai jamais lancé), mais c'est à priori comme ça que fonctionne Spine : il met des images sur des couches de polygones 3D, puis ces couches vont être déformées/modifiées (pour faire des mèches de cheveux qui bougent, des yeux qui clignent etc…). Je ne sais pas quel format d'export il utilise, mais je suppose qu'il y a au moins un plugin Unity qui permet aux développeurs de ne pas avoir à se soucier de ça (iels se retrouvent avec un objet Unity prêt à l'emploi dans leur projet avec les animations nommées comme il faut prêtes à être lancées). On peut imaginer le même genre de chose pour Godot évidemment. Au final on obtient quelque chose de plutôt léger par rapport aux modèles 3D classiques avec des centaines de milliers de polygones qu'on a de nos jours (la beauté du résultat va plus venir de la qualité du dessin de base que tu as utilisé dans Spine).
• Pour rappel le grease pencil de Blender permet justement de faire de la 2D (mais peut être que mon idée est idiote et que faire mes animations de type Spine dans Godot serait plus intelligent; bref).

Donc oui l'idée serait de garder un objet 3D (mais "plat"), et pas de générer N images de haute résolution pour faire les animations (ça serait sûrement bien moins efficace, et moins puissant).

Perso je me tâte à modéliser les persos en 3D. Ça me simplifierait les animations je pense, mais je pars de loin.

Il y a des tas d'exemples de mélanges 2D/3D très intéressants (à titre perso, dans le jeu sur lequel je bosse en dilettante j'ai des perso 2D dans un décor 3D). Pour Dead Cells, les animations hyper fluides du héros (en 2D) on été obtenues en faisant un personnage 3D dans Blender avec un rendu type Cel Shading; mais dans certains jeux on garde de la 3D dans le jeu final (avec un rendu qui évoque de la 2D) pour par exemple faire un personnage qui tire à 360°.

Je ne sais pas à quel point ça serait pertinent vu la direction artistique de Bim! de travailler en 3D. Mais j'ai hâte de lire tes prochains journaux !

La légèreté de Blender c'est comme celle de Gimp : selon que tu travailles sur une image en 32x32 pixels ou en 4000x4000 ça ne demande pas les mêmes ressources.

Je me suis servi de Blender y a encore pas longtemps pour faire un peu de 3D basique sur mon ordi portable pas du tout dernier cri (mais oui peut-être que ça serait un peu juste si je voulais faire un film d'animation niveau Pixar).

Je ne vais pas partir de 0 pour coder un tel truc ; j'ai d'autres projets plus prioritaires (et y a des chances non négligeables qu'aucun projet de Spine libre partant de 0 n'atteigne jamais un niveau satisfaisant—Spine a des années et je n'ai rien vu apparaître). Alors que bricoler avec un Blender déjà là c'est un truc que je pourrais faire avec mes petits moyens ; tant pis si l'éditeur ne tourne pas sur un Pentium 100, c'est surtout les performances du jeu final que j'aurai tendance à prioriser.

Pareil ça fait des années que je me dis que j'aimerai bien m'amuser avec un Spine libre. À défaut d'un logiciel dédié, je me demande si en utilisant le grease pencil de Blender il n'y aurait pas moyen de bidouiller quelque chose d'un peu fonctionnel "assez facilement".

Nous n'avons jamais été sur heptapod ; lorsque nous utilisions Mercurial nous étions sur BitBucket. Ce dernier a fini par abandonner Mercurial (de manière assez subite) pendant le développement de Creme 2.2, et nous sommes passés à Git+GitHub (je l'avais évoqué rapidement dans la dépêche de la version 2.2 ).

Et merci à toutes celles & ceux qui font vivre le site, quelque soit leur niveau de contribution !

Hum, y'a un truc qui me dérange à demander à des gens de corriger un script obtenu par ia…

Alors qu'il suffisait de demander à l'IA de coder sans bug #tipsdepro

"du l'ordinateur" > "de l'ordinateur" je suppose.

Belle découverte sinon, merci !

Quand je dois répondre à ça (s'il s'agit de développement), je dis à la personne de juste essayer par elle-même. Peu importe la techno (mais un truc accessible comme Python ou Godot c'est sûrement un bonne idée pour commencer plutôt que partir sur du plus "exigeant" genre Rust ou Ada), l'idée est de savoir si créer un programme lui procure de la joie ou si elle trouve ça pénible.

Ça serait dommage de partir sur une activité qu'on déteste alors que (presque) tout le monde a déjà tout le matériel sous la main afin de se faire une bonne idée. Si vous voulez absolument que ça marche du premier coup (si c'est le cas vous aurez du mal à plein d'autres moment, mais c'est un autre débat) ou que chercher de la documentation vous saoule, ce n'est probablement pas un métier qui est fait pour vous.

Intéressant merci.

À noter que :
- FPC Atomic est libre mais c'est juste un moteur, il faut des assets propriétaires pour pouvoir jouer.
- Soldat n'est pas du tout libre de ce que j'ai vu.

Comme dit au dessus, rien n'obligeait non plus à utiliser un indice de popularité. Je trouve qu'une liste de logiciels libres écrit avec Pascal aurait été plus intéressante.

Du coup je commence: Hedgewars (un jeu vidéo façon Worms avec des hérissons—qui ne semble plus trop actif).

Tu ne veux tellement pas nous surcharger d'informations que tu ne nous a quasiment rien dit (on sait que dans certains cas y a des trucs qui ne marchent pas).

À part te renvoyer vers des tutoriels Python/Venv de base (peut-être que commencer par un projet si complexe est un peu trop ambitieux) on ne va pas pouvoir faire grand pour toi.

Le fait d'utiliser 3 points (U+002E FULL STOP) consécutifs, donc trois caractères, prend 6 octets en UTF-8.

Non 3 octets. L’intérêt de utf-8 est de ne prendre que 8 bits (d'où le nom) pour les caractères ASCII de base (les 127 premiers) dont fait parti le point.

Pour être open source, il faut une licence considérée comme open source par l'Open Source Initiative, qui va respecter 10 critères. Mais si comme moi tu es incapable de retenir les 10 critères de l'OSI, dis toi qu'ils sont équivalents aux 4 critères qui font qu'un logiciel est libre (exécuter, copier/redistribuer, étudier, modifier).

Toute restriction du type "pas d'utilisation commerciale" ou "uniquement pour un usage éducatif" par exemple est incompatible avec ces critères (la redistribution par exemple), et une telle licence ne peut donc pas être considéré comme libre ou open source.

On peut voir le code, même faire quelques trucs avec, c'est donc mieux qu'un code propriétaire dont les sources sont fermées. Mais ça reste non libre/open source.

En effet ; c'est encore pire que ce que je disais. Merci pour la précision !

The SDK is licensed to users on a non-commercial basis under the SOURCE 1 SDK LICENSE

La licence n'est pas OpenSource de manière évidente.

En plus il s'agit juste du moteur, pas des assets.

Donc un truc plus correct serait "le code source du moteur de TF2 est visible" mais c'est sûr ça fait moins rêver.

Tout à fait ; je pratique le TDD comme ça depuis 2007. Ça permet d'avoir confiance dans son travail de refactoring (vu qu'on a les tests qui permettent de détecter la majeur partie des régressions qu'on pourrait introduire) et donc d'avoir un code propre.

Ça permet de limiter la dette technique (on évite le côté "le code est immonde, je ne comprends pas comment ça marche, je ne touche à rien") mais ça ne la supprime évidemment pas (tu veux devoir réécrire des composants dont la conception a largement montré ses limites mais sans avoir les ressources pour le faire).

Très beau journal ! Du jeu, du graphisme, du code, c'est très sympa à lire.

Tu t'en es vraiment bien sorti avec tes pierres (le style cartoon marche bien). Les assets de Aryeom sont jolis aussi (mais qui en aurait douté).

J'ai du mal à trancher sur ce conseil. Ça m'a l'air d'être une bonne idée, mais en même temps si la contrainte est de livrer le lendemain je m'attends à voir arriver des variables globales, du gros couplage, des allocations dans tout les sens, et d'autres trucs pas cool. Ça ne colle pas trop avec le reste de son discours. Je pense qu'une grande partie de la difficulté du dev est justement de trouver un bon compromis en fonction des ressources disponibles, sans trop en faire mais sans bâcler pour autant.

J'imagine que ce conseil s'applique déjà plus à des devs expérimentés (pour qu'ils se cantonnent à du code naïf et propre, plutôt que complexe et propre) qu'à des débutants (qui feront simpliste plus que simple).

Personnellement mon code est truffé de commentaires "TODO" (qui explique que le code pourrait faire mieux dans tel ou tel cas), et d'expérience :
- une infime partie des problèmes que j'avais anticipés finissent par réellement apparaître.
- une grosse partie de ces potentiels problèmes ne gênent personne, et ces "TODO" existent toujours 10 ans après.
- pas mal de ces "TODO" finissent par disparaître purement et simplement avec le code qu'ils accompagnent (ex: le code passe en obsolète puis est remplacé par complètement autre chose).

…avec une personne au parcours plutôt atypique. Merci du coup !

J'aurai même aimé plus de détails ; par exemple le fait de fabriquer soi-même onduleurs et routeurs me rend curieux.

Elle devra aussi apprendre à reconnaître un allié et un ennemi.

Ça c'est facile. L'ennemi est stupide, il pense que c'est nous l'ennemi, alors que c'est lui !

(pardon)

En pratique tu ne risques rien (ton jeu est confidentiel et ne génère pas d'argent), tous comme des milliers de petits jeux amateurs qui reprennent des assets de jeux commerciaux.

En revanche ça reste évidement une violation de licence, tu ne peux pas prétendre que ton jeu (donc code + assets) est libre, et il ne pourra pas par exemple intégrer une distribution Linux un tant soit peu sérieuse. Mais rien ne dit que c'était ton objectif au départ évidemment.