Il faut bien voir qu'une grande partie de l’intérêt de Twitch vient du fait que ça soit du streaming en direct (il y a aussi des VOD—comme pour Youtube par exemple—ainsi que la possibilité de rediffusion, mais ce n'est pas le mode de fonctionnement principal) avec un chat intégré, pour interagir avec le streamer et les autres spectateurs. On peut donc poser des questions (ou y répondre) en direct ; on est loin de l'interaction qu'apporte les commentaires Youtube.
Un des streamers chez qui je vais souvent (pour du jeu) a fait aussi des sessions de code où il développait son site Web ; c'était l'occasion de discuter avec d'autres habitués (ou pas) en écoutant de la musique (je travaille en parallèle, ce n'est pas quelque chose qu'on est forcé de regarder intensément), de donner son avis sur un visuel du site en direct (ex: "je préfère l’icône d'avatar en plus grand").
Cela n'a pas la prétention de remplacer la documentation écrite, c'est une expérience plus sociale (même si ça permet aussi d'apprendre des choses). Comme souvent, les nouveaux usages ne remplacent les autres, ils ouvrent juste le champ des possibilités (les guitares électriques n'ont pas remplacé les guitares acoustiques).
Désolé si je n'ai pas été clair ; je ne dis pas que ces détections dynamiques sont intéressantes dans votre cas précis (que je ne connais pas), c'était juste des exemples où la détection à l'exécution avait du sens. Le cœur de mon propos étant que ce que voulez faire ne fait pas partie de cette liste de cas pertinents, pour la bonne raison que c'est sûrement une mauvaise idée. Parce que vous voulez tester que ça fonctionne sous Windows (c'est très bien) mais vous sabordez le travail juste derrière (et ça c'est moins bien).
Je n'ai pas trouvé de réglage plus efficace que l'option -O3 de gcc/gfortran.
Je ne suis pas sûr de comprendre le lien avec mon message ; si vous répondez à ma partie sur la détection du CPU, voici une explication plus détaillée.
Si vous détectez à l'exécution le type de CPU, vous pouvez par exemple utiliser des versions spécifiques écrites en langage assembleur avec des instructions spécifiques à l'architecture. Le noyau Linux a par exemple des versions écrites en langage assembleur pour ses algorithmes de chiffrement, qui sont utilisées dynamiquement quand c'est possible. Mais ça nécessite du travail de la part du codeur (ce n'est pas juste un flag compilateur), aussi le jeu doit en valoir la chandelle. Et même si vous compiliez pour cette architecture spécifique avec gcc, il n'est pas dit que le compilateur soit assez intelligent pour générer de lui-même la version la plus optimisée (sinon les développeurs Linux auraient généré ce code plutôt que de l'écrire à la main…).
la version de Windows (seven, 8 ou 10), afin d'utiliser des fonctionnalités qui existent sur une version récente tout en fonctionnant sur une version plus ancienne.
le nombre de CPU, afin de créer un nombre intelligent de threads.
la présence de certaines instructions (SSE et cie), afin d'utiliser une version plus optimisée du code quand c'est possible.
tout en ayant un seul binaire estampillé "Windows", ça me parait une bonne idée pour éviter d'avoir 1000 combinaisons (genre seven+2cores+intel, w10+8cores+amd) qui vont être un enfer pour l'utilisateur.
En revanche détecter qu'on est sur Wine ça ne va conduire qu'à un seule chose à mon avis: un programme qui tourne bien sous Wine, mais pas sur un vrai Windows (puisque tout un pan du code ne sera jamais testé).
En général il est déconseillé d'utiliser des objet mutable comme valeur par défaut (car c'est au final une variable globale utilisée par tous les appels à la fonction/méthode).
resolvconf=open("/etc/resolv.conf","r")
Il serait mieux d'utiliser with, ce qui fermerait proprement et automatiquement le fichier.
Il y a un temps limité pour trouver de l'argent sur les systèmes de crownfunding
Ce n'est vrai pour un certain type de crowdfunding, comme avec des sites du genre Kickstarter, IndieGogo ou Ulule.
Il existe d'autres types de financement pour lesquels tu n'es pas obligé convaincre "beaucoup" de gens en peu de temps, comme les systèmes proposés par Patreon, Tipeee ou Liberapay.
Après si tu veux que des gens te donnent de l'argent, il faudra toujours faire de la publicité d'une manière ou d'une autre (à part être déjà connu et reconnu).
J'avais les stats KickStater & Google Analytics. Des centaines de personnes l'ont vu.
Des centaines de personnes c'est en fait minuscule sur un site aussi gros que kickstarter ; des centaines de vues c'est je pense assimilable à quelques badauds qui se sont perdus.
Un site comme LinuxFR, pourtant bien plus petit et spécifique (logiciel libre, francophone) possède des milliers de comptes (plus les lecteurs non-inscrits) ; donc ton journal va sûrement faire bien plus que des centaines de vues !
J'ai utilisé Kickstarter comme un outil pour déterminer l'intérêt de la chose
Mais là il s'agissait de jauger la valeur de l'idée.
Personne n'a jugé que ça valait 5€.
Tantôt tu parles d'intérêt, tantôt de valeur de l'idée, tantôt du prix que des gens veulent mettre dessus. Tout ceci est certainement très clair dans ta tête, mais personnellement je ne comprends pas ce que tu cherches.
Est-ce que si des gens sont prêts à venir contribuer à ton projet sur leur temps libre, est-ce que tu appelles ça de la valeur
(parce que pour ces gens, ton projet a de la valeur, sinon il utiliseraient leur temps libre autrement) ?
Si des gens installent gratuitement ton jeu (sachant que tu dis aussi que faire plein de brouzoufs n'était pas le but), y jouent, s'amusent et te éventuellement disent merci, est-ce tu appelles ça de la valeur ?
J'avais bien aimé ce texte de Ploum (parmi tant d'autres): https://ploum.net/votre-idee-ne-vaut-rien/
En gros une idée n'a aucune valeur, seule la réalisation d'une idée a de la valeur. C'est vrai pour une idée innovante ; mais dans ton cas où ton jeu semble très classique (et des tas de jeux existants réalisent déjà ce que toi tu ne fais que promettre) c'est d'autant plus vrai. Une fois fini ton jeu serait peut-être très bien, mais là, même ce que tu promets n'a rien d'original.
Il n'est donc pas étonnant que sa valeur marchande soit nulle ; pour 5€ on peut acheter des tas de jeux déjà finis et largement plus ambitieux ; 5€ ce n'est effectivement pas énorme, mais il n'y avait pas vraiment de raison de te les donner à toi (c'est mieux investit en achetant un jeu déjà fini, ou en finançant un jeu qui semble apporter quelque chose de nouveau). Mais encore une fois cette valeur marchande, on ne sait pas si c'était la valeur que tu voulais mesurer (il a de la valeur sans aucun doute, mais pas de valeur marchande—en l'état actuel en tout cas).
Peut-être qu'une présentation plus détaillée desdits jeux (et des visuels, on aime ça les images:) ) serait une motivation supplémentaire pour d'éventuels contributeurs/partenaires.
Je vous souhaite bonne chance pour la suite, et j'espère avoir des nouvelles sur LinuxFr quand le projet aura avancé.
Je ne suis pas candidat, car vu la faible vitesse à laquelle avance mes projets personnels je ne voudrais pas vraiment impliquer quiconque là dedans. En revanche je trouve votre post intéressant & intriguant (car sortant nettement de l'ordinaire) et j'aurai des questions, qui pourraient peut-être permettre d'éclaircir certains points qui ne me semblent pas clairs.
Quand vous parlez de faire ces jeux en Open-Source, est-ce que vous parlez uniquement du code, ou vous englobez aussi les différents assets (images, sons etc…), voire le nom ? En clair, vos jeux ont j'imagine une identité visuelle ; est-il question de pouvoir réutiliser ces visuels existants et de les placer sous une licence libre, genre CC-BY/CC-BY-SA (mais pas les clauses NC & ND qui ne sont pas libres) ?
Autre question: est-il question pour vous de gagner de l'argent avec ces jeux vidéos, ou bien êtes vous juste à la recherche de "repreneurs" pour ce travail effectué afin que ça puisse servir éventuellement aux autres ?
Le premier qui m'est venu à l'esprit, c'es le sigill qui déclenche l'écriture d'un coredump, celui-ci pouvant contenir des informations sensibles qui deviennent alors lisibles de l'extérieur.
Ça voudrait dire que l'environnement est configuré pour générer des core dumps (depuis bien longtemps sous Debian/Ubuntu ce n'est pas le cas dans la configuration de base, vu que c'est plutôt pour les développeurs), et que ces dumps sont lisibles de l'extérieur. Ça ne veut pas dire qu'il n'existe pas de scénario (ça serait assez pédant vu la complexité du problème), mais pour le coup celui-là ne me parait pas hyper pertinent (parce que ça indique plutôt une faille qui n'a pas grand chose à voir avec le logiciel en lui-même).
J'aurais tendance à dire que si l'instruction illégale est toujours la même et ne correspond pas aux données du fichier (comme dans un buffer overflow), ça me parait difficilement exploitable.
Après comme je ne vais pas aller vérifier, et que je n'ai pas les connaissances suffisantes pour affirmer que ça suffit à l'absence de faille, je vais botter en touche en disant que la sécurité est un point auquel l'équipe de Rust a toujours fait très attention (et qu'en l'occurrence le problème est connu).
Ton commentaire est intéressant, mais tu présentes les choses de manière un peu provocante dans cette phrase:
De là à appuyer tout l'argumentaire de Rust sur "les programmes écrits en C et C++ peuvent planter, un code écrit en Rust ne peut pas planter", je trouve que ça méritait quelques précisions
L'interview parle plutôt de bugs étranges et de failles de sécurité, plutôt du fait que ça ne plante jamais. Par exemple à propos de C/C++:
Vous pouvez facilement faire quelque chose qui fera planter votre système et permettra à un attaquant de prendre le contrôle de la machine de l’utilisateur, sans même vous rendre compte que ce que vous avez écrit n’est pas sûr.
Ça va juste échouer à l’exécution avec des symptômes bizarres.
Et dans ton cas il n'y a ni de faille de sécurité (enfin jusqu'à preuve du contraire), ni de symptôme bizarre (un message nous indique clairement le problème—en revanche oui le SIGILL est pour le moins déroutant j'avoue).
Et quand le texte dit qu'un programme Rust ne plante pas, il se ravise aussitôt:
Ce qui veut dire que si vous ne sortez pas du bac à sable, votre programme ne plantera pas… Du moins, il ne produira pas d’erreur de segmentation.
(et on n'a pas une erreur de segmentation :) )
J'ajouterai qu'il s'agit d'un problème dont les créateurs de Rust sont au courant (tu nous donnes justement les liens qui vont bien) qui devrait être réglé à terme, et pas d'une limite intrinsèque et insoluble du langage (comme l'obligation d'avoir des pauses dans un langage basé sur un GC par exemple).
Mais comme tu le soulignes le terme "sûr" qu'utilise Rust n'est pas sans ambiguïté ; il s'agit de cohérence des données (pas de pointeur qui écrit au pif dans la mémoire, ou de data-race entre 2 threads par exemple), pas du fait qu'un programme ne va pas terminer prématurément. Par exemple, il est souvent dit qu'il n'y pas de fuite mémoire avec Rust ; en fait c'est faux. La gestion mémoire est certes très bonne, mais par exemple il est possible lorsqu'on utilise du comptage de référence (on en a besoin dans certains cas) de "perdre" de la mémoire si on a des cycle de références. C'est bien dommage, mais ça ne rentre pas en contradiction avec la définition de sûreté du langage (le programme pourra finir par être à court de mémoire comme dans ton cas, mais ça n'introduira pas de faille de sécurité par exemple).
Oui, je parlais évidemment du temps qu'il fallait pour quelqu'un d'expérimenté. Quand un plombier te dit qu'il en a pour deux heures pour remplacer ton radiateur, il ne prend pas en compte son temps de formation sur la pose de radiateur.
Certes. Mais dans cas tu es le plombier et tu dis à des non plombiers qu'ils devraient faire la réparation (eux-mêmes) et que ça prendra 2h ; personnellement je le comprends comme "ça va vous prendre 2h". Mais c'est peut-être moi. Peu importe.
Mouais, en même temps l'amateurisme des équipes qui développent les jeux libres est peut-être le problème majeur […]
Je suis globalement d'accord avec tout ton paragraphe. Mais il n'est pas en contradiction avec ma phrase ; même des pros vont avoir besoin de beaucoup de temps pour faire quelque chose de soigné. Si tu codes (mais c'est vrai pour tout), alors tu sais ce que c'est que faire un sympathique prototype en 3h, mais au final passer 2 semaines sur ton patch pour gérer tous les cas particuliers pénibles etc…
Je suis d'accord avec l'ensemble de ton commentaire. Je reviens sur 2 points en particulier:
Parfois on trouve des paliers très hauts pour l'ouverture du code dans les campagnes de financement participatif de jeux indépendants mais c'est rare et encore plus rarement atteint.
Intéressant. Je me suis déjà amusé à faire le tour des plateformes de financement participatif à la recherche de projets de jeux libres, et je n'avais rien trouvé (sauf un anecdotique jeu genre casse brique pas du tout attrayant). La seule exception semble être la campagne d'amélioration de 0AD.
Du coup l'existence de tels paliers dans des projets de jeux m'intéresse, mais j'y vois 2 bémols:
je ne serais pas étonné que comme d'habitude, il s'agisse de la libération du moteur seulement.
ça me dérange que ça soit un palier, car moi j'aimerai financer uniquement si je sais que ça va être libre. Donc en pratique je dois attendre que ledit palier soit atteint ; difficile de faire passer le message "c'est ce palier que je veux, sinon rien".
Je ne pense pas que ce soit aussi simple que le fait que ça prenne du temps.
J'ai axé ma réponse autour du temps, en rapport au message auquel je répondais ; ce n'est évidemment pas le seul problème.
Mais pour préciser ma réponse, je parlais de petits jeux d'arcade comme celui de cette dépêche. Pour de tels jeux, il n'y a pas de grosse difficulté technique (le côté artistique c'est autre chose) (ex: il ne s'agit pas de faire un modèle d'éclairage dynamique 3D nécessitant des connaissances pointues en optique et en pipeline 3D), je pense pour l'aspect mathématique un niveau 4ème doit suffire (bon allez si on peut envoyer une bombe, faut peut-être savoir ce qu'est une parabole). Du coup même si ce sont des amateurs qui codent, s'ils ont assez de temps, ils vont y arriver (le code ne sera peut-être pas terrible, mais ça marchera à peu prêt). Mais même pour un petit jeu comme ça, il faudra pas mal de temps pour faire tous les petits détails qui font que ça rend bien.
Évidemment pour des jeux plus ambitieux le problème sera tout autre.
Si la seule manière d'évalluer la complexité d'un projet était de le coder, alors ça ne servirait pas à grand chose d'évaluer la complexité d'un projet…
Certes, mais en parlant d'une journée max de boulot, tu montres à mon avis à quel point il est courant dans le milieu de l'informatique de sous-évaluer le temps de développement (mais peut-être es-tu commercial dans une SSI :) ).
Alors oui, il existe des gens capables lors d'une GameJam de 24h de pondre seul des jeux même plus ambitieux que ça (et en faisant les graphismes et le son) (regardez ce que DeepNight arrive à faire par exemple), mais il s'agit de gens rodés à cet exercice depuis de longues années, qui connaissent leur outils de création de jeux sur le bout des doigts ; généralement ce sont des professionnels de la création de jeux vidéos. Donc s'ils sont capable de faire ça en un week-end, il ne faut pas oublier les années de création de jeux qui on permis d'atteindre ce niveau.
De simples amateurs qui se mettent à la création de jeux il leur faudra bien plus. Ça ne sera pas des années de développement évidemment, mais moi rien que pour lire la documentation et faire les tutoriels de GodotEngine, ça m'a largement pris plus d'une journée, pendant mes vacances. Il est tout à fait possible que tu sois bien plus compétent que moi, mais je bosse depuis suffisamment longtemps pour savoir que je suis plus compétent que la moyenne. Après je serai heureux que tu viennes nous présenter les applications libres que tu codes ; parce que si tu es capable de faire ça en quelques heures, j'imagine qu'en quelques jours de travail ça doit vraiment être impressionnant.
PS: 90% du code écrit ne fait rien de bien complexe. Pourtant le diable se cache dans les détails et même faire quelque chose d'assez trivial, quand on veut que ça soit de bonne qualité, ça prend du temps. Sinon nous aurions des tas de jeux libres de qualité. Hélas on sait qu'il ne sont pas très nombreux.
Le jeu est identique à la version DOS à part l’ajout de l’I.A
Visiblement l'idée est d'améliorer le jeu (avec un peu d'imagination, les possibilités sont nombreuses), pas juste de garder quelque chose de figé qu'on va faire tourner sur plein de plateformes. Auquel cas, la façon la plus pragmatique de faire aurait été de faire de l'émulation [*] ; ce n'est pas forcément la plus excitante techniquement évidemment.
Donc un langage de plus haut niveau peut avoir du sens (pour écrire un code réseau plus sereinement par exemple). Après ce n'est pas à moi de décider si le jeu en vaut la chandelle.
[*] la NES mini & la SNES mini par exemple, ce ne sont "que" des émulateurs dans un joli écrin.
À noter qu'il existe un outil, Corrode , capable de convertir du code C vers Rust (en revanche le projet n'a plus l'air très actif).
Évidemment ce n'est pas magique, mais l'outil a quand même réussi à convertir le code de CVS (50K lignes de code).
Dans le cas présent il est clair que si le code n'est déjà pas du joli C (pour des raisons évidentes), passer de l'asm à du Rust idiomatique ne va pas se faire sans travail de la part des codeurs.
Il ne s’agit pas de contributeurs qui sont, en effet, sonores, mais de personnes qui contribuent avec de l’effet sonore.
À titre personnel j'aurais mis "effets sonores". Si on parlait de cinéma libre, j'imagine qu'on dirait "des contributeurs en effets spéciaux" ; même si on peut parler d'un effet spécial au singulier (ex: "tel effet spécial a été réalisé avec Blender"), il me semble qu'on en parle au pluriel en général.
J'imagine que c'est de l'humour, mais vu l'incubateur d'excellence qu'est LinuxFr, je vais quand même répondre. :)
À part des cas très spécifiques, par exemple toutes ces conditions sont vérifiées:
on n'a pas de thread donc pas possible que ça introduise un bug.
on a vérifié que l'optimisation règle effectivement un problème en production très critique.
on doit livrer très rapidement une version qui corrige ledit problème mais sans casser l'API, et derrière on fera une version avec une nouvelle API correcte (celle que je proposait par exemple) (on peut même garder la vieille API en "deprecated").
soit on garde la vielle version (lente mais correcte), soit on fait une version rapide et correcte (ce qui en l'occurrence n'était pas bien long, les lignes en plus n'étant quelques déclarations). Mais conseiller en premier une bidouille infâme ne me semble pas une bonne chose ; le C++ est déjà assez piégeux comme ça.
[^] # Re: C'est quoi "Twitch" ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Twitch et copyleft. Évalué à 7.
Il faut bien voir qu'une grande partie de l’intérêt de Twitch vient du fait que ça soit du streaming en direct (il y a aussi des VOD—comme pour Youtube par exemple—ainsi que la possibilité de rediffusion, mais ce n'est pas le mode de fonctionnement principal) avec un chat intégré, pour interagir avec le streamer et les autres spectateurs. On peut donc poser des questions (ou y répondre) en direct ; on est loin de l'interaction qu'apporte les commentaires Youtube.
Un des streamers chez qui je vais souvent (pour du jeu) a fait aussi des sessions de code où il développait son site Web ; c'était l'occasion de discuter avec d'autres habitués (ou pas) en écoutant de la musique (je travaille en parallèle, ce n'est pas quelque chose qu'on est forcé de regarder intensément), de donner son avis sur un visuel du site en direct (ex: "je préfère l’icône d'avatar en plus grand").
Cela n'a pas la prétention de remplacer la documentation écrite, c'est une expérience plus sociale (même si ça permet aussi d'apprendre des choses). Comme souvent, les nouveaux usages ne remplacent les autres, ils ouvrent juste le champ des possibilités (les guitares électriques n'ont pas remplacé les guitares acoustiques).
[^] # Re: Mauvaise idée ?
Posté par GuieA_7 (site web personnel) . En réponse au message détecter l'OS depuis un code compilé. Évalué à 1.
Désolé si je n'ai pas été clair ; je ne dis pas que ces détections dynamiques sont intéressantes dans votre cas précis (que je ne connais pas), c'était juste des exemples où la détection à l'exécution avait du sens. Le cœur de mon propos étant que ce que voulez faire ne fait pas partie de cette liste de cas pertinents, pour la bonne raison que c'est sûrement une mauvaise idée. Parce que vous voulez tester que ça fonctionne sous Windows (c'est très bien) mais vous sabordez le travail juste derrière (et ça c'est moins bien).
Je ne suis pas sûr de comprendre le lien avec mon message ; si vous répondez à ma partie sur la détection du CPU, voici une explication plus détaillée.
Si vous détectez à l'exécution le type de CPU, vous pouvez par exemple utiliser des versions spécifiques écrites en langage assembleur avec des instructions spécifiques à l'architecture. Le noyau Linux a par exemple des versions écrites en langage assembleur pour ses algorithmes de chiffrement, qui sont utilisées dynamiquement quand c'est possible. Mais ça nécessite du travail de la part du codeur (ce n'est pas juste un flag compilateur), aussi le jeu doit en valoir la chandelle. Et même si vous compiliez pour cette architecture spécifique avec gcc, il n'est pas dit que le compilateur soit assez intelligent pour générer de lui-même la version la plus optimisée (sinon les développeurs Linux auraient généré ce code plutôt que de l'écrire à la main…).
# Mauvaise idée ?
Posté par GuieA_7 (site web personnel) . En réponse au message détecter l'OS depuis un code compilé. Évalué à 4.
Détecter dynamiquement :
tout en ayant un seul binaire estampillé "Windows", ça me parait une bonne idée pour éviter d'avoir 1000 combinaisons (genre seven+2cores+intel, w10+8cores+amd) qui vont être un enfer pour l'utilisateur.
En revanche détecter qu'on est sur Wine ça ne va conduire qu'à un seule chose à mon avis: un programme qui tourne bien sous Wine, mais pas sur un vrai Windows (puisque tout un pan du code ne sera jamais testé).
# Petite revue de code...
Posté par GuieA_7 (site web personnel) . En réponse au journal Mon premier projet open source. Évalué à 6.
…parce que ça m'amuse.
En général il est déconseillé d'utiliser des objet mutable comme valeur par défaut (car c'est au final une variable globale utilisée par tous les appels à la fonction/méthode).
Il serait mieux d'utiliser
with, ce qui fermerait proprement et automatiquement le fichier.Sinon ça me parait OK.
[^] # Re: Une histoire de communication
Posté par GuieA_7 (site web personnel) . En réponse au journal J'ai fait un jeu. Évalué à 2.
Ce n'est vrai pour un certain type de crowdfunding, comme avec des sites du genre Kickstarter, IndieGogo ou Ulule.
Il existe d'autres types de financement pour lesquels tu n'es pas obligé convaincre "beaucoup" de gens en peu de temps, comme les systèmes proposés par Patreon, Tipeee ou Liberapay.
Après si tu veux que des gens te donnent de l'argent, il faudra toujours faire de la publicité d'une manière ou d'une autre (à part être déjà connu et reconnu).
[^] # Re: Moi aussi j'ai fait un jeu :)
Posté par GuieA_7 (site web personnel) . En réponse au journal J'ai fait un jeu. Évalué à 2.
J'espère que tu viendras nous faire un journal au moins pour la 1.0, ça a l'air prometteur.
[^] # Re: tout le monde s'en tamponne le coquillard
Posté par GuieA_7 (site web personnel) . En réponse au journal J'ai fait un jeu. Évalué à 8.
Des centaines de personnes c'est en fait minuscule sur un site aussi gros que kickstarter ; des centaines de vues c'est je pense assimilable à quelques badauds qui se sont perdus.
Un site comme LinuxFR, pourtant bien plus petit et spécifique (logiciel libre, francophone) possède des milliers de comptes (plus les lecteurs non-inscrits) ; donc ton journal va sûrement faire bien plus que des centaines de vues !
Tantôt tu parles d'intérêt, tantôt de valeur de l'idée, tantôt du prix que des gens veulent mettre dessus. Tout ceci est certainement très clair dans ta tête, mais personnellement je ne comprends pas ce que tu cherches.
Est-ce que si des gens sont prêts à venir contribuer à ton projet sur leur temps libre, est-ce que tu appelles ça de la valeur
(parce que pour ces gens, ton projet a de la valeur, sinon il utiliseraient leur temps libre autrement) ?
Si des gens installent gratuitement ton jeu (sachant que tu dis aussi que faire plein de brouzoufs n'était pas le but), y jouent, s'amusent et te éventuellement disent merci, est-ce tu appelles ça de la valeur ?
J'avais bien aimé ce texte de Ploum (parmi tant d'autres): https://ploum.net/votre-idee-ne-vaut-rien/
En gros une idée n'a aucune valeur, seule la réalisation d'une idée a de la valeur. C'est vrai pour une idée innovante ; mais dans ton cas où ton jeu semble très classique (et des tas de jeux existants réalisent déjà ce que toi tu ne fais que promettre) c'est d'autant plus vrai. Une fois fini ton jeu serait peut-être très bien, mais là, même ce que tu promets n'a rien d'original.
Il n'est donc pas étonnant que sa valeur marchande soit nulle ; pour 5€ on peut acheter des tas de jeux déjà finis et largement plus ambitieux ; 5€ ce n'est effectivement pas énorme, mais il n'y avait pas vraiment de raison de te les donner à toi (c'est mieux investit en achetant un jeu déjà fini, ou en finançant un jeu qui semble apporter quelque chose de nouveau). Mais encore une fois cette valeur marchande, on ne sait pas si c'était la valeur que tu voulais mesurer (il a de la valeur sans aucun doute, mais pas de valeur marchande—en l'état actuel en tout cas).
[^] # Re: tout le monde s'en tamponne le coquillard
Posté par GuieA_7 (site web personnel) . En réponse au journal J'ai fait un jeu. Évalué à 7.
Le premier Mario Kart est Super Mario Kart, et est sorti sur Super NES.
Voila c'était ma remarque tout à fait dispensable :)
[^] # Re: Des questions.
Posté par GuieA_7 (site web personnel) . En réponse au message Recherche programmeur. Évalué à 5.
Merci pour vos réponses.
Peut-être qu'une présentation plus détaillée desdits jeux (et des visuels, on aime ça les images:) ) serait une motivation supplémentaire pour d'éventuels contributeurs/partenaires.
Je vous souhaite bonne chance pour la suite, et j'espère avoir des nouvelles sur LinuxFr quand le projet aura avancé.
# Des questions.
Posté par GuieA_7 (site web personnel) . En réponse au message Recherche programmeur. Évalué à 4.
Je ne suis pas candidat, car vu la faible vitesse à laquelle avance mes projets personnels je ne voudrais pas vraiment impliquer quiconque là dedans. En revanche je trouve votre post intéressant & intriguant (car sortant nettement de l'ordinaire) et j'aurai des questions, qui pourraient peut-être permettre d'éclaircir certains points qui ne me semblent pas clairs.
Quand vous parlez de faire ces jeux en Open-Source, est-ce que vous parlez uniquement du code, ou vous englobez aussi les différents assets (images, sons etc…), voire le nom ? En clair, vos jeux ont j'imagine une identité visuelle ; est-il question de pouvoir réutiliser ces visuels existants et de les placer sous une licence libre, genre CC-BY/CC-BY-SA (mais pas les clauses NC & ND qui ne sont pas libres) ?
Autre question: est-il question pour vous de gagner de l'argent avec ces jeux vidéos, ou bien êtes vous juste à la recherche de "repreneurs" pour ce travail effectué afin que ça puisse servir éventuellement aux autres ?
[^] # Re: Pas encore de gestion des erreurs d'allocation mémoire
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Conférence GStreamer 2017 : Oxydation de GStreamer. Évalué à 4.
Ça voudrait dire que l'environnement est configuré pour générer des core dumps (depuis bien longtemps sous Debian/Ubuntu ce n'est pas le cas dans la configuration de base, vu que c'est plutôt pour les développeurs), et que ces dumps sont lisibles de l'extérieur. Ça ne veut pas dire qu'il n'existe pas de scénario (ça serait assez pédant vu la complexité du problème), mais pour le coup celui-là ne me parait pas hyper pertinent (parce que ça indique plutôt une faille qui n'a pas grand chose à voir avec le logiciel en lui-même).
[^] # Re: Pas encore de gestion des erreurs d'allocation mémoire
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Conférence GStreamer 2017 : Oxydation de GStreamer. Évalué à 3.
Tu as tout à fait raison.
J'aurais tendance à dire que si l'instruction illégale est toujours la même et ne correspond pas aux données du fichier (comme dans un buffer overflow), ça me parait difficilement exploitable.
Après comme je ne vais pas aller vérifier, et que je n'ai pas les connaissances suffisantes pour affirmer que ça suffit à l'absence de faille, je vais botter en touche en disant que la sécurité est un point auquel l'équipe de Rust a toujours fait très attention (et qu'en l'occurrence le problème est connu).
[^] # Re: Pas encore de gestion des erreurs d'allocation mémoire
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Conférence GStreamer 2017 : Oxydation de GStreamer. Évalué à 7.
Ton commentaire est intéressant, mais tu présentes les choses de manière un peu provocante dans cette phrase:
L'interview parle plutôt de bugs étranges et de failles de sécurité, plutôt du fait que ça ne plante jamais. Par exemple à propos de C/C++:
Et dans ton cas il n'y a ni de faille de sécurité (enfin jusqu'à preuve du contraire), ni de symptôme bizarre (un message nous indique clairement le problème—en revanche oui le SIGILL est pour le moins déroutant j'avoue).
Et quand le texte dit qu'un programme Rust ne plante pas, il se ravise aussitôt:
(et on n'a pas une erreur de segmentation :) )
J'ajouterai qu'il s'agit d'un problème dont les créateurs de Rust sont au courant (tu nous donnes justement les liens qui vont bien) qui devrait être réglé à terme, et pas d'une limite intrinsèque et insoluble du langage (comme l'obligation d'avoir des pauses dans un langage basé sur un GC par exemple).
Mais comme tu le soulignes le terme "sûr" qu'utilise Rust n'est pas sans ambiguïté ; il s'agit de cohérence des données (pas de pointeur qui écrit au pif dans la mémoire, ou de data-race entre 2 threads par exemple), pas du fait qu'un programme ne va pas terminer prématurément. Par exemple, il est souvent dit qu'il n'y pas de fuite mémoire avec Rust ; en fait c'est faux. La gestion mémoire est certes très bonne, mais par exemple il est possible lorsqu'on utilise du comptage de référence (on en a besoin dans certains cas) de "perdre" de la mémoire si on a des cycle de références. C'est bien dommage, mais ça ne rentre pas en contradiction avec la définition de sûreté du langage (le programme pourra finir par être à court de mémoire comme dans ton cas, mais ça n'introduira pas de faille de sécurité par exemple).
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 2.
En effet le site officiel parle bien d'une campagne sur OpenFunding (qui a l'air mort).
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 3.
Certes. Mais dans cas tu es le plombier et tu dis à des non plombiers qu'ils devraient faire la réparation (eux-mêmes) et que ça prendra 2h ; personnellement je le comprends comme "ça va vous prendre 2h". Mais c'est peut-être moi. Peu importe.
Je suis globalement d'accord avec tout ton paragraphe. Mais il n'est pas en contradiction avec ma phrase ; même des pros vont avoir besoin de beaucoup de temps pour faire quelque chose de soigné. Si tu codes (mais c'est vrai pour tout), alors tu sais ce que c'est que faire un sympathique prototype en 3h, mais au final passer 2 semaines sur ton patch pour gérer tous les cas particuliers pénibles etc…
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 3.
Je suis d'accord avec l'ensemble de ton commentaire. Je reviens sur 2 points en particulier:
Intéressant. Je me suis déjà amusé à faire le tour des plateformes de financement participatif à la recherche de projets de jeux libres, et je n'avais rien trouvé (sauf un anecdotique jeu genre casse brique pas du tout attrayant). La seule exception semble être la campagne d'amélioration de 0AD.
Du coup l'existence de tels paliers dans des projets de jeux m'intéresse, mais j'y vois 2 bémols:
J'ai axé ma réponse autour du temps, en rapport au message auquel je répondais ; ce n'est évidemment pas le seul problème.
Mais pour préciser ma réponse, je parlais de petits jeux d'arcade comme celui de cette dépêche. Pour de tels jeux, il n'y a pas de grosse difficulté technique (le côté artistique c'est autre chose) (ex: il ne s'agit pas de faire un modèle d'éclairage dynamique 3D nécessitant des connaissances pointues en optique et en pipeline 3D), je pense pour l'aspect mathématique un niveau 4ème doit suffire (bon allez si on peut envoyer une bombe, faut peut-être savoir ce qu'est une parabole). Du coup même si ce sont des amateurs qui codent, s'ils ont assez de temps, ils vont y arriver (le code ne sera peut-être pas terrible, mais ça marchera à peu prêt). Mais même pour un petit jeu comme ça, il faudra pas mal de temps pour faire tous les petits détails qui font que ça rend bien.
Évidemment pour des jeux plus ambitieux le problème sera tout autre.
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 7. Dernière modification le 07 novembre 2017 à 00:49.
Certes, mais en parlant d'une journée max de boulot, tu montres à mon avis à quel point il est courant dans le milieu de l'informatique de sous-évaluer le temps de développement (mais peut-être es-tu commercial dans une SSI :) ).
Alors oui, il existe des gens capables lors d'une GameJam de 24h de pondre seul des jeux même plus ambitieux que ça (et en faisant les graphismes et le son) (regardez ce que DeepNight arrive à faire par exemple), mais il s'agit de gens rodés à cet exercice depuis de longues années, qui connaissent leur outils de création de jeux sur le bout des doigts ; généralement ce sont des professionnels de la création de jeux vidéos. Donc s'ils sont capable de faire ça en un week-end, il ne faut pas oublier les années de création de jeux qui on permis d'atteindre ce niveau.
De simples amateurs qui se mettent à la création de jeux il leur faudra bien plus. Ça ne sera pas des années de développement évidemment, mais moi rien que pour lire la documentation et faire les tutoriels de GodotEngine, ça m'a largement pris plus d'une journée, pendant mes vacances. Il est tout à fait possible que tu sois bien plus compétent que moi, mais je bosse depuis suffisamment longtemps pour savoir que je suis plus compétent que la moyenne. Après je serai heureux que tu viennes nous présenter les applications libres que tu codes ; parce que si tu es capable de faire ça en quelques heures, j'imagine qu'en quelques jours de travail ça doit vraiment être impressionnant.
PS: 90% du code écrit ne fait rien de bien complexe. Pourtant le diable se cache dans les détails et même faire quelque chose d'assez trivial, quand on veut que ça soit de bonne qualité, ça prend du temps. Sinon nous aurions des tas de jeux libres de qualité. Hélas on sait qu'il ne sont pas très nombreux.
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 3.
Visiblement l'idée est d'améliorer le jeu (avec un peu d'imagination, les possibilités sont nombreuses), pas juste de garder quelque chose de figé qu'on va faire tourner sur plein de plateformes. Auquel cas, la façon la plus pragmatique de faire aurait été de faire de l'émulation [*] ; ce n'est pas forcément la plus excitante techniquement évidemment.
Donc un langage de plus haut niveau peut avoir du sens (pour écrire un code réseau plus sereinement par exemple). Après ce n'est pas à moi de décider si le jeu en vaut la chandelle.
[*] la NES mini & la SNES mini par exemple, ce ne sont "que" des émulateurs dans un joli écrin.
[^] # Re: Pourquoi en C en 2017 ?
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Mr.Boom version GNU/Linux. Évalué à 4.
À noter qu'il existe un outil, Corrode , capable de convertir du code C vers Rust (en revanche le projet n'a plus l'air très actif).
Évidemment ce n'est pas magique, mais l'outil a quand même réussi à convertir le code de CVS (50K lignes de code).
Dans le cas présent il est clair que si le code n'est déjà pas du joli C (pour des raisons évidentes), passer de l'asm à du Rust idiomatique ne va pas se faire sans travail de la part des codeurs.
[^] # Re: Trop léger
Posté par GuieA_7 (site web personnel) . En réponse au journal Raspberry Pi et vintage. Évalué à 2.
Ou avec des ventouses. :)
[^] # Re: qui veut une dépêche ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Comment je suis devenu chef de projet. Évalué à 7.
À titre personnel j'aurais mis "effets sonores". Si on parlait de cinéma libre, j'imagine qu'on dirait "des contributeurs en effets spéciaux" ; même si on peut parler d'un effet spécial au singulier (ex: "tel effet spécial a été réalisé avec Blender"), il me semble qu'on en parle au pluriel en général.
Après ça n'est que mon avis.
# Merci !
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Libération du jeu Planète Blupi. Évalué à 10.
Merci au créateurs & ayant droit d'avoir accepter de libérer leurs jeux (et de vraiment tout libérer, pas juste le code, comme on le voit "souvent").
Merci à toi d'avoir fait cette démarche de demande de libération, et de travailler dessus évidemment.
J'aimerai que plus de gens dans l'industrie s'en inspirent.
[^] # Re: Preuves ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2.
C'était une façon détournée de dire "bravo" et "j'ai hâte de lire ces dépêches". :)
(en vrai je code déjà du libre à plein temps ; ça vaut ce que ça vaut, mais je pourrai difficilement faire plus)
[^] # Re: Preuves ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 2.
Donc en fait tu ne bosses pas sur projet qui mérite une dépêche, mais plusieurs.
Je me sens nul…
[^] # Re: essayer Julia ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 5.
J'imagine que c'est de l'humour, mais vu l'incubateur d'excellence qu'est LinuxFr, je vais quand même répondre. :)
À part des cas très spécifiques, par exemple toutes ces conditions sont vérifiées:
soit on garde la vielle version (lente mais correcte), soit on fait une version rapide et correcte (ce qui en l'occurrence n'était pas bien long, les lignes en plus n'étant quelques déclarations). Mais conseiller en premier une bidouille infâme ne me semble pas une bonne chose ; le C++ est déjà assez piégeux comme ça.