Là je suis rassuré, parce que j'ai l'impression que la conception d'un tel logiciel serait un travail gigantesque (à la limite construire un interpréteur ça doit se faire, mais ensuite faire la modélisation je préfère pas imaginer) et son intérêt me semble très limité. Tu prends l'exemple de Georges (prénom assez invraisemblable en 2020 d'ailleurs) qui veut savoir à quoi ressemble un certain trick. Bon tu tapes le nom du trick sur Google tu trouves directement une vidéo, si c'est pour faire une base de données de tricks je pense que faire une vidéo par trick serait plus rapide. La seule utilité que je vois c'est si quelqu'un qui connaît la syntaxe du langage imagine un enchaînement qu'il ne sait pas faire, qu'il ne sait pas breaker, et dont il a envie de montrer les composantes à une autre personne.
Mais bon si ça reste un travail théorique alors la question de l'utilité ne se pose plus et ça peut être intéressant de se pencher sur le problème.

Après j'ai l'impression que pour qu'il n'y ait pas d’ambiguïtés il faudrait être très précis. Quelques exemples :
Qu'est-ce que ça veut dire qu'un doigt est sur le mod ? Si je renverse la main c'est le mod qui est sur le doigt ? Si c'est ça alors il faut préciser dans quel sens est la main. Et s'il est sur le mod, à quel endroit sur le mod et quelle partie du doigt est en contact ?
Qu'est-ce que ça veut dire que deux doigts sont en contact ? Sur toute la longueur ? Aux extrémités ? Côte-à-côte ? L'un au-dessus de l'autre ? Croisés ? Tu as un opérateur qui permet de dire que deux objets sont croisés, mais ils peuvent l'être si on ne précise pas s'ils le sont ou pas.
Pour un TA rev par exemple, comment tu décris l'index recourbé sur le stylo ?
Comment tu décris la position de départ de l'anti-gravity ?
Je me demandais aussi comment différencier un TA d'un TA FL, mais finalement ce n'est peut-être pas nécessaire dans ce projet de les différencier. Je trouve ça tout de même un peu gênant.
Tous ces problèmes peuvent être résolus en étant suffisamment précis dans la description d'un enchaînement, quitte à rajouter des attributs ou des opérateurs à ce que tu as présenté, mais c'est juste pour donner une idée de la complexité que peut représenter l'écriture de certains enchaînements. Par exemple réussir à décrire de façon suffisamment précise un twisted cobra bite pour que quelqu'un qui ne connaisse pas la figure sache à quoi elle ressemble me semble assez difficile.

Pour ce que tu dis Skatox, je n'ai pas l'impression que le fait qu'un programme soit physiquement réalisable soit un problème, le but étant simplement de couvrir l'ensemble des enchaînements réalisables. L'utilisateur verra de lui-même si un enchaînement est réalisable ou non.

en y regardant de plus près, et outre l'aspect orienté objet de ta notation, l'utilisation qu'on peut en faire ressemble très fortement à celle des expressions régulières (je pense que ça ne t'a pas échappé), ou plus généralement des grammaires de type PEG (Parsing Expression Grammar) ou autres joyeusetés.

C'est assez intéressant, et tu proposes un jeu d'opérateurs viables, mais à mon avis beaucoup TROP expressifs. Ce qui me frappe, c'est que tes opérateurs servent un peu à tout et n'importe quoi : définir les points de contact, définir les positions relatives des objets... C'est utilisable, mais si tu veux décrire un mouvement très contraint -- déjà c'est possible, alors +1 mais, il va nécessairement falloir introduire de la redondance dans ta notation, avec plusieurs apparitions des mêmes termes, pour autant qu'un objet possède plusieurs contraintes.

Là on est dans le problème de la "linéarité" de l'écriture face aux possibilités des schéma-plans ou spatiaux, mais pas seulement je pense. Si tu trouves un moyen de le faire, FACTORISE tes attributions d'opérateurs, là ça peut devenir très bon.

