case42 a écrit 610 commentaires

Y a un moment ou plusser ne suffit plus, il faut aussi dire merci.

Merci.

le problème est que je suis un peu à la ramasse en jeux

Relis-toi, il y a beaucoup de bon sens dans cette phrase.

Le problème, c'est que tu as beaucoup de certitudes pour un mec qui avoue ne pas y connaître grand chose, tu ne crois pas?

mais aussi parce que ces accusations sont débiles

Quelles accusations ?

Les accusations d’être dans un déni total du problème je suppose… CQFD…

Je vais te révéler un secret de femme : quand on passe a la télé, on se maquille ( oui oui, même les hommes ) .

Ok, ça doit être de la résistance utilisateur alors, moi les salons XMPP m'ont toujours paru inutilisables… Sûrement parce que je suis trop habitué a IRC. Enfin du coup ca va pas etre tres complique de tweaker mon bot pour qu'il poste sur un salon XMPP :)

Mon use case est un peu le même que Michel: quand je code, je suis connecté. Je veux être notifié instantanément des commits. Quand je me remets a coder après une pause, je pull les changements et le lis les logs, donc je n'ai pas besoin d'avoir les notifs que j'ai ratés. Et je n'ai pas envie de pourrir mes mails…

J'avoue que la différence est ténue, mais je garde "instant messaging" pour les systèmes orientés "1 a 1" (MSN, ICQ, XMPP, AIM, etc.) et pas pour les systemes orrientes "salons". Je précise bien "orientés" car les deux savent faire l'autre, juste moins bien.

Or pour un travail en groupe, c'est le mode "salon" qui a du sens (je trouve) , car il est important que tout le monde participe aux conversations qui ont lieux, même entre 2 devs (au du moins tout le monde doit les lires). Et les systèmes de messagerie instantanée favorisent la conversation 1 a 1 et rendent les discussions a plusieurs difficiles a mettre en place et a conserver. Dans mon précédent projet, je me battais contre les discussions 1 a 1 entre devs, qui donnaient de mauvais résultats (décisions moins bonnes, perte de temps, car quand A parle a B et qu'au bout de 30 minutes ils annoncent a tous qu'ils ont décidées X, C s'exclame "ha mais non, on peut pas, a cause de Y" , et op, 30 minutes de perdues). Et pourtant, on était tous sur IRC…

Si je passe a XMPP sur ce projet la, c'est juste parce qu'on est 2 :)

Moi non plus je ne trouve pas IRC hasbeen, mais je crois qu'on est bien les seuls. Les jeunes sont élevés a l'instant-messaging, les concepts d'IRC et l’aridité des clients sont complètement aliens pour eux. S'tay mieux a vent, bla bla bla…

Je ne dis pas que c'est la solution miracle, ça dépend beaucoup de ton tempérament, mais tu as pensé a travailler en indépendant? En cherchant des clients plutôt qu'un employeur, tu as le choix du choix. Tu n'es pas obligé de t'embringuer dans une carrière figé, tu peux "picorer" les clients et donc les projets… Et mettre un terme a une collaboration qui se passe mal. Bon je le vends pas comme une solution miracle, j'ai pas assez d’expérience dans ce domaine, et ça dépend vraiment de ton caractère, mais comme ca n'a pas l'air d'avoir été évoqué…

Tu as inventé Reddit? :)

http://www.reddit.com/
http://fr.wikipedia.org/wiki/Reddit

Le fait que la nouvelle soit arrivée sur Slashdot et Reddit ne doit pas y être étranger…

Si quelqu'un au CERN pouvait aller chercher un extincteur pour éteindre la station Next…

Les besoins sont si différents d'une étude d'un autre livre ?

En fait oui. Pour les évangiles en tous cas, on veut au moins pouvoir les lires "en parallèle". En format papier, ça s'appelle une synopse : http://fr.wiktionary.org/wiki/synopse
( Si je voulais troller je rajouterais que de cette façon les failles du textes ne sont que plus criantes ;) )

J'ai fait Epitech. Tout ce que je peux en dire, c'est que des qu'on parle d'un truc qui a un rapport de près ou de loin avec Epita/Epitech/Ionis/Nicolas Sadirac ici, on se fait dezinguer la tronche.

