GuieA_7 a écrit 675 commentaires

"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.

Ça peut être bien pour de l'entre soit, mais au moment où la communauté Linuxienne est tant décriée notamment à cause de Stallman et de certains autres Linuxiens peu aimables

C'est vraiment le cas ? J'ai plus l'impression que tout le monde s'en tape de Stallman et Linus ; je n'en entends jamais parler ailleurs qu'ici (par exemple dans les réseaux tournés autour du Jeu Vidéo où je traîne, j'entends parler de drama nuls du JV, dont 99% des gens se fichera aussi en dehors de cette sphère). La communauté n'a peut-être plus vocation a grandir énormément, c'est comme ça, ce n'est pas comme si 50% des gens en avaient quelque chose à faire du logiciel libre (c'est dommage mais les sujets passionnants ne manquent pas).

faut au contraire s'ouvrir et accepter la critique. Et les critiques sont souvent mal notées…

Je n'en suis pas vraiment sûr (mon avis n'est pas arrêté, mais j'aimerai au moins des exemples). Autant il est plus facile de récolter un +10 pour un jeu de mot que pour une critique argumentée, autant les fameuses critiques géniales qui se prennent des -10 ne sont géniales que la tête que leur auteur de ce que je vois depuis 20 ans ici. Et même si parfois le problème est plus dans la forme que dans le fond (par exemple insulter tout le monde n'aide pas vraiment à ce qu'on vous lise de manière rationnelle), ça restent des messages qui se prennent un -10 pour une bonne raison (c'est-à-dire pas parce qu'ils révèlent des réalités dérangeantes, n'en déplaise à leur auteur).

[…] ils contiennent les sprites du jeul,

=> ils contiennent les sprites du jeu

[…] on peut fusionner les sprites niveau hardware et les controllers comme s’il n’en avait qu’un seul !

=> on peut fusionner les sprites niveau hardware et les contrôler comme s’il n’y en avait qu’un seul !

[…] les sprites zoomés n’était que des gros sprites qu’on dézoomer !

=> les sprites zoomés n’étaient que des gros sprites qu’on dézoomait !

Et merci pour l'interview, hâte d'avoir des nouvelles des autres projets (moteur 3D & CPU) !

Le principe d'ownership ne sort effectivement pas de nulle part ; en revanche Rust a permis d'uniformiser plusieurs concepts de recherche en un seul concept cohérent, qui va plus loin et qui fonctionne sur des vrais programmes ambitieux. Quant à trouver comment écrire un borrow checker performant la communauté Rust est face à un défi nouveau (et d'autres langages seront ravis de copier ça, ce qui est très bien).

article qui est initialement libre puisque publié sur linuxfr

C'est peut-être un raccourci de ta part, mais les articles LinuxFR ne sont pas forcément libres. Ils sont par défaut en CC-By-SA dans le formulaire de rédaction (c'est un site orienté libre, donc c'est un choix que les gens acceptent de manière générale) mais l'auteur peut choisir une autre licence, même non libre, dans l'absolu.

je reprends en partie le contenu de ce journal

Il est toujours possible, lorsque l'ensemble des ayants droit sont d'accord, de changer la licence d'une œuvre. C'est pourquoi il serait compliqué de changer la licence de Linux (qui a des milliers de contributeurs/auteurs) par exemple, mais quand tu es l'unique auteur tu peux re-licencier à ta guise. En admettant que LinkedIn t'impose une licence ça ne pose pas de problème (quelle que soit la licence originelle sur LinuxFr, rien à voir avec le libre).

Je doute que LinkedIn demande nécessairement du contenu original (et si c'est le cas, rien à voir avec la licence sur LinuxFr, là encore).

Et sinon oui Tanguy a bien répondu au dessus.

Merci !
Faire du prosélytisme me met mal à l'aise, mais parler de mon travail de manière technique me fait très plaisir. Je laisse donc lâchement mes collègues communiquer sur les réseaux "classiques" (et heureusement qu'ils le font—merci à eux) et je me concentre sur notre forum et les dépêches LinuxFr.

En revanche c'est depuis 2011: https://linuxfr.org/news/sortie-de-creme-crm-en-version-10
Mais cette dépêche (ainsi que https://linuxfr.org/news/sortie-de-creme-crm-en-version-1-2 ) sont étiquetés avec un étrange "creamecrm".

N'hésite pas à lancer ton fork CaRaseMerveilleusementCRM.

Utilisez des nested macros partout

Utilisez des macros imbriquées partout

Utilisez des nombres en programmation.

Utilisez des nombres en dur (? directement? littéraux?).

Utilisez le moins possible de accolades et de line breaks.

Utilisez le moins possible d'accolades et de sauts de ligne.

N'utilisez pas la bibliothèque standard de langues.

N'utilisez pas la bibliothèque standard du langage.

Si line breaks et indents sont insignifiants […]

Si les sauts (passages?) de ligne et l'indentation sont insignifiants […]

• Tu ne respectes pas trop le style de programmation Python (au niveau des la gestion des espaces surtout), ce qui à la limite n'est pas hyper grave, mais en plus le style n'est pas cohérent ; un coup il y a des espaces après les parenthèses d'appel d'une fonction, un coup non.
• Je n'ai rien contre le code en français dans un objectif d'apprentissage de la programmation (même si bon les petits français font de l'anglais dès l'école primaire—il y a plus de 30ans j'en ai fait à partir du CM2—et le vocabulaire nécessaire est assez basique: array, list, draw, flag, width…), mais là encore ce n'est pas cohérent ; placer_drapeau() côtoie input_config_valid().
• J'imagine qu'on en est pas à la première leçon (il y a des fonctions, classes, boucle imbriquées…) du coup je pense que les élèves savent que cases = list() peut s'écrire cases = [].
• À plusieurs endroits la gestion des boucles est plus C que Python ; par exemple

    for li in range( hauteur ) :
        for ci in range( largeur ) :
            cases[li][ci].draw()

pourrait être plus joliment écrit en :

    for line in cases:
        for case in line:
            case.draw()

Je sais vers où je chercherai mes prochains bouquins de fantasy ;)

"Un compilateur source à source, transpileur ou transcompilateur est un type de compilateur […]" ( source )

(je pinaille mais merci des informations)

Ta demande n'est pas très claire (c'est une demande utilisateur normale ne t'inquiète pas haha). Souhaites-tu créer les formulaires via une interface graphique ou bien y aura-t-il un seul formulaire codé en dur ? Souhaites-tu garder les réponses des utilisateurs (genre pour faire des statistiques par exemple) ? etc…

En fonction de ce que tu veux ça changera de beaucoup le temps de développement. Et tout dépend de ce que tu appelles "simple". En quelque mois de développement un développeur peut pondre un truc un peu sympa mais pas super ambitieux non plus ; mais quelque mois de développement ça représente selon les cas un petit ou un énorme investissement.

En voyant le titre je m’apprêtais à écrire un Nᵉᵐᵉ commentaire sur le fait qu'il n'y a que le moteur et pas les assets, je suis donc agréablement surpris. Je ne suis aps un spécialiste du genre mais le jeu avait l'air de très bonne qualité. Et la Direction Artistique est clairement de toute beauté (les sprites sont petits mais marchent très bien).

Merci aux créateurs pour cette belle initiative !

Je n'ai pas l'impression que le dépôt GitHub contienne les assets graphiques & audio (il semble qu'il manque un répertoire "pool/" qui les contiendrait). Si j'ai raison, dire que le jeu est open-source est faux (seul son moteur l'est).

(je n'aurai rien contre que les assets soient libérés une fois le jeu rentabilisé, mais je n'ai rien vu qui laisse entrevoir une telle possibilité ; et dans tous les cas il n'est pas open-source là tout de suite)

Un gentil contributeur cette année m'a fait découvrir qu'à partir du moment où on utilise from __future__ import annotations, on peut déjà remplacer Union[List[Element], int] par list[Element] | int par exemple (testé sur Python 3.7 et suivant).