GuieA_7 a écrit 689 commentaires

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.

Globalement d'accord avec ton analyse.

Et le pire c'est oe devoir se battre pour qu'un projet de logiciel libre… utilise des logiciels libres, et pas Github ou Discord par exemple. Là aussi, c'était évident il y a quelques années (à l'époque de sourceforge), mais ça ne l'est plus.

Peut-être que la situation s'est empirée (très probable), mais dans un monde principalement propriétaire, il a toujours fallut faire des compromis. Il y a 20+ ans on aurait parlé de Linux qui utilise bitkeeper, des logiciels sous licence Libre mais écrits en Java (encore propriétaire à l'époque), des trucs qui ne marchent bien qu'avec les NVidia & les pilotes propriétaires…

J'ai surtout l'impression que le libre était une niche à l'époque, et est juste resté une niche.

Dans ma promo, y a plus de 20 ans, et bien qu'en filière informatique, les passionnés d'informatique (le genre qui en ferait par plaisir sur leur temps libre, incroyable) étaient une minorité. Et parmi ces personnes, les passionnés de libre étaient une minorité. Autant dire que ça faisait pas grand monde.

Du coup est-ce que le monde a vraiment changé de ce côté là, ou bien est-ce juste ton environnement (voire toi, tout simplement), qui a changé depuis cette époque ?

C'est en effet quelque chose de très important, et c'est pourquoi ça a toujours été présent dans Creme. Nous nous sommes servi de notre expérience sur V-Tiger, un autre CRM que nous intégrions, que soit avec les fonctionnalité qui étaient là comme celles qui manquaient. Cela se trouve dans notre module Rapports ('reports' dans le code), auquel on accède de base dans le menu "Analyse".

Un Rapport est une fiche qui va pouvoir générer des "tables", dont on choisi les colonnes et dont on peut filtrer les lignes, et que l'ont peut ensuite exporter (xls, csv). Par rapport aux vues en liste (qui possèdent aussi ces fonctionnalités), on a :

• des colonnes spéciales d'agrégat ; pour faire des sommes/moyennes/maximum/minimum.
• la possibilité d'imbriquer des rapports.

On peut ensuite attacher autant de Graphes que l'ont souhaite à notre Rapport. Pour un Graphe on va pouvoir choisir un critère de groupage pour les abscisses, et un calcul pour les ordonnées (bien qu'il y ait plusieurs représentations graphiques disponibles, pensez histogramme/bargraph dans un premier temps).

Pour chacun des Graphes, vous allez pouvoir créer des blocs, que vous pourrez mettre :
- sur l'accueil, et donc afficher les statistiques globales.
- sur une fiche, et afficher des données restreinte à cette fiche (par exemple uniquement les factures générées par un commercial).

À titre d'exemple, une installation par défaut de Creme vient avec plusieurs blocs de graphes sur l'accueil, comme "Somme des totaux HT des factures de l'année en cours / mois".

Si toutes les requêtes imaginables ne sont évidemment pas faisables, le système actuel est plutôt puissant et permet généralement de satisfaire les demandes des directeurs commerciaux par exemple.

Creme est conçu avec un cœur qui se charge des fonctionnalités génériques (gestion des blocs, configuration du menu ou des formulaires, import CSV…), et autour des modules (apps dans le jargon Django)—quasi tous optionnels—qui se chargent des fonctionnalités métier (rendez-vous, facturation, tickets, e-mails…).

Donc quand on parle d'extension, cela recouvre 2 aspects :

• ajouter de nouvelles apps, qui vont souvent introduire de nouveaux types de fiche/entité (cela pourrait être des Formations ou un Dossier Médical par exemple), avec leurs vues détaillées/en liste/de création/de modification/…, comme le font déjà la grosse vingtaine d'apps fournies de base. À savoir en écrivant peu de code puisque le cœur va faire la majorité du travail pour tout ce qui est générique.
• modifier l'existant, ce qui va être possible via divers mécanismes. Le code est pensé de manière à pouvoir être modifié depuis vos propres apps, même si évidemment plus une modification est profonde plus ça va être complexe.

En plus des apps existantes qui sont évidemment le meilleur exemple de ce qui est possible de faire, je maintiens une doc (en anglais & en français ; voir le répertoire 'doc/' à la racine des sources) sur les 2 aspects vu au dessus.

"Simphony of the Night like" est sûrement à prendre comme "Doom-like" (jeux comme Doom), donc les "Castlevania semblables à SotN" (il me semble qu'en français on n'accorde pas les noms propres).

tous les Simphony of the Night comme Castlevanias.