Tu te base sur les infographies ou sur du texte? Dans le programme je vois du C/UNIX, C++, X-Window (comme a Epitech)… Rien qu'on ne puisse faire une un Mac, rien qui nécessite forcement d’être sous Mac. Et X-Window c'est pas vraiment l'environnement de prédilection chez Mac…

Edit: et en creusant plus dans le programme, le seul point du cursus qui fait appel a une tech explicitement proprio, c'est .Net . Et le chapitre "dev embarqué" est sur Android, pas IOS, alors pour le coté vendu a Apple, on repassera…

… et depuis hier KSP est disponible sur Steam, avec dors et déjà un succès entonnant pour un jeu aussi obscur: premier des ventes dans le classement Linux et Mac, second pour le classement des jeux indépendants, sixième dans le classement global…

Je trouve que c'est un peu tendu de faire un vol tres longue distance dans la version Vanilla, par exemple atteindre le second satellite et revenir tend du miracle.

Atteindre Minmus n'est pas difficile qu'attendre Mun, grâce aux "maneuver nodes". Ce qui est vraiment plus dur c'est d'atteindre les autres planètes…

Et puis les moteurs ioniques sont inutiles c'en est navrant…

Oui ils sont assez dur a utiliser, ce qui n'est pas plus mal car leur impulsion spécifique de ouf déséquilibrerait le jeu. Le moteur le plus efficace pour un voyage interstellaire reste le moteur nucléaire NERVA.

Sinon c'est quoi cette histoire de 1-body

La physique orbitale n'est simulée que vis a vis d'un astre pour chaque objet. Toutes les orbites sont des ellipses pures et il n'y a pas de perturbation. C'est une simplification de la réalité mais une approximation assez proche tout de même.
Ça se sent surtout a la frontière de la sphère d’influence d'un astre, ou tu passes de façon abrupte de l’influence d'un astre a l'autre, alors que dans la réalités c'est progressif (tu subits l’influence de tous les astres de l'univers, c'est juste qu'a part quelques-uns qui sont assez proches, on peut ignorer les autres).

Et la désintégration a cause de la vitesse, rassurez moi c'est une blague

Je ne sais pas ce que tu as compris, ce qu'on disait c'est que la version 0.19 introduit un effet visuel du plus bel effet pour les rentrées atmosphériques (ça flambe!), mais ça ne se traduit pas encore au niveau gameplay: le vaisseau ne chauffe pas, il n'y a aucune conséquence si tu rentres dans l’atmosphère n'importe comment (sauf si tu rentre tellement vite que tu arrache tes parachutes a l'ouverture…) . J'ai aucune doute que ca viendra dans une prochaine mise a jour.

Ce modèle de développement semble de plus en plus populaire dans l'univers des jeux indépendants sur PC. C'est le modèle qu'avait adopté Minecraft (je ne sais pas si son succès est lie a ce modèle, en tous cas manifestement ça ne l'a pas pénalisé :) ).

Il y a beaucoup de point commun selon moi entre Minecraft et Kerbal Space Program:

• jeux indépendants développé par une petite équipe
• "release early, release often" (développement incrémental)
• cible le PC
• prix croissant au fur et a mesure des releases.
• Jeu visant une niche (même si Minecraft a "explosé", ca reste un jeu de niche)
  

