Yukito a écrit 109 commentaires

Si, si. C'est dit. Son père était chirurgien, et sa mère prof dans une école d'infirmière. Il n'est pas né riche du tout. Disons, à l'abri du besoin.

Pour la fortune de Mark, il a fondé une autorité de certification (essentiellement, les certificats qui permettent de "certifier" une connexion https sur le web), Thawte, qui était le principal concurrent de Verisign. Et il s'est enrichi au-delà du raisonnable lors de la revente à Verisign. Là où Mark a été très fort, c'est qu'il a revendu en décembre 1999, au sommet de la bulle internet. Trois mois plus tard, en mars 2000, la bulle internet commençait à éclater. Verisign a dû en pleurer.

Malgré tout le respect que j'ai pour Knuth, je pense qu'il fait fausse route avec la programmation lettrée. Le langage des ordinateurs, c'est celui des mathématiques, et non pas celui de la langue humaine naturelle.

Je suis d'accord avec Knuth sur le fait que l'un des points essentiels de la conception d'un programme, c'est qu'il soit compréhensible par les autres humains, et donc que les commentaires et les noms de variables sont importants, mais un programme n'est pas la simple transcription dans le langage des ordinateurs de quelque chose de préexistant dans la langue humaine. C'est quelque chose de différent.

Pour donner une analogie de ce que je veux dire, quand je vais voir un architecte pour qu'il conçoive une maison, je ne veux pas qu'il me rédige un pavé de 20 pages en langue naturelle du style "à droite, on va mettre un escalier, qui débouchera sur les deux chambres". C'est bien plus simple qu'il me dessine un plan de la maison. D'ailleurs, dans sa tête, un architecte pense directement avec le plan de la maison, pas en langue naturelle.

Et ce n'est pas un hasard si on parle de "l'architecture" d'un programme. Ce que je fais le plus souvent dans mon activité de programmation - et j'imagine que je ne suis pas le seul - c'est l'inverse de la programmation lettrée, à savoir de la programmation "graphique". Je prends un bout de papier, et je dessine avec des blocs et des flèches la structure d'ensemble du programme. Si on pouvait laisser facilement ces petits schémas en commentaire dans le source, ce serait génial.

Oui, mais bon, des implémentations, il y en a pas des milliers, hein. Il n'y a en gros que Xfree86 dont le développement est abandonné depuis plusieurs années, et le fork X.org.

Google me semble effectivement relativement toléré par les développeurs, probablement parce que Google est dans l'ensemble très amical vis-à-vis du libre. Google a contribué énormément de code, et soutient aussi financièrement des projets, comme par exemple la fondation Mozilla. En comparaison, Facebook ou Twitter n'ont quasiment rien apporté aux logiciels libres.

Par contre, à titre personnel, je ne participe ni à Google+ ni à Facebook. Je trouve que c'est bonnet blanc et blanc bonnet.

Laisse tomber, ce sont juste des mirliflores.

Moi, aujourd'hui, j'ai rêvé que j'allais sur linuxfr lire un journal sympa et informatif, comme à mon habitude, et qu'en fait je tombais sur du charabia incompréhensible. Et d'un coup, je me suis rendu compte qu'en fait, non, j'étais déjà réveillé. Le flip.

Merci pour l'info. Malheureusement, je suis très loin (au Japon), et du coup, faire le déplacement est difficile. Mais je garde l'idée dans un coin, pour l'an prochain peut-être.

J'ai créé une section "news" sur la page principale du wiki classique. J'y ferai les annonces des principaux changements du code ou du contenu des niveaux (par exemple, une annonce quand on atteindra 10 niveaux de jeu), et normalement elles seront visibles dans le flux rss.

Oui, c'est pas faux. En fait, il y a un flux rss pour le site web classique : http://flukz.org/wiki/feed.php . Je créerai demain une page "news" sur le wiki classique pour y faire des annonces de nouvelles fonctionnalités ou de nouvelle release, et comme ça elles seront visibles dans le flux rss du site.