Castlevania est une série de jeux.
Symphony of the Night (SotN) est épisode de cette série (voir le tableau dans mon lien), surtout connu pour sa sortie sur PlayStation, et il n'est pas sorti sur GBA.
Il y a 3 épisodes sur GBA ("Circle of the Moon", "Harmony of Dissonance" & "Aria of Sorrow"), qui sont clairement dans la lignée de SotN, et qui font parti d'un genre qu'on nomme souvent MetroidVania (de la contraction de Metroid & de CastleVania, donc des jeux avec un seul grand monde ouvert dont on ouvre les parties grâce aux pouvoirs qu'on acquiert au fur et à mesure + une composante RPG avec des caractéristiques qu'on améliore avec de l'expérience).

Du coup s'agissait-il de "Tous les CastleVania inspirés de Symphony of the Night" ?

Oui j'aime bien le parti pris '32bits mais en se limitant à de la 2D'. En revanche je n'ai pas vu de licence dans les repo GitHub (donc sauf erreur de ma part ce n'est pas libre), et dommage ça na pas l'air très actif.

PostreSQL => PostgreSQL (je suppose)

Tu cherches une plateforme existante (genre même un truc propriétaire uniquement en SaaS) pour pouvoir jouer avec des inconnus (après avoir genre configuré 2/3 trucs genre ton ensemble de carte, le nombre de joueurs etc…)
Ou tu cherches un serveur libre de jeu de carte que tu vas auto-héberger et jouer avec tes amis ?
Ou bien tu cherches un moteur de jeu afin de coder tout ça ?
Ou autre ?

J'imagine qu'on parle de conjoncture plutôt que de conjecture.

Bon courage à l'association qui fait un travail important !

Rust, Go & Elixir sont des langages très différents, et leur approches du parallélisme est du coup différente :

• Rust est un langage système généraliste sans runtime par défaut (ce qui est indispensable quand on veut faire un module noyau par exemple, moins si on veut faire une petite web-app—l'absence de GC pour des gros volumes de données peut faire la différence parfois). Il permet d'avoir les performances brutes de C/C++ et des garanties fortes sur le code, mais le prix à payer est en autres que le langage est clairement difficile à maîtriser. Pour le parallélisme, on travaille de base avec des threads mais il apporte la garantie qu'on ne pourra pas modifier un même objet depuis 2 threads sans protection (genre mutex), ce qui n'est pas le cas en Go.
• Go se compile en natif mais vient avec un runtime pour le garbage collector et l'ordonnanceur des routines. Le langage est très simple à apprendre et on code rapidement des choses qui marchent correctement, mais c'est le langage le moins expressif des 3 et il va y avoir plus de code boilerplate et moins de garanties sur l'exactitude du code qu'avec les 2 autres.
• Elixir (je connais plus Erlang, je vais m'appuyer donc sur ce dernier, j'espère ne pas dire trop de bêtises) se base sur la VM Erlang, on a donc affaire à quelque chose de solide pour faire des services réseaux scalables et fiables, mais au détriment de performances brutes plus faibles (VM + typage dynamique).

Dans la mesure où tu regardes du côté de Go & Elixir, même si tu ne le précises pas, je suppose que tu envisages ces langages dans le cadre d'un service réseau. Le parallélisme de Rust est très bien si tu veux faire un moteur 3D par exemple, mais c'est sûr qu'il n'aura pas forcément la facilité d'utilisation des goroutines/micro-processus Erlang dans des cas plus spécifiques.

Si j'ai bien compris il existe en Rust plusieurs bibliothèques permettant d'utiliser async/wait (comme vu au dessus, vu les objectifs "système" du langage, imposer un runtime de base n'est pas souhaitable), mais on n'arrive pas à la facilité d'utilisation des routines (on a les garanties de Rust en compensation). J'ai aussi vu passer des systèmes d'acteurs façon Erlang pour Rust ; ça me semble une piste très intéressante, mais tout va dépendre de la maturité/pérennité de ces briques évidemment…

Pour répondre à ta question, bien que ne connaissant pas vraiment Zig, vu ses objectifs (système etc…), je suppose que sa situation doit être à comparer à celle de Rust.

Si j'ai bien compris ton besoin (accéder aux évènements les plus proches rapidement) c'est un problème classique, et le tas (heap) est sûrement une bonne solution. C'est une façon de ranger des éléments dans une liste/tableau en fonction d'une priorité (la date dans ton cas) de manière à accéder rapidement à l'élément le plus prioritaire.

En Python regarde le module standard heapq.

La dépêche indique bien que les assets sont ne pas libres/open-source, mais du coup je serai pour que le titre soit plutôt "Fishfolk : un jeu au moteur libre codé en Rust".

J'étais personnellement enthousiasmé quand j'ai vu la campagne apparaître, mais l'aspect non-libre des assets a fait retomber le soufflet. J'espère un jour une campagne qui vise à libérer les assets.

Il me semble qu'il y a llllllooonnngtemmpsss c'était +/- (des vieilles moules< pour confirmer ?).

Tout à fait. Le passage à pertinent/inutile a amélioré les choses, au moins légèrement.

De même tu semble affirmer que les notes sont quelque chose de neutre et objectif avec comme règle "si une dizaines de personnes de plus on voté dans un sens par rapport à l'autre c'est que ça doit être vrai".

Je précise ma pensée. Quand je parle de commentaire à -10, je parle d'un "+0/-10" (voire d'un "+2/-38" par exemple) ; même sans un système 100% neutre (il ne l'est pas, il n'est pas pour autant 100% biaisé), ce genre de note indique clairement un gros souci (pour peu qu'on se trouve dans une communauté avec laquelle on est un minimum d'accord—si j'avais l'impression de nager dans les suprémacistes blancs je partirai, je n'essaierai pas de changer le système de note). Ce n'est pas "y a juste 10 personnes de plus qui ont jugé ça nulle", mais "personne ne défend ce truc". On n'est pas dans un commentaire très clivant à "+152/-165" ; ce genre de commentaire reste très rare au final, et la remarque initiale sur les critiques pas bien notées ne parlaient pas de ce cas j'imagine.

Si c'est le cas pourquoi ne pas interdire de répondre à tout commentaire noté à -10 ?

Ça permet d'expliquer ce qui ne va pas dans le commentaire ; si c'est la forme qui était problématique, il reste un espoir. Je ne suis pas non plus pour fermer le compte de l'auteur directement.