( Edit: je souhaite bien évidement le même succès a KSP qu'a Minecraft, ou même une fraction de ce succès, ce sera déjà pas mal :) )

Oui il n'y a que les effets visuels de la re-entree (et aussi le passage du mur du son), mais pas d’échauffement sur les vaisseaux. Le model atmosphérique est très primitif, les avions ne se comportent vraiment pas de façon réaliste, et les effets de décélération sont applique sur le centre de gravite des vaisseaux, ce qui empêche de pouvoir contrôler sa rentrée (comme le faisaient / font les capsules Gemini, Apollo et Soyouz). En gros, c'est calculs sont justes, mais c'est une approximation grossière, j’espère que ça évoluera car ça ouvre des possibilités intéressantes sans rendre le jeu plus dur (au contraire).

Orbiter, j'y jouais énormément il y quelques années, mais je n'ai jamais réussi a bien le faire marcher sous Linux, et je l'ai abandonne a cause de ça. Orbiter est beaucoup plus réaliste et a la prétention d’être un vrai simulateur, pas un jeu comme KSP. Les deux ont des buts divergeant donc c'est bien que les deux projets existent. Je ne suis plus l’actualité d'Orbiter, j'ai l'impression que ca stagne, surtout a cause de l'auteur qui a d'autres chats a fouetter mais n'a jamais voulu l'open-sourcer (c'est pas faute de l'avoir demande a corps et a cri…)

Personnellement je le trouve relativement facile d’accès !
[…]
Pour résumer c'est un très bon jeu pour ceux qui s’intéresse a la conquête spatiale !

Je pense que ton jugement est un peu biaisé quant a la difficulté de KSP :)
Quand on est passionne d'espace et qu'on est bien documenté, on a des bases en astrophysique et donc une longueur d'avance sur le commun des mortels pour appréhender KSP, mais ça reste très très raide… Il n'y a qu'a voir les posts rageur de débutants sur le forum ou reddit qui au bout d'une semaine n'ont toujours pas réussi a mettre un satellite en orbite… Et qui pourtant s'acharnent! :)

Ah oui petit défaut mais qui simplifie vachement le jeu c'est que votre fusée gravite autour d'un seul point alors que dans la réalité c'est pas vraiment ca :p

Oui il y a pas mal d’approximations physiques mais ça reste une simulation réaliste, et qui pour moi a un gros potentiel pédagogique… (c'est pas vraiment plus dur pour le joueur d'avoir une simulation en N-body plutôt qu'1 , ça permet surtout de faire des prédiction de trajectoires pour pas cher (en CPU) avec les patched conics). Le model de vol atmosphérique est un petit scandale aussi, mais je ne doute pas que ca s'arrangera dans les versions suivantes.

Je savais que j'avais oublier d'insister lourdement sur un point… Effectivement il n'est pas open-source.
(edit: je l'ai rajouter en tag, voila :p )

De manière générale, la POO est plus contraignante que la programmation par composant (y en a qui aiment être très contraints par le langage, moi j'aime bien quand le langage me fiche un peu la paix…). La programmation par composant te permet une souplesse au runtime que la POO ne te permet pas. Par exemple, avec un ECS tu peux proposer a l'utilisateur un editeur d’entité ou il pourra construire lui même son entité customisee. Avec la POO pour faire ca tu devrais avoir une classe qui hérite de tous les objets de bases, ce qui est assez infâme.

Je sais qu'il y a deux écoles, mais pour pas beaucoup plus de temps que tu as passe a écrire cette doc,
tu pourrais avoir un début de première implémentation qui marche. Ça t'aurait permis de trouver tout
un tas de problèmes de designs en l’implémentant, car en réfléchissant sur le papier tu n'as aucun
garde-fou, alors qu'en implémentant, si une idée ne fonctionne pas, ça se voit tout de suite.

En codant des tests unitaires en même temps, les tests deviennent une spécification, c'est juste
qu'elle est écrite en JS au lieu d’être écrite en anglais.

Sinon, les ECS c'est la vie, j'ai deux projets en cours basés plus ou moins sur ce paradigme
(un en C++, l'autre en JS), et j'en suis très content.

Bon courage pour la suite, mais réveille moi quand t'as du code qui tourne :)

Pardon, mais au XXIieme siecle, faut plus préconiser SVN. Comme un récent journal l'a indiqué, GIT, ou si la courbe d'apprentissage est un problème, Mercurial.

… Et donc les deux mesures a 60fps laissent présager que le driver sous Linux attend le vSync alors que celui sous Windows/D3d ne le fait pas. Ce qui laisse présager que la mesure a 60fps ne reflète pas les capacités de la configuration, mais aussi pose un doute sur la validité de la valeur moyenne. Donc on ne sait toujours pas vraiment si Win/D3d est meilleur que Linux/OpenGl , on sait juste que les drivers ne sont pas configurés pareille (et que Win/Ogl est un scandale :) ).

… Et donc tu peux aller regarder comment on débraye le vSync et refaire tes benchs :)