Mmh, non, pas sur le web, dans le logiciel lui-même :-)
Au fait, au cas où tu n'aies pas vérifié depuis, le niveau que tu avais commencé a pas mal progressé depuis.

Je viens de créer une page "Nouveautés" dans Flukz. J'y listerai les principaux changements du code au fur et à mesure, comme ça, les personnes qui le souhaitent pourront se faire une idée des développements en cours.

Monsieur, à quoi ça sert d'apprendre l'assembleur ?

A quoi tu penses plus précisément ?
A priori, il y a juste la liste des "modifications récentes" directement dans Flukz.

Oui, je vois ce que tu veux dire à propos du pilotage rotatif du vaisseau. Cela donne un gameplay complètement différent. Normalement, ce n'est pas trop dur à implémenter. En gros, il faut que je change la réaction du sprite du joueur lors de l'appui sur une touche et que j'ajoute un paramètre dans les niveaux pour choisir le type de gameplay.

Ce type de gameplay est d'ailleurs particulièrement intéressant si on fait des niveaux qui ne sont pas simplement rectangulaires mais recouvrent une surface qu'on peut explorer aussi bien en longueur qu'en largeur. Mais ça, par contre, c'est une modification nettement plus lourde étant donné le code actuel de Flukz.

Suite à une suggestion de devnewton dans le journal Flukz 0.1, je me permets de te proposer de venir rejoindre Flukz. Il s'agit d'un moteur de shootemup programmé en Qt, dont les niveaux sont entièrement éditables à la façon d'un wiki. La première version vient d'être releasée, il y a quelques jours.

J'ai l'impression que Flukz pourrait fournir l'environnement que tu cherches pour implémenter tes idées. On a déjà une base de code solide et qui ne demande qu'à s'étendre. Bon, c'est codé en C++, avec lequel tu as eu apparemment une expérience difficile, mais la bibliothèque Qt est très bien conçue … et ça change tout. Elle permet d'éviter la quasi totalité des aspects techniques compliqués du C++. Et la base de code de Flukz est déjà suffisamment développée pour qu'il soit possible d'y faire des améliorations uniquement par imitation du code existant, sans spécialement connaître Qt notamment.

Si tu testes Flukz, tu seras peut-être déçu par la "pauvreté" du contenu actuel, et les fonctionnalités limitées des sprites. Comparé à ta superbe video de démo, la route est encore longue. Mais je suis persuadé que la possibilité pour les utilisateurs de participer directement à la création des niveaux à la façon d'un wiki est la fonctionnalité-clef qui permettra à terme de faire la différence sur tous les jeux existants. J'évite de le dire trop fort sur ce site pour ne pas perdre ma crédibilité (ça se perd facilement, il paraît :-), mais bon, voilà, l'objectif de Flukz, c'est de devenir l'équivalent de wikipedia pour les jeux videos 2D. Shoot'em up, mais aussi jeux de plateforme ou jeux de simulation type simcity.

Enfin, bref, tu es plus que bienvenu si ça t'intéresse, aussi bien en tant qu'utilisateur du logiciel pour créer des niveaux avec les fonctionnalités existantes, qu'en tant que développeur pour participer au codage de nouvelles fonctionnalités.

Ah, c'était toi :-). Merci d'avoir pris le temps de tester. Je réponds à tes différentes suggestions :

• le commentaire est en fait facultatif. Tu peux le laisser vide et simplement appuyer sur entrée. (le commentaire est obligatoire uniquement dans le cas précis où on ajoute un nouveau fichier)
• le fait que tu parles de "sauvegarde de travail" correspond en fait à un manque actuel du logiciel. Pour l'instant, on ne peut pas tester le niveau pendant l'édition, ce qui oblige à sauvegarder, à quitter l'édition pour tester, puis à reprendre l'édition. C'est vite énervant dès qu'on travaille sur un niveau plus que quelques minutes. Pour la prochaine version, je vais essayer d'ajouter une méthode pour tester les niveaux en cours d'édition.
• tout à fait d'accord sur l'idée de pouvoir charger plusieurs images à la fois.
• pour supprimer un sprite, il suffit de cliquer dessus (le cadre de sélection apparaît autour du sprite) et d'appuyer sur la touche de suppression du clavier. Ça me fait penser qu'il faut que je crée un tutorial à propos de l'édition des niveaux de jeu.
• un peu plus haut, Larry aussi avait fait une remarque sur la popup de propriétés. Tu vois les choses comment à la place d'une popup ?
• le scripting de l'IA des ennemis, ça, c'est un vaste (et joli) sujet…

