Recoder KSP

[Hitman458]

Niveau optimisation, j'ai pas trop d'arguments. La seule fois que j'avais fait ramé le jeu, je l'avais un peu cherché aussi.

Ce qui me frappe par contre c'est qu'il manque des fonctionnalités importantes quand on prend le jeu out of the box sans aucun mod.
Vu qu'on est en alpha, on va pas gueuler pour ça, on va attendre en espérant du résultat car il est clair que le jeu est encore en construction.

Par contre avec une vision globale, si on regarde KSP + les Mods au final ça fait un jeux très complet. Il faudrait juste que les mods importants soient inclus d'office dans KSP, ce qui ne se fait pas pour des raisons de propriétés intellectuelles, de licence et de droit d'auteur sur le code. (là Squad a été trop lent et s'est fait doublé).

Après c'est comme pour Orbiter, il y a le jeu de base incomplet, et ce sont des mods qui complètent le jeu, par ex. Martin Schweiger ne s'embête pas à programmer un API pour du son, vu qu'un fan l'a fait de son coté avec OrbiterSound (Merci au grand Dansteph).

Ce qui fait un peu mal par contre, c'est que Orbiter est gratuit et vu qu'on paye KSP, on s'attend quand même a un autre level.

Par rapport au titre du topic, je pense que recoder KSP de notre coté n'aurait pas d’intérêt. Continuons de développer des mods pour rendre le jeu complet mais alors KSP mériterait p'tet moins le prix qu'il est payé.
Sinon et bin, on peut toujours repartir de zéro, et faire un jeu libre en créant une fondation/une organisation à but non lucratif et gérer le développement du jeu à la manière dont il est géré pour Debian ou Blender, mais il faut vraiment de la volonté pour en arriver là. Ce genre d’initiative se ferait que si les sources de KSP ou d'orbiter deviennent libre.

[Mahzel]

C'est marrant je m'attendais pas à tant d'avis en faveur d'un recodage de KSP.
Je vais peut-être me faire lyncher (nan, je m'y attends pas vraiment :p) mais :
-Je trouve personnellement qu'ils font du bon boulot (j'ai pas dit que vous aviez dit qu'ils faisaient de la m... hein) Tout le monde sait ce que c'est que le crowdfunding, on a tous payé en sachant que c'était du Work In Progress. Certains choix de dévelopement sont discutables (dédier un mec au developpement du SpacePort? Qui dure depuis des plombes >>), l'optimisation mémoire c'pas encore ça... OK. Mais on s'amuse tous sur ce jeu, malgré ses défauts. Oui ça manque de contenu, mais ça arrive tout doucement.

-Maintenant

vous avez raison que le problème c'est la compétence des développeurs. Ils faut voir que c'est leur premier vrai jeu donc voilà ...

Euh... WTF? Okay, deux trois anglais, dont c'est très certainement le boulot, on fait des mods supers. Je trouve que t'y vas un peu fort. Avis persos. On peux avoir beaucoup de choses à dire sur leurs choix, comme dit plus haut, mais en attendant, ils ont eu les "balls" d'attaquer un projet comme ça. Certains (beaucoup?) d'entre nous içi, bossent dans la prog' ou s'y connaissent pas mal. Tout ceux là savent que c'est pas de la magie. Qu'il y a des bugs (et qu'un bugs corrigé en amène dix autres), que tout marche pas forcément comme on l'espérait dès le début... Je reprend à titre l'optimisation, avec le patch précédent sensé améliorer les choses... Ben non. Ca arrive dans un logiciel en développement. Eux ils testent sans mods sur des bécanes de malade sans doute. Faut qu'ils revoient leur manière de tester? Fait avec leur nouveau type de "branch testing". On va voir ce que ça vaut.

-Les DLC. Je reviendrais pas longtemps dessus. On aime ou on aime pas. Faut gagner des sous pour vivre, même dans l'industrie du jeu vidéo. Pour mémoire, la gratuité des DLC date d'un billet qui date d'avant Steam, qui expliquait que les DLC serait gratuits. Ils sont revenus sur leur décision, mais cette "clause" n'apparaissant pas sur Steam, ceux qui ont achetés après cette release l'ont dans l'os. En anglais on appelle des gens comme ça des "Early backers" et en général ils ont le droit à une bande originale. Là ils ont des DLC gratuits. Je vois pas où est le soucis.

-Recoder KSP. Mettons qu'une boite géniale reprenne le concept (le seul jeu à peu près réaliste depuis Orbiter...) et ponde un truc mieux. Concevable, faisable, parce que c'est structuré par une hierarchie, avec des gars qui décident. Ce sera peut être plus rapide que SQUAD, peux être pas. C'est un peu quitte ou double.
Mettons que 4 bonhommes motivés s'y mettent ensembles. La aussi concevable et faisable. Plus rapide? Moui, si les gars ont pas de travail à côté, qu'ils font payer un prix équivalent. Si c'est trois gars qui font ça en rentrant du boulot (comme nous tous?), ça ira pas plus vite.
Maintenant, le codage communautaire. Je suis à 300% pour ce genre de système, mais la plupart du temps c'est un truc tué dans l'oeuf :
-Soit y'a pas de "commité directeur" et ça fait un détour de 3km pour avancer d'un mètre.
-Soit y'a un dit commité et on se retrouve avec l'inévitable liste de pleureuse parce que leur idée a pas été prise, parce que le lead programmer c'est un *censuré* et j'en passe.
*edit* Je suis d'accord, que des trucs "professionnels" (Linux, des forks d'Elite...) communautaire ça fonctionne. Mais ce sont des trucs réalisés par des passionés et/ou généralement des professionnels du milieu. Avec l'audience de KSP un tel projet va inévitablement recevoir sa cuillérée de "Kevins" qui veulent voir leur super rayon laser de la mort, de codeurs qui vont se prétendre comme tels (je ne suis pas contre le bonnes âmes, mais coder un jeu, c'est un investissement personnel. On peux pas taper

Code : Tout sélectionner

public int addInt(int a, int b)
{return a+b;}

et dire qu'on a participer. Désolé, c'est du déjà vu.
A titre de mauvais exemple : Trillek qui se veut une reprise d'0x10C de Notch. Bonne initiative, mais ça avance pas parce que personne est foutu de se mettre d'accord et tout le monde y va de sa petite idée....
Bref.

Je suis pour l'idée, mais quand je lis certains posts j'ai l'impression qu'il vous suffirait d'une casserole et d'une cuillère en bois pour faire mieux, et surtout, ça me "dégoute" un peu de voire que vous avez, finalement, pas beaucoup de considération pour le boulot de mecs qui font un truc qui au final, vous passione. Je suis peux être dans l'erreur, mais c'est un peu ce qui transpire de ce topic.

Voilà j'aime Squad et KSP, et j'attendrais de voir le produit fini avant de juger du besoin de faire un fork ou pas.

[Hitman458]

Ouais en fait c'est vrai, faut quand même souligner que travailler dans l'info c'est un peu ingrat parfois. On peut passer des jours et des nuits à faire un truc de fou qui marche, les non-initiés trouverons toujours à râler, à redire et à se plaindre sans jamais montrer de reconnaissance pour ce travail.

[Granolat]

Mahzel exprime parfaitement ma pensée.

[jeremy]

Je partage également les propos de Mahzel.

Jamais un jeu ne m'a autant émerveillé que KSP. Je suis donc tolérant, sachant que, il faut le rappeler, Squad n'est pas une société spécialisée dans le jeu vidéo. C'est une boite de communication qui a donné des moyens humains et financiers à l'un de ses salariés pour réaliser son jeu vidéo. Nous avons tous de la chance qu'un projet comme celui-là ai pu se concrétiser

[Excle]

Plutôt d'accord avec Mahzel. Hormis sur le dernier point. Je ne vois pas ce qu'il y a recoder.

Il y'a une règle très importante dans le projet informatique ( qui s'applique aussi dans le BTP d'ailleurs ), c'est le 80 - 20.

80% des fonctionnalités sont développées en 20 % du temps. Les 80% du temps restant sont mobilisés sur les 20% de finitions.
C'est comme pour une maison, on la voit très vite sortir du sol, tout à coup, on a l'impression que le chantier s'arrête.

Comme l'a très bien expliqué Hitman, Unity n'est pas seulement le moteur, c'est aussi l'outil avec lequel on doit s'adapter.
Lorsque l'on fait des jeux où l'on pousse le perfectionnisme, ou que ca sort un peu du cadre initial du moteur, on en rencontre très vite les limites.
L'architecture logiciel qu'ils ont bâtie au départ ne prévoyait pas l'utilisation d'objet de 500 parts.

Que faire ?

Recréer un moteur from scratch en C++ capable d'absorber se type de charge ?
- Ont-ils les ressources ?
- Ont-ils le savoir faire ?
- Ont-ils le temps ?

Si vous répondez Non à une de ses 3 questions, la meilleur solution, car la moins risquée, est de patcher à l'arrache votre projet et de bidouille le moteur pour le pousser un peu plus loin dans ses retranchements. Tant pis pour les 3% de pas content qui font des objets qui dépassent les limites du moteur. On travaille pour satisfaire le plus grand nombre et non tout le monde.
Ne perdez pas de vu le 80 - 20, car mauvaises nouvelles pour les fans, ces opérations "patch & bidouille", ce sont elles qui crament le plus de temps de développement et on est en plain dedans.

Alors j'entends ici et là : Oui mais regarder les moddeurs, ils font des trucs incroyables (ce qui est vrai).
Mais il ne faut pas mélanger les choux et les carottes. Les moddeurs n'interviennent que sur les éléments extérieurs du ksp quand Squad les définis.

Pour faire une analogie simple : C'est Squad qui coule les pièces de lego, Les moddeurs, eux, les assemblent.
Pour terminer sur les moddeurs, ils sont 300 à se mobiliser sur des fonctionnalités quand à Squad ils sont une demi-dizaine à bosser sur le coeur. Ca explique la différence des volumes de production.

Et je terminerai par rationaliser un dernier truc. J'ai un jeu qui marche bien et que j'ai déjà amorti, j'ai une équipe qui bosse bien. Pourquoi est ce que j'irai me casser ma marge pour accélérer mes devs ?
Le jeu sortira quand il sortira. Coté squad, rien ne presse, mieux vaut sortir un produit fini sans bug qui assurera gloire et réputation, qu'un truc sorti vite fait truffé de bug. Désolé les amis, le temps est un luxe qu'ils peuvent se permettre même si ca fait rager les fans.

[Hitman458]

Je doute que Unity soit si bridé que ça. Ce moteur briderait le regroupement logique de plusieurs parts en groupe ? Ce serait presque simplement désactiver la fonction "réactualiser physique" de quelques éléments !

J'y connais que dalle hein, mais vu ce que Unity a permis de faire dans KSP, le reste me semble surtout lié à une non-prévision qui bride des possibilités, à mesure que le jeu se complexifie...

Je viens d'avoir un illimitation à propos de ça. C'est pas Squad le problème, c'est juste que Unity n'est pas adapté à l'échelle de KSP.

Le moteur (Unity) utilise des nombres à virgule flottante, ce qui implique un problème : l'erreur est proportionnelle à la distance, plus la distance est grande plus l'erreur est grande. C'est à dire que si on mesure la distance séparant 2 vaisseaux en orbite proches de quelques km on mesurera leur distance avec une précision au mm par exemple. Mais si on mesure la distance de 2 vaisseaux en orbite sur 2 planètes différentes alors la précision sera plutôt au km. Et c'est pour ça que Unity déplace régulièrement la position du repérè du monde pour qu'il reste proche du vaisseau. (Je ne sais pas si c'est un mécanisme interne à Unity ou si c'est fait par Squad, mais en tout cas ce mécanisme est nécessaire).

Du coup ça implique autre chose, Comme le moteur physique ne sera pas précis sur les calculs pour les vaisseaux qui se trouves très très très très très loin, la physique est désactivée (là non plus je ne sais pas si c'est un mécanisme propre à Unity ou si c'est fait par Squad, mais... c'est nécessaire aussi).

Du coup, c'est une raison de plus qui ne permet pas d'avoir un mode multijoueur.

Si les jeux FPS avaient des map de plusieurs millions de km de large, on aurait le même problème.

Une rustine à Unity serait qu'il soit capable de gérer le moteur physique dans plusieurs repère de monde à la fois mais ça, je ne sais pas si il le fait. Du coup Squad se contente de précalculer les orbites pour les objets trop loin.

[Dragoon1010]

Il existe un mod multi en dev qui fonctionne pas mal, maintenant nous n'avons encore aucune info sur les objet éloigné par contre.