Dans 13 jours se tiendra la sixième CitizenCon, le téléthon annuel de Star Citizen pendant lequel Chris et sa bande promettent monts et merveilles histoire de lever des fonds. A l'occasion RSI/CIG lancera l'alpha 3.3 du jeu.

Le petit soucis est que cette dernière a été sévèrement amputée niveau contenu vu qu'elle ne proposera pas Hurston et ses 4 lunes comme prévu. On nous explique que c'est parce qu'il faut d'abord finir le Object Container Streaming (OCS), une technologie clé du jeu. Derrière ce nom compliqué se cache un concept simple : celui de charger et décharger dynamiquement les objets du jeu (décors, personnages, véhicules...) selon votre position. C'est grâce à cela que GTA San Andreas par exemple arrive à tenir dans les 32 Mo de RAM de la PS2.

C'est évidemment une bonne idée pour un jeu massif comme Star Citizen mais généralement ce n'est pas le truc qu'on ajoute au milieu du développement. Ca fait partie des techno qu'on développe bien en amont... Histoire de ne pas perdre la face, RSI/CIG va coller l'OCS, Hurston et ses lunes dans une version intermédiaire appelée 3.3.5 qui sortira avant la 3.4 prévue avant la fin de l'année.

Lire la suite sur le site : J-13 avant la CitizenCon.

CBL a écrit :
il faut d'abord finir le Object Container Streaming (OCS), une technologie clé du jeu. Derrière ce nom compliqué se cache un concept simple : celui de charger et décharger dynamiquement les objets du jeu (décors, personnages, véhicules...) selon votre position. C'est grâce à cela que GTA San Andreas par exemple arrive à tenir dans les 32 Mo de RAM de la PS2.

C'est évidemment une bonne idée pour un jeu massif comme Star Citizen mais généralement ce n'est pas le truc qu'on ajoute au milieu du développement. Ca fait partie des techno qu'on développe bien en amont...

Effectivement, dit comme ça, ça fait un peu peur...

CBL a écrit :
C'est évidemment une bonne idée pour un jeu massif comme Star Citizen mais généralement ce n'est pas le truc qu'on ajoute au milieu du développement. Ca fait partie des techno qu'on développe bien en amont...

Cela fait effectivement depuis plusieurs années qu'ils y bossent dessus, environ au moins 2 ans.

Arcusan a écrit :
Cela fait effectivement depuis plusieurs années qu'ils y bossent dessus, environ au moins 2 ans.

Je fais des sites de ventes en ligne, et le premier truc qu'on code, c'est la page "contactez nous".
Et qu'on vienne pas me dire qu'il faut plutôt développer le panier et le catalogue en premier !!

Au final, je suis quand même heureux d'avoir backé ce jeu. Rien que pour voir la tristesse dans les yeux des fans. Un peu comme les supporters de foot quand leur équipe perde ^^

Jusqu'ici, tout va bien.

Arcusan a écrit :

CBL a écrit :
C'est évidemment une bonne idée pour un jeu massif comme Star Citizen mais généralement ce n'est pas le truc qu'on ajoute au milieu du développement. Ca fait partie des techno qu'on développe bien en amont...

Cela fait effectivement depuis plusieurs années qu'ils y bossent dessus, environ au moins 2 ans.

Heu c'est de l'ironie j'espère non ? Décharger un objet en fonction de la distance et de la position du joueur ça demande pas 2 ans de développement... Sur un moteur comme Unity ça se fait en quelques lignes de code avec des fonctions pré-mâchées... Alors ok, on parle d'un gros univers, c'est plus compliqué etc, mais c'est un peu (et ça doit être) la base de tout le reste.

Je me demande si ce n'est pas fourni par défaut dans le CryEngine.

Arcusan a écrit :
Cela fait effectivement depuis plusieurs années qu'ils y bossent dessus, environ au moins 2 ans.

Et peut-être que ça aurait dû être une priorité avant de bosser sur des machins comme FOIP ou l'interface graphique...

CBL a écrit :
Je me demande si ce n'est pas fourni par défaut dans le CryEngine.

Bah je pense quand même oui... Après ils doivent certainement mettre les mains dans le cambouis pour l'adapter à leurs besoins, j'imagine que le netcode vient s'en mêler un minimum aussi...

Semifer a écrit :

CBL a écrit :
Je me demande si ce n'est pas fourni par défaut dans le CryEngine.

Bah je pense quand même oui... Après ils doivent certainement mettre les mains dans le cambouis pour l'adapter à leurs besoins, j'imagine que le netcode vient s'en mêler un minimum aussi...