(et je vais essayer de contacter shingo, peut-être que ça peut l'intéresser, effectivement)

Oui, je vais essayer de déplacer la position par défaut de la fenêtre de propriétés sur le côté, ou de la "docker". En attendant, je te conseille de ne pas fermer la fenêtre de propriétés, parce qu'effectivement elle réapparaît à chaque clic. Il faut simplement la déplacer un peu sur le côté (sans la fermer). J'ai tellement pris l'habitude de faire ce geste en début d'édition d'un niveau que j'en avais oublié que c'était contre-intuitif.

Voici une capture d'écran en mode wiki. La disposition est très similaire à celle d'un wiki classique, avec sur la gauche des liens "Accueil" et "Modification récentes", et sur la droite, le contenu de la page en cours de visionnage (la page d'accueil sur cette capture d'écran).

Et voici une capture d'écran lors du mode shootem up (quand on clique par exemple sur le lien "premier jeu"). La fenêtre du logiciel se redimensionne automatiquement lorsqu'un niveau de shootem up est lancé, et le mode wiki devient invisible jusqu'à la fin du jeu.

Sauf erreur, je crois que ni phonon ni libvlc ne disposent de ce que j'avais vraiment besoin, à savoir le mixage en temps réel de sons issus de sources audio différentes. Mais il est fort possible qu'il y ait des choses dans libvlc qui pourraient être utiles pour supporter plus de formats audio.

Au niveau du protocole, j'ai volontairement évité les protocoles existants. A terme, je veux décentraliser certains aspects du logiciel (notamment en faisant des réplications des données sur les clients), donc http n'est pas adapté, mais je ne veux pas juste faire de l'échange de fichiers comme dans les logiciels peer-to-peer actuels, ou juste de l'échange de messages comme dans les logiciels de chat (xmpp). Au niveau des fichiers, par exemple, je veux pouvoir contrôler les fichiers, comme sur un site web classique.

Comme je ne sais pas vraiment la forme finale qu'aura le protocole, ni exactement à quoi il servira, je me suis dit que le plus simple, c'était de le faire à ma sauce, et de le faire évoluer au fur et à mesure que les besoins apparaîtront.

L'utilisation de hashs aussi bien dans le protocole que dans la structure de stockage des fichiers est d'ailleurs une préparation de la réplication des données entre les clients. En gros, quand un client voudra un fichier, il lui suffira de demander le hash au serveur maître, et le serveur maître enverra en plus du hash l'adresse d'un serveur esclave. Le client n'aura plus qu'à télécharger le fichier depuis le serveur esclave, et vérifier que les hashs correspondent.

C'est vraiment une première version, jamais testée par des utilisateurs externes au projet. Un journal discret me paraît préférable pour l'instant…

Eh, eh. Un truc sympa grâce à un protocole maison basé sur Qt. Juste plus haut, je voulais faire un petit nettoyage et puis donner l'adresse, mais en fait, j'ai un problème de décalage horaire. J'habite au Japon, et il est presque l'heure de se coucher. Impossible de finir ça ce soir. Mais je reviens demain, promis.

Pour les petits projets que j'ai fait jusqu'ici, subversion me convenait assez bien. Et du coup, je n'ai jamais essayer git sérieusement. Mais c'est un truc auquel je pense.

D'abord, merci à tous les messages plus haut. Ça m'a motivé à releaser comme ça, en l'état.

Je vais juste nettoyer le serveur des tests faits jusqu'ici, histoire de repartir d'une base propre, et puis je reviens juste après donner l'adresse du site web et du repository subversion et décrire de quoi il s'agit. Sinon, dans un an, ce projet sera encore sur la ligne de départ.