GuieA_7 a écrit 695 commentaires

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.

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 ?