J'ai pas compris en quoi.

Je trouve ces inquiétudes raisonnables.

J'ai pas compris en quoi.

Le style orienté objet occulte un peu cette ressemblance, mais basiquement, utiliser des mots terminaux (ici, doigts, mods) et des opérateurs dessus (V, ||, /, etc) pour décrire un langage d'objets (ici, des tricks/combos), c'est le principe des expressions régulières, et plus généralement de toute grammaire "productive" en informatique. De plus Lindor a proposé dans son second post une utilisation à base d'éléments variables (les doigts) de façon à transformer un nom de trick en une fonction [ensemble des doigts]^N => [ensemble des tricks], où N est un nombre dépendant du trick, et ainsi transformer chaque objet "trick"-même en un ensemble. une utilisation similaire peut-être faite des expressions régulières, (et d'autres systèmes de différente expressivité mais utilisant le même concept)... Je sais pas si je suis très clair ceci dit.

C'est justement l'infinité des tricks qui m'a fait préférer l'usage de l'orienté objet, puisqu'on peut créer à volonté des objets pouvant être à loisir des tricks, des enchaînements ou des schémas de tricks.



Dans quel sens ? Tu veux juste dire par là qu'elle ne te plait pas ? Je rappelle que mon écriture n'est pas censée être facilement lisible par un oeil humain - je trouve qu'assez peu de langages de programmation sont "attrayants" pour un non-initié.



Merci, et je requote ça parce que c'est en effet le point fondamental : je n'essaye pas de définir un système de breakdown.



Soit c'est moi qui comprend mal ton message, soit c'est toi qui a zappé une partie de mon post. Justement, j'introduis la distinction entre les objets statiques et les objets dynamiques (entre parenthèse, cette distinction n'existe que pour aider à se le représenter, pour un ordinateur elle n'a pas de sens) :

Les objets statiques sont des positions de la main, des états, si tu préfères.
Les objets dynamiques sont des mouvements, ou des transitions, pour reprendre ta terminologie.

J'ai précisé que dans ce langage, un trick pouvait se représenter ainsi :

Position (objet statique), puis mouvement (on applique une méthode à cet objet).

La seule position non précisée est la position finale... Et j'ai bien précisé qu'on pouvait tout à fait la rajouter. Il me semble inutile de préciser la position finale pour décrire un TA, par contre si ce TA est dans un enchaînement, je rajouterai bien sûr un objet qui indique la position de la main et du mod après le TA, et donc juste avant le trick suivant.

On peut à volonté représenter des états ou des transitions, je ne vois pas ce qui bloque...




ça me rappelle mon prof de maths à qui on demande l'utilité d'un théorème (qui donne le point depuis lequel on doit se positionner pour regarder une ellipse lorsqu'on est dans un espace de dimension 3 et être sûr que c'est une ellipse et non un cercle - parce qu'en perspective, ellipse et cercles, on voit pas la différence), et qui prenait l'exemple pratique de cosmonautes dans l'espace croisant un vaisseau extraterrestre infiniment long, et souhaitant déterminer si la section de ce vaisseau était elliptique ou circulaire.

Tout ça pour dire que je ne m'intéresse vraiment pas aux applications pratiques éventuelles, c'est simplement un jeu pour moi =)



C'est arbitraire et sans réelle importance : le "logiciel" aurait une position de la main par défaut (disons palm down), et "sur" serait définit par défaut dans cette position (par exemple : au dessus du stylo, entre le stylo et l'utilisateur). Ensuite, si on introduit une nouvelle position de la main pour un autre trick (disons palm up), "sur" serait interprété de façon inversée. Mais ce n'est pas au programmeur de se soucier de ça : il utilise l'opérateur "sur" de façon intuitive, et le logiciel l'interprète en fonction de la position de la main indiquée. Je ne me suis pas du tout penché sur la partie interprétation par le logiciel, mais je doute que ça pose problème.