Ben c'est surtout qu'ils savaient de base que c'était pas fait pour faire un truc aussi énorme, et qu'il y aurait un taf de ouf pour rendre tt ça cool. M'enfin, bon courage aux développeurs quand même. Mais ce projet énorme donne tellement l'impression de tenir debout d'un rien, que si ça chute, ça va être fou.

Dans la discussion précédente sur le sujet, j'avais concédé que le devs s'etait enfin mis sur des rails ces deux dernieres années (aprés 5 ans de grand n'importe quoi) sortant des updates de facon plus réguliere et méthodique.

Mais de là a respecter leur roadmap ...

Dailleurs, Arcusan, un des rares defenseurs de Star citizen raisonné et calme, tu disais dans cette news précédente :

Si ils respectent la livraison de la majorité du contenu de la road map prévu pour la fin d'année avec notamment les 2 planètes et ses lunes et surtout les optimisations cité dans la news, ce qui semble apriori bien partie pour. Alors ça sera le signe que pour moi qu'ils sont définitivement sur la bonne voie."

Du coup, opinion actuelle ?

Je suis déçu par les commentaires dans cette news jusqu'à maintenant. D'habitude il y a toujours 1 ou 2 fans hardcores qui nous sortent des propos à mourir de rire pour défendre SC sur n'importe quel sujet en dépit du bon sens élémentaire.

CBL a écrit :
Je me demande si ce n'est pas fourni par défaut dans le CryEngine.

Arcusan a écrit :
Cela fait effectivement depuis plusieurs années qu'ils y bossent dessus, environ au moins 2 ans.

Et peut-être que ça aurait dû être une priorité avant de bosser sur des machins comme FOIP ou l'interface graphique...

Je pense que cela a toujours été une priorité, mais en dehors du fait que tous ce qui touche au netcode est ce il y a de plus long et de plus fastidieux à mettre en place dans un MMO, c'est surtout une question de ressource humaine.
Ils ont des armées d'artistes mais leurs ingés réseaux se comptent sur les doigts d'une main (je crois qu'ils sont que 3) et c'est apparemment ce qu'il y a de plus rare à recruter.
Il y avait eu un débat intéressant sur CPC à propos de la spécificité de l'OSC dans SC, page 40 à 41.
http://forum.canardpc.com/threads/118825-Star-Citizen-On-a-la-liste-d%C3%A9finitive-de-notre-Bingo-annuel-de-la-CitizenCon-!?p=11841606&viewfull=1#post11841606

kakek a écrit :

Du coup, opinion actuelle ?

Que c'est encore possible si ils sortent leurs patchs intermédiaire en novembre, vu que c'est pas la prod des planètes/lunes en elle même qui pose le soucis. Cela se jouera avec la stabilité de l'OCS/bind culling au moment du live de la 3.3.5, si cela se révèle complétement pété il y aura peu de chance pour que le reste suive derrière
Après la promesse de cet année tenait avant tout sur les livraisons à période fixe avec le contenu disponible à ce moment la.
J'attends d'être à la fin de l'année quand ils auront sortie la 3.4 pour juger si dans l'ensemble se fut une stratégie pertinente ou non.

Préambule : les Wing Commander font partie de mes plus tendres souvenirs de jeux vidéos et j'ai très envie de jouer à Squadron 42 (parce que MMO caca)

Je ne sais pas comment on fait des jeux vidéos mais sérieusement, lire que pour le MMO le plus ambitieux de l'Histoire du Jeu Vidéo y aurait que 3 guss sur le code réseau, ça me pique les yeux. Sans rire ? Sur ce projet ultra controversé à cause de son financement et de son développement ? 3 ? Ou alors ça doit pas servir à ce que je crois, un ingénieur réseau. Et insérer une technologie qui semblerait être angulaire aussi tard dans l'avancement officiel du projet, c'est pas un complet foutage de gueule ? Ce projet est dingue et je suis fasciné de voir qu'il y a encore des gens pour le soutenir.

CBL a écrit :
Je me demande si ce n'est pas fourni par défaut dans le CryEngine.

Arcusan a écrit :
Cela fait effectivement depuis plusieurs années qu'ils y bossent dessus, environ au moins 2 ans.

Et peut-être que ça aurait dû être une priorité avant de bosser sur des machins comme FOIP ou l'interface graphique...

Non ce n'est pas fourni dans le cryEngine étant donné que le cryEngine est un moteur de FPS à la base. La gestion OCS qui est en dev depuis 2 ans c'est aussi une refonte total du moteur pour la gestion multi-thread, la suppression du LUA et sont remplacement par du code pur C++ qui lui sera compatible multi-thread et permettra donc à l'OCS de charger en tache de fond les objets, textures etc.....

PS : dans le cryengine d'origine la map est loader en mémoire, mais les dimensions de SC ne le permettent plus.

Tout cela confirme que le choix du CryEngine était absurde et qu'ils auraient du partir dès le départ sur un moteur maison...

Pour le Lua, je doute qu'ils l'aient utilisé pour les éléments lourds ou alors ils sont vraiment à la masse. En général avec un moteur type CryEngine, tu utilises le language natif pour les bases du jeu, le réseau et les calculs compliqués et le langage de script pour les éléments où tu as besoin d'itérer rapidement comme l'interface ou le gameplay.

CBL a écrit :
Tout cela confirme que le choix du CryEngine était absurde et qu'ils auraient du partir dès le départ sur un moteur maison...

Pour le Lua, je doute qu'ils l'aient utilisé pour les éléments lourds ou alors ils sont vraiment à la masse. En général avec un moteur type CryEngine, tu utilises le language natif pour les bases du jeu, le réseau et les calculs compliqués et le langage de script pour les éléments où tu as besoin d'itérer rapidement comme l'interface ou le gameplay.

C'est évidement sur l'interface principalement que le LUA est utilisé dans le cryengine mais aussi sur la partie outil de dev d'origine car c'est du LUA qui drive le système de graph et aussi sur toute la partie scripting tout simplement comme dans beaucoup de moteur de jeu.

Non ils ont bien fait de partir d'un moteur existant pour avoir un support et ses services associés. Les deux premières années ont été faites avec le support direct des ingénieurs de CRYTEK puis suite à la fermeture de certain studio (CRYTEK) l'embauche d'une partie des devs.

Partir de zéro aurait été stupide car il aurait été alors nécessaire de réaliser le moteur plus les outils de dev et les plugins (vers maya etc...).

PS : CIG est constitué d'ingénieur réseau de codeur etc.. venant de CRYTEK et d'autres studios ayant participé à des projets utilisant le CryEngine donc je pense qu'ils sont les mieux placés pour savoir comment il faut changer le moteur pour arriver à leur fin. Faudrait arrêter de penser savoir mieux que des gens qui ont une réel expérience sur le sujet.

Ca fait juste 15 ans que je développe avec différents moteurs :)

Et je maintiens pour le choix du CryEngine.
En six ans de dev, ils bossent encore sur des fonctionnalités de base pour un MMO et les performances sont à la rue. Dans le même laps de temps, Hello Games et Frontier ont commencé, fini et patché leurs jeux puis sorti tout plein d'extensions. Le tout avec des moteurs maison.

Ils ont choisi un moteur prévu principalement pour des combats sur la terre ferme et de leur propre aveu l'ont modifié de fond en comble.
CryEngine est fameux pour de nombreuses choses. Le support n'est pas l'une d'entre elles. C'est en partie la raison pour laquelle le moteur n'a jamais décollé. Les moteurs modernes n'utilisent plus de plugins d'export custom pour Maya et Max car ils savent que c'est la galère à maintenir. Unreal importe des .fbx et Unity peut même importer des .mb. Le gros plus de CryEngine c'est son éditeur de cartes WYSIWYG et ils ne doivent probablement s'en servir vu la nature du jeu et l'aspect procédural des planètes...

C'est assez symptomatique je trouve par rapport à tout le reste, que de taper autant "à côté" ne serait-ce que dans le choix du moteur...

Avec tout le fric de soulevé, en effet développer un moteur maison (ce qui est habituellement déconseillé nous sommes bien d'accords) dans ce cas aurait été au final bien plus productif. Alors que là pour le coup, la contre-production est d'une sévérité...

Bon après, clairement je reste admiratif, je trouve ça hallucinant à bien des égards et sans précédent. Je n'ai jamais testé le bousin, je ne me suis contenté que des vidéos. Il parait que c'est pété de partout mais j'ai quand même pu zieuter des sessions de jeu impressionnantes. Le projet est gigantesque et j'aimerais concéder une chose, c'est que nous en rêvions tous étant gosse. Justement avant quand je jouais à des shoots ou des simus j'éprouvais cette "limite" de ne pouvoir aller dans les vaisseaux, m'y balader, aller sur les planètes en temps réel, etc...

En terme de plaisir de jeu le but est de permettre finalement à chacun (selon son approche différente du jeu) d'y trouver son compte. Après je n'entre pas dans la polémique franchement et sincèrement ça ne m'intéresse pas parce que pardon mais la plupart du temps c'est parler sans savoir et je déteste parler pour ne rien dire. Le minimum c'est quand même de s'adresser à des experts et si possible qui bossent directement sur le sujet...

C'est sûr que pour des petits développeurs peut être plus modestes mais plus réalistes dans leur développement, voir ça : c'est frustrant. Mais ce n'est pas mauvais. Combien de joueurs risquent de se retrouver fortement déçus par de telles démarches (aussi démesurées) et se tourneront finalement vers de la création indé peut être plus artisanale mais peut être au plaisir plus immédiat (?)

En attendant c'est surtout Squadron42 qui m'intéresse...
Mais je ne crois qu'en ce que je vois donc en attendant (et vu la gueule du truc) faut pas compter sur mes pépètes.

CBL a écrit :
Ca fait juste 15 ans que je développe avec différents moteurs :)

Et je maintiens pour le choix du CryEngine.
En six ans de dev, ils bossent encore sur des fonctionnalités de base pour un MMO et les performances sont à la rue. Dans le même laps de temps, Hello Games et Frontier ont commencé, fini et patché leurs jeux puis sorti tout plein d'extensions. Le tout avec des moteurs maison.

Ils ont choisi un moteur prévu principalement pour des combats sur la terre ferme et de leur propre aveu l'ont modifié de fond en comble.
CryEngine est fameux pour de nombreuses choses. Le support n'est pas l'une d'entre elles. C'est en partie la raison pour laquelle le moteur n'a jamais décollé. Les moteurs modernes n'utilisent plus de plugins d'export custom pour Maya et Max car ils savent que c'est la galère à maintenir. Unreal importe des .fbx et Unity peut même importer des .mb. Le gros plus de CryEngine c'est son éditeur de cartes WYSIWYG et ils ne doivent probablement s'en servir vu la nature du jeu et l'aspect procédural des planètes...

Le moteur à été choisi pour son rendu et la qualité visuel. Le fait que ce soit un moteur FPS impliquait nécessairement de changer beaucoup de chose que ce soit d'un point de vue réseau (netcode), dimension des cartes limités, passage en 64bits, remplacement de l'octree etc.... Tout ça a été refait entièrement donc d'une certaine façon c'est comme si ils étaient parti de 0 sauf que du coup ils avaient le soutien des studios de Crytek puis d'Amazon et donc de bénéficier des services de support dev Amazon et de la documentation. Ils ont pu ainsi aussi déléguer des choses à Amazon, Turbulent, Faceware etc...

La comparaison avec NMS et ED, franchement ce n'est pas du tout les mêmes objectifs qui sont visés. Pour ce qui est des plugins custom il y en a toujours, et ils font aussi beaucoup d'autres plugins pour gagner du temps par exemple dans la fabrication des ships, le re-calibrage d'animation etc...

Je suis désolé mais non "c'est pas comme". Quand tu tentes de faire entrer des problématiques techniques dans un moteur déjà existant... (même si se sont des features qui n'existent pas), tu as toute la base du moteur existant. Tu vas avoir des contraintes sur la manière dont est gérée ta mémoire ou ton rendu par exemple. Si bien que tu es obligé de composer avec l'existant quand tu commences à entrer dans l'optimisation. Avec un moteur maison, tu structures ton moteur autour de ta problématique ce qui t'impose vachement moins de contraintes que d'avoir une base qui va fonctionner d'une manière bien définie.

Concernant ED et NMS, on s'en fout que ça soit pas les mêmes objectifs... ce sont des jeux relativement monstrueux et procéduraux et ils ont pondu leur moteur de zéro. C'est tout ce que CBL cherchait à dire.

__MaX__ a écrit :
Je suis désolé mais non "c'est pas comme". Quand tu tentes de faire entrer des problématiques techniques dans un moteur déjà existant... (même si se sont des features qui n'existent pas), tu as toute la base du moteur existant. Tu vas avoir des contraintes sur la manière dont est gérée ta mémoire ou ton rendu par exemple. Si bien que tu es obligé de composer avec l'existant quand tu commences à entrer dans l'optimisation. Avec un moteur maison, tu structures ton moteur autour de ta problématique ce qui t'impose vachement moins de contraintes que d'avoir une base qui va fonctionner d'une manière bien définie.

Concernant ED et NMS, on s'en fout que ça soit pas les mêmes objectifs... ce sont des jeux relativement monstrueux et procéduraux et ils ont pondu leur moteur de zéro. C'est tout ce que CBL cherchait à dire.

Justement ils ont viré progressivement les contraintes de l'ancien moteur afin de pouvoir faire les choses comme ils ont besoin. La base du moteur a été changée ils ont fait le passage en 64bits et le zbuffer en 32bits, virer le octree etc..

Manifestement nous ne voyons pas les choses sous le même angle donc la discussion s’arrêtera la pour moi. Nous verrons bien s'ils ont fait les bons choix ou pas.