Il y a une autre notation : collé. Deux doigts sont en contact si on souhaite préciser, pour une raison ou pour une autre, que deux portions de ces doigts se touchent. Si les doigts sont collés, on utilise l'opérateur adéquat. Et oui, les doigts peuvent être croisés si l'on ne le précise pas : Généralement, ce sera absolument sans importance (doigts croisés ou non, un TA reste un TA). Si on veut décrire un trick dans lequel les doigts ne doivent pas être croisés, il suffira de rajouter un " !X ". Et la valeur "par défaut" peut logiquement être fixée à "décroisés".



J'ai précisé que le langage actuel était une base simplifiée. Il me semble avoir aussi précisé que l'une des extension serait de définir des sous-objets de la classe "doigt" qui seraient les classes associées au phalanges d'un doigt (trois sous classe par doigt, sauf pour le pouce). ça prend trois secondes de les définir, et définir la position de départ de l'antigravity est immédiat ceci étant fait. Rentrer dans les détails me semblait inutile dans le premier post.



Tu mets le doigt sur une caractéristique de mon langage, et je vais te répondre tout en répondant à ta question sur le Ta rev :

Je l'ai précisé dans le premier post, ce langage décrit le trick, mais pas la façon dont il est exécuté. Tout mouvement du poignet ayant pour but de lutter contre la gravité peut être négligé, par exemple. Pour décrire un TA rev, je dirais ceci :
1) le mod est sur l'index
2) l'index et le mod sont croisés (peut-être est-ce facultatif ?)
3) La phalange de l'extrémité de l'index est en contact avec le mod

Inutile d'être plus précis : le langage ne donne pas d'indication sur la façon dont on réalise physiquement le trick.

De là, il me semble évident que le langage se fiche de la distinction entre TA et FL TA : la seule distinction se fera dans la description de la position de départ. Un FL TA rev sera décrit comme un TA rev pour lequel le mod est posé sur les deux phalanges extrêmes de l'index : bref, l'index n'est pas positionné en contact avec le mod dans l'optique de le pousser. Mais l'impulsion n'est pas décrite.

Entre parenthèse, la notion de fingerless a créé un sacré bazars dans le système de breakdown, avec les backs qui s'opposaient aux arounds, les neobacks aux shadows... Cette notation est plus gênante qu'autre chose. C'est juste un descriptif d'impulsion, très imprécis en soit...



De même, je peux écrire des programmes qui ne font rien d'utile ou de cohérent dans n'importe quel langage : c'est éventuellement un travail à laisser à la plate forme utilisée pour coder que de détecter des points qui ne vont pas dans le code. Mais je ne me suis absolument pas penché sur le problème, et faire détecter par une plate forme la réalisabilité réelle d'un enchaînement me semble difficile.



J'avais pensé à ça, mais je voulais rester simple dans le premier post, donc je ne suis pas parti sur des systèmes de description simplifiés d'enchaînement complexes... Oui, ça ne doit pas être difficile d'imaginer un système de factorisation pour les opérateurs. Mais la redondance ne me gêne pas trop en elle même, on ne recherche pas l'écriture épurée au maximum du trick, on en cherche juste une écriture. Si je n'ai pas la flemme, j'y réfléchirai malgré tout. C'est une bonne remarque.



Si si, ça m'a échappé puisque je ne sais pas ce que c'est. J'ai commencé l'informatique il y a 3 mois, mes notions sont approximativement nulles en ce domaine.

Si le but c'est un programme, regardez comment est fichu le code d'un jeu de skate ou de snow pour l’enchaînement des figures. Ça doit être intéressant pour vous je suppose. Et pour pas partir de zéro.

Non, c'est pas le but. Mais dans l'idée, c'est sous une forme de logiciel dont ce code servirait de base et qui créerait un combo une fois le code entré.