The n.e.w. Project

Répondre
Partager Rechercher
Bonjour,

Je viens vous présenter ici aujourd'hui le résultat de plusieurs mois de travail.
Mon projet porte le nom de code NEW "NeverEndingWorld" et est un projet de jeu 3D réseau PVP. Le but de ce jeu sera de coloniser des iles afin d'en récupérer les ressources et faire grossir votre village/faction/guilde.

Je suis seul et unique membre de mon équipe actuellement même si certaines personnes m'apportent parfois leur aide sur des sujets bien précis. Comme un compositeur qui a bien voulu m'aider sur la partie "son" du projet.
Vous pouvez d'ailleurs entendre ses compositions sur son soundcloud :
https://soundcloud.com/t-frost

Pourquoi je ne créé pas d'équipe ?

Cela me permets d'avancer bcp plus rapidement et d'avoir un maximum de réactivité. Je ne me disperse pas pour gérer l'équipe et créer des tonnes de documents de game design et de gestion de tâches.
Malgré tout, il me faudra dans un futur plus ou moins proche, de nouveaux collaborateurs sur ce projet si celui ci venait a grossir de plus en plus...

Ou en est le projet ?

J'ai déjà développé l'éditeur d'îles 3D qui est totalement automatisé de la forme initiale de l'ile, jusqu'à sa forme finale. Le système génère les fichiers de texture, le placement des arbres, des rochers, de l'herbe, leur forme, leur taille, etc.
Ce que je veux dire par là c'est qu'il me suffit de choisir quelques paramètres et de déclencher la création pour créer dans sa totalité une île. Ainsi ce que vous allez voir juste après n'a pas été touché une seconde par une main humaine...

L'intégralité des modèles que vous verrez ont été acheté et je possède les droits d'exploitations commerciales pour ces derniers.

Voilà ce que ca donne rapidement :

1368354830-screenshot-12052013-122038.png

1368354966-screenshot-12052013-122552.png

1368355055-screenshot-12052013-122700.png

1368355314-screenshot-12052013-122900.png

Le moteur de jeu est quasiment fini dans sa pré-version alpha. C'est a dire que d'ici la fin du mois, il sera téléchargeable pour que toute personne le souhaitant puisse le tester.
Il ne me reste a l'heure actuelle que quelques bugs de collisions et les fichiers de ressources a générer (je viens de finaliser mon gestionnaire de ressources)

C'est parce que j'arrive a cette pré-version prochainement que je me permets de venir présenter mon projet sur ce prestigieux forum. Dans un second temps et si vous le souhaitez je pourrais parler de ce qu'apportera la prochaine version et l'élément de gameplay révolutionnaire () qui y sera intégré : "les compétences"

Pour finir une petite vidéo (d'avance désolé de sa qualité médiocre)


Merci,
Urizen
C'est du perlin d'après une autre de ses vidéos, mais il génère d'abord un périmètre qui délimite la terre.
Je vais faire mon connard de service mais tu ne nous montre qu'un mec qui se ballade sur une île générée avec le même mesh d'arbre et de plante, c'est léger.

D'après ce que j'ai vu, TrueVision3D est un render engine pour DX9. Pas si mal vu qu'on peut dev en python, langage rapide.
Perso j'aurai opté pour Irrlicht ou Ogre qui sont un peu plus avancés.

Dernière modification par Neirdan ; 18/05/2013 à 13h46.
Bonjour et merci !

Je vais essayer de répondre et réagir aux différentes réponses

Je développe en .Net et avec le moteur graphique truevision3D qui je l'avoue commence a doucement vieillir mais je le maitrise correctement ce qui me permets de me focaliser sur le coeur du projet.

AU niveau de la génération de l'ile , j'ai intégré et testé nombreux algo : perlin, voronoi, diamond square, etc.. mais aucun ne m'a jamais donné le résultat que j'attendais (j'ai meme essayé de combiner les algos entre eux..) alors j'ai développé mon propre algo personnel pour avoir un maximum de réalisme.

Sinon le système choisi entre 30 meshs d'arbres, 6 meshs de plante, les rochers sont quasiment tous uniques. Cela ne reste pas qu'un simple terrain avec une pose aléatoire d'arbres a la noix ;-)

Le moteur montre surtout que je gère plusieurs milliers de meshs d'arbres et de rochers sans compter les effets d'ombres, de texturing, de ciel, l'effet d'eau (que je montre pas en effet dans cette video) le tout sur une configuration modeste (Athlon X3 450, 3go Ram, CG ATI Radeon HD 4650) et a quasiment 100FPS.

Je voulais montrer surtout que je pouvais générer des zones de jeu rapidement en grand nombre. désolé de ne pas montrer plus...

Maintenant oui j'ai oublié de parler du concept réel du projet...

Donc le monde dans lequel évoluera le joueur sera composé uniquement d'îles. Chaque joueur pourra intégrer un village (zone NON PVP) créé par les joueurs, ce village (sorte de guilde au final) devra être agrandit et amélioré par les joueurs aux même a la manière d'un Anno ou d'un Settlers.
Chaque batiment apportera un pnj spécifique et permettra d'avoir accès a de nouvelles possibilités ou évolutions pour le village.

Pour construire un batiment, il faudra des ressources et rapidement les ressources de l'ile ne seront plus suffisante. Il faudra alors aller chercher des ressources sur d'autres îles qui seront alors des zones PVP, y construire des batiments pour extraire les ressources, etc.

Le but du projet est d'offrir un environnement de jeu le maximum ouvert et avec un maximum de libertés autant dans le fond que dans la forme. Pour prendre un exemple, l'un des concepts est de donner le droit aux joueurs de concevoir leurs propres compétences de combats via un éditeur de compétences !

A+
Uri
Combien de triangles affichés?
Tu utilises des LOD statiques ou dynamiques?
Tu gères la pose d'arbre sur une pente pour que le mesh ne soit pas soit a moitié flottant soit à moitié dans le sol?
Différence de FPS avec/sans shader?
Tu bashes tes mesh ensemble?
Y'a possibilité de les modifier où ils sont statiques?
Si tu parles de collecter des ressources, il y a donc possibilité de collecter, donc faire une démo technique dans ce sens pourrait être pas mal
Pourquoi ne pas capper a 60FPS?

En fait le problème c'est que de ce que tu montres, sur un plan technique c'est bien, mais tout le monde ici n'est pas développeur et encore moins en 3D.

J'aime bien le concept de génération des compétences de combat, on le voit parfois pour les sorts mais plus rarement pour les "mouvements".
Quels seront les requis pour créer son propre village?
T'as pas peur du phénomène "petit chef" où chacun voudra son village?
capper à 60fps à une époque ou les nouveaux écran son 120Hz est un non sens, mais je suppose que la vsync est une option de son moteur, aprés il est logique de faire les benchmark sans.

Citation :
AU niveau de la génération de l'ile , j'ai intégré et testé nombreux algo : perlin, voronoi, diamond square, etc.. mais aucun ne m'a jamais donné le résultat que j'attendais (j'ai meme essayé de combiner les algos entre eux..) alors j'ai développé mon propre algo personnel pour avoir un maximum de réalisme.
"Allumeur"... Tu devrait faire un blog pour expliquer un peut ce que tu fait, un peut comme le dev d'overgrowth: http://blog.wolfire.com/

Tu montre tes îles, mais tu en est ou du réseau et du gameplay ?
Quelles sont tes compétences, ta formation ?
Tu bosse dessus depuis combien de temps ? tu pense en avoir pour combien de temps encore ?

Dernière modification par Titan. ; 19/05/2013 à 14h23.
+Bonjour,

Houlalala... On sent que vous avez régulièrement des projets qui viennent sur ce forum et qui avortent avec le temps et vous êtes devenus très demandeurs de précisions et de preuves...

Que de questions Je vais essayer de répondre dans la mesure de mes possibilités actuelles (je suis en weekend dans la famille et pas accès a mes données projets)

J'utilise un seul niveau de LOD statique sur les meshs d'arbres. Le processus de génération de la flore est précis et étudié, partant d'un point "habitable de l'ile" et générant une population croissante suivant les dénivelés sur les alentours. Je répète ce processus suivant différents paramètres afin d'atteindre un degré de flore sur l'ile.
J'ai essayé de controler certains paramètres afin de pouvoir éviter les bugs tels que les meshs qui sortent du sol ou autres. Je ne suis pas a l'abris de bugs bien sur, j'ai essayé de les éviter au maximum.

Les meshs sont (a part les meshs d'herbe) tous indépendants les uns des autres et peuvent avoir des caractéristiques propres a chacun (qte, dureté, vie, etc.).

Oui les écrans affichent du 120, mon moteur peut synchroniser a 60 et je pense que c'est déjà un beau rapport surtout sur une machine comme la mienne. Je ne bloque pas la synchro a 60 tout simplement car je suis en phase de développement et je souhaite connaitre l'impact FPS de chaque système que je mets en place.
De plus je vois pas pk bloquer un système a 60FPS si les gens ont des betes de courses affichant 400FPS..

Je commence un DevBlog doucement mais j'attends d'avoir 5/7 articles pour en parler... Cf. mon profil.

Niveau réseau, j'ai déjà eu l'occasion de travailler sur du réseau a plusieurs reprises et je SAIS que c'est LE point crucial du projet, LE point ou on peut pas se planter car le lag et le clipping sont l'ennemi du MMO (je suis joueur sur GW2 en RvR et je connais )

Formation ?
J'ai 35 ans, dev pro depuis 15 ans, et amateur depuis 25... Je suis actuellement responsable informatique et ma situation a très évolué ces dernieres années ou j'ai du faire un break malgré moi (maison, enfant"S", mariage, etc...).
Oui, Yame, je pense que c'est moi...

J'ai lancé ce projet et je suis parti de 0 il y a on va dire 1 an de ca grand max. C'est donc pas un projet qui commence et qui demande des congratulations, non... je viens ici aujourd'hui car je sais que la communauté JOL est l'une des plus pertinentes et qu'elle me fera avancer dans le bon sens. Alors surtout ne retenez pas vos critiques elles me feront avancer et j'espère me permettront de vous proposer un projet indé vraiment nouveau !

A+
Uri
Citation :
Publié par Urizen
je viens ici aujourd'hui car je sais que la communauté JOL est l'une des plus pertinentes et qu'elle me fera avancer dans le bon sens.
Repart.

"Les meshs sont (a part les meshs d'herbe) tous indépendants les uns des autres et peuvent avoir des caractéristiques propres a chacun (qte, dureté, vie, etc.)."
Là, tu parles des objets (arbre de type X à la position XYZ), moi je te parle des mesh en eux mêmes (vertices,indices,texture,toussa), est ce que tu fais des appels unitaire et les affiche un a un ou est-ce que tu les batch ensemble pour faire un seul draw call? Ca joue à mort sur les perfs, en fonction de combien tu affiches sur l'écran.
D'où ma question de savoir si chaque mesh est statique ou dynamique (si tu peux couper l'arbre ou non et que ca a un impact graphique sur le mesh).
Citation :
Publié par Neirdan
Repart.
Neirdan, Je ne comprends pas ton agressivité et ton aigreur... Je viens chercher ici des critiques a mon projet, peut être n'est il pas necessaire d'etre aussi violent et vindicatif.

La communauté JOL est a ton image ?
Car tu sembles parler en son nom puisque tu me demandes de partir.

Dans ce cas, je me suis fait une fausse idée de cette communauté, ou peut etre as tu une dent contre moi que je ne m'explique pas moi même...

Je le repete, ce projet est a un stade alpha, je suis seul et pas graphiste. Je ne peux avoir de meshs comme tu les nommes "dynamiques" car cela demande le travail de modeleurs spécialisés et je n'en est pas. Le rendu des meshs ne possède pas de système par batch (contrairement a l'herbe qui est calculée par groupe de 64 objets) car mon moteur ne permets pas de faire un calcul par batch et d'y ajouter les fonctionnalités que je souhaite (le rendu par batch oblige un objet en nombre de polygones limité et une non interaction niveau des collisions)

Je suis sur un projet de MO-RPG (j'ai enlevé un M hein....) et je ne cherche pas a faire un moteur pour concurrencer CoD ou BF... Je cherche a faire un moteur propre et performant pour un projet amateur et je compte jouer sur le gameplay et les idées.

Maintenant si vraiment je gêne n'hésitez pas a me le dire, je m'en irais.

A+
Uri
Citation :
Publié par Neirdan
est ce que tu fais des appels unitaire et les affiche un a un ou est-ce que tu les batch ensemble pour faire un seul draw call? Ca joue à mort sur les perfs, en fonction de combien tu affiches sur l'écran.
Neirdan, j'essaie de comprendre tes questions (désolé je ne suis pas du milieu de la création du jeu par conséquent je peux avoir du mal a comprendre certaines interrogations)

Donc chaque mesh est géré indépendamment l'un de l'autre, je peux en ajouter, supprimer sans soucis. Leur traitement est unitaire même si les meshs sont faits d'un seul et unique objet.

J'espère répondre a tes questions et apporter les réponses que tu souhaitais entendre

A+
Uri
Repart est une inside joke barienne/JOLienne, c'est juste que t'as une haute opinion de la communauté.

Si tu parles couramment anglais y'a un bon bouquin: http://www.realtimerendering.com/

Dans le cry engine par exemple, la végétation est batchée en fonction des plans.

Edit: tu parles de clipping GW toussa mais mes questions c'est par rapport au fait que tu tournes a FPS mais sans aucun monstre ni perso, du coup ca risque de prendre un énorme coup dans la gueul tes perfs

Dernière modification par Neirdan ; 20/05/2013 à 05h26.
Citation :
Publié par Urizen
Le rendu des meshs ne possède pas de système par batch (contrairement a l'herbe qui est calculée par groupe de 64 objets) car mon moteur ne permets pas de faire un calcul par batch et d'y ajouter les fonctionnalités que je souhaite (le rendu par batch oblige un objet en nombre de polygones limité et une non interaction niveau des collisions)
Tu calcule les colliders sur les meshs ? Le truc serait de batcher les modèles et de générer des colliders plus légers je pense.

Pour moi le fond est bon mais la présentation de ton projet donne pas envie, trop de chose, trop gros, trop comme on à l'habitude de voir. Après on demande tous à seulement voir le contraire
Mais par habitude je dirais de voir moins gros tu risque de t'essoufler à créer un truc aussi fat.

Edit : Pour résumer on est pas mal partisan de ce blog ici : http://conquerirlemonde.com/blog/ :d
Je vais t'expliquer le principe des draw calls et du batching de mesh, puisque tu ne peut pas faire un moteur performant sans même savoir que ça existe:

L'un des bottleneck majeur de la 3D temps réel est l'envoi des informations à la carte graphique pour l'affichage, chaque appel est un "draw call", tu va mettre dedans tes informations de rendu (vertex buffer object, textures, etc). je n'ai pas étudié le pourquoi, mais les draw call prennent tous un temps incompressible, même un draw call vide impact grandement les perfs.
C'est pour cette raison qu'une implémentation native de l'herbe est un gouffre à ressource, si chaque brin d'herbe génère un draw call. pour remédier à ce problème tu à le batching, c'est à dire que tu regroupe plusieurs objets pour les envoyer en un seul draw call; pour pouvoir fusionner plusieurs objet, ils ont besoin de partager le même shader et les mêmes textures, dans le cas de ton herbe et de tes arbres c'est parfait, si tu veux pousser l'optimisation plus loin, il faudra des shader générique (c'est généralement le cas de toute façon), et des atlas de textures, c'est a dire que tu colle plusieurs texture ensemble, ce qui t’amène à des problème de tilling, mais c'est encore une autre histoire .

La première chose que tu doit faire c'est afficher plus d'info sur ton HUD de debug, les FPS ne suffisent pas, il te faut en plus: les draw calls, le nombre de triangle rendu, et les temps de calcul CPU. Avec ça tu aura les outils pour savoir ce que tu fait.
Hello,

Tout d'abord mes excuses Neirdan, j'ai été surpris par ce private joke et par conséquent assez troublé !

Donc comme je l'ai dis, le moteur est limité sur son system interne de batching par rapport a la complexité de l'objet a traiter. Ce batching est donc tout a fait possible sur l'herbe mais pas sur des objets "arbres" plus complexes.

Pour plus de simplicité, je reprends une feature du moteur :
"Internal shader instancing allowing up to 52 meshes to be rendered per batch"

Ensuite je le repète, je n'ai pas de graphiste ou modeleur avec moi et par conséquent je dois faire avec les moyens du bord. Si par la suite, je peux développer plus en avant mon projet, je ne dis pas (pour le moteur de jeu uniquement) revoir le moteur graphique afin d'aller sur quelque chose de plus optimisé et récent.

Je suis bien conscient des optimisations dont vous me parlez mais je ne peux les appliquer (pour la plupart) a ce niveau du projet.

Le moteur actuel tourne sur un système de spooler qui update les meshs par groupes. Ce spooler traite les informations par priorité et possède un range timer précis afin que l'impact sur le FPS soit le minime possible.

Citation :
Tu calcule les colliders sur les meshs ? Le truc serait de batcher les modèles et de générer des colliders plus légers je pense.
Je suis entièrement d'accord et j'avoue que c'est obligatoire de toute facon. Ne serait ce que pour gérer des collisions propres et sans bavure. Oui les colliders seront gérées sur des meshs plus légers !

Citation :
Pour moi le fond est bon mais la présentation de ton projet donne pas envie, trop de chose, trop gros, trop comme on à l'habitude de voir. Après on demande tous à seulement voir le contraire
Mais par habitude je dirais de voir moins gros tu risque de t'essoufler à créer un truc aussi fat.

Edit : Pour résumer on est pas mal partisan de ce blog ici : http://conquerirlemonde.com/blog/ :d
Je connais très bien ce blog depuis de nombreuses années

Non bon sans rire, oui bien sur, je suis lucide. Je suis sur un projet complètement démesuré et incroyablement complexe (surtout niveau réseau) et je ne doute pas que je vais passer par des phases critiques. Mais j'avoue aussi que pour la première fois, je sens que je peux aller assez loin pour pouvoir montrer quelque chose de concret.

Avant la fin du mois je vous promets le moteur en téléchargement avec une île de test pour vous permettre de juger par vous même et mon système de compétence de combat personnalisable.

Merci en tout cas de vos réponses et critiques !

A+
Uri
Citation :
Publié par Neirdan
Tu devrais faire un vertical slice (http://en.wikipedia.org/wiki/Vertical_slice) de ton projet, ça serait cool pour qu'on sache où tu en es, où tu vas et ce que tu projettes de faire, que ce soit sur le plan dev ou sur le plan technique.
C'est une très bonne idée en effet, ca permettra de montrer les étapes du projet et de voir les avancées. J'ai 3 étapes essentielles pour moi avant de vraiment commencer le "coeur" du projet en terme de gameplay.

1. Lancer la démo "technique" on va dire même si il n'y a rien de technique au final mais juste pouvoir offrir le moteur en download afin de montrer que le moteur existe autrement que via des screenshots ou videos. Cette étape sera terminée d'ici une semaine.

2. Lancer la démo "réseau" afin de prouver que je peux gérer techniquement parlant plusieurs dizaines de joueurs sur une même île. C'est pour moi l'étape la plus périlleuse car la viabilité du projet tiendra en grande partie sur ma capacité en tant qu'amateur a pouvoir gérer un grand nombre de joueurs sans avoir une infrastructure pro.

3. Lancer la vrai version Alpha 1.0 qui gérera un gameplay de jeu en réseau sur le moteur 3d.

Une fois l'étape 3 lancée, je sais que j'aurais un truc concret dans les mains et que je pourrais voir vraiment le futur d'un bon oeil et d'un bon pied. C'est a ce moment là que je pourrais vraiment faire ce que tu demandes et ainsi commencer a fidéliser des gens sur le projet.

Aujourd'hui rien ne sert d'écrire tout ce que je souhaiterais mettre dans le projet sauf me discréditer et rendre mon projet tout sauf sérieux...

A+
Uri
Bonne chance pour ton projet.

J'en connais beaucoup qui aimeraient pouvoir essayer de créer leur propre projet si ils en avaient les compétences.

Sur ça , je vous envie toi et d'autres.
Bonsoir,

Ce soir, je suis enfin prêt à vous proposer de tester le moteur du jeu...
Ce n'est qu'un moteur en version alpha mais il possède déjà tout ce qu'il faut pour partir sur de bonnes bases et c'est pour moi le pas le plus important du projet, le pas ou je donne accès pour la première fois a mon travail.

Oui, vous allez trouver des bugs, le plus connu sera celui de l'herbe qui disparait d'un coup (j'y travaille) mais je voulais absolument vous proposer quelque chose a tester pour prouver le travail fourni.

Voici le lien de download :
http://www.sendspace.com/file/5ytge1

Dans le zip, un setup.exe a lancer qui installera "normalement" tout ce qu'il faut pour tester. Je ne suis pas sur un système embarqué comme unity ou autre, c'est de l'indé donc il risque d'y avoir des surprises. Je ne certifie pas la compatibilité en 64bits par exemple et aucune portabilité autre que Windows actuellement désolé.

En espérant que cela vous donne déjà envie d'en découvrir plus...

A+
Uri
Bonjour à vous !!

Je viens de télécharger et de tester votre démo.

( Mes informations machine : Core 2 Duo 3.2Ghz - 4go de Ram - CG : GTX 470 - Windows Seven 64B )

Après un "long" téléchargement ( 250mo !!! ), et l'installation, dès l'éxecution du client j'ai eu ce message d'erreur :

13052407093513261111225045.png

Mais qu'importe, puisque malgré tout, la démo s'est bien lancé en mode fenêtré.
Voici mes remarques :

Les Plus :

*/ Tout d'abord, bravo de nous faire parvenir une démo avec laquelle on puisse intéragir et tester de manière concrète tous vos travaux accomplis.
Bon nombre de projets diffusés sur le net se limitent à des images aguichantes, de vaines promesses et finissent à la longue par lasser ... Bel effort la dessus !

*/ Le rendu graphique est vraiment bluffant pour un projet "Indé" réalisé par une seule et même personne !! Certes, il y a quelques petits défauts de clipping, des textures un peu grossières et répétitives, mais le fait est là : C'est un travail soigné, sérieux avec une cohérence graphique tout à fait digne d'un projet pro. Bravo !

*/ C'est très fluide ( un peu plus de 110 Fps sur mon système ), et je n'ai rencontré aucun ralentissement dans la démo. Joli travail la dessus !!

*/ Il se dégage, déjà, une atmosphère particulière dés les premiers instants, j'ai eu rapidement l'envie d'en savoir plus et d'explorer les environs ...

*/ Le personnage est assez bien animé, quoiqu'un peu "raide" ... Néanmoins, sa réalisation est tout à fait correcte et acceptable !

*/ La caméra contrôlé par la souris est bien fichue mais ... voir les moins ...

Les Moins :

*/ J'ai eu des problèmes avec les touches de déplacements ... Je ne pouvais qu'avancer ou reculer ... Malgré tous mes efforts ! Bizarre ...

*/ ... des problèmes de caméra qui ne sauve pas la dernière position lorsque l'on fait bouger le personnage. C'est assez énervant je trouve.

*/ J'ai un petit bug graphique lorsque que je fais sauter le personnage ... Un artefact qui s'affichait en bas à droite de l'écran très rapidement.

*/ Allez, un petit effort pour une ambiance sonore pour une meilleure immersion et ...

*/ ... un peu plus de vie !!!

C'est du très bon travail !!! Soigné, propre et assez peu buggé pour une première diffusion.
Bravo pour votre travail et bon courage pour la poursuite de votre travail, que je sais, est une tâche ardue quand elle s'ajoute à la vie privée et professionnelle ...

Cordialement.

V.
Hello,

Vetea, merci d'abord pour tout ce retour qui me sera très utile !

Je suis déjà très heureux que la démo fonctionne sur un Seven 64Bits !! YES !! ^^

Pour le petit pop-up en début de lancement, oui j'ai réaliser un passage d'obfuscator sur ma DLL principale Eyengine.dll afin que certaines choses ne puissent pas être trop visibles car il existe un grand nombre de logiciels permettant de lire le "code" d'un projet réalisé en .net (vb/c#).
Cela n’empêche pas de tester effectivement.

Oui 250 Mo compressés, 355Mo je crois une fois décompressé.. Fou ca non a un âge ou on a besoin de 10Go pour le moindre jeu ;-) non je rigole, je rêve encore d'Elite Frontier qui faisait tenir des milliers de systèmes planétaires dans une disquette de 720Kb...

Merci vraiment pour les points positifs, je n'en suis qu'a une béta et je pense que plus tard j'aurai besoin d'un "designer" pour m'aider a concevoir l'ambiance graphique dans sa globalité et me montrer ce qu'il faut rajouter un peu partout...
Heureux que le système tourne pas trop mal sur ta machine !
Le mode fenêtré a été installé pour permettre de pouvoir profiter de la meilleure résolution pour chacun !

Revenons sur les moins

Les touches de déplacement je comprends pas... Première fois que je vois ce problème... Les touches Q et D n'ont pas permis de tourner ?? La touche A peut être (mode qwerty ??) -> a contrôler...

Caméra, ok noté... C'est vrai là j'avoue la caméra se reset derrière le personnage dès qu'on avance, une option a changer !

Le bug graphique du saut : je viens de relancer le moteur pour constater par moi même et après 50 sauts, je ne vois rien Ô__o
Des détails ?

Le son est en cours, la vie va arriver avec le réseau et le moteur de construction de compétences de combats !


Merci pour ce retour en espérant que d'autres suivent !

Cette première démo n'est que technique et montre une île générée par mon système de manière 100% automatique (je ne suis pas intervenu une seule seconde dans le processus de génération de cette île, je le répète mais c'est important pour la suite du projet !)

A+
Uri
Re - Bonsoir !!

Alors, après reboot de mon système, il s'avère que des problèmes que j'avais énoncé ne sont plus lieu d'être :

*/ Le problème des touches de déplacement : Tout fonctionne parfaitement, aucun lag de réaction, le personnage se déplace correctement.

*/ L'artefact lors du saut : je n'ai plus rien ... A vrai dire, je ne sais pas pourquoi j'ai eu ce bug, et je n'arrive pas à le reproduire à nouveau bref !! ^^

Voila, je voulais éclaircir ces points pour les futurs travaux et ne pas donner de "faux" problèmes.

Cordialement.

V.

EDIT : Ah oui Elite ... J'y jouais déjà sur mon CPC 6128 ! ^^
David Braben est un petit génie d'outre manche que l'on a vite oublié hélas ...
Merci Vetea de ce retour !

Oui, le CPC6128 a été mon premier ordi aussi en 1989 meme si Elite:Frontier était sur mon super 386sx16 ^^
J'ai toujours vénéré cet homme qui pour moi a été un "grand" génie !!

A+
Uri
[Modéré par Gectou4 : Propos injurieux et grossier ]
.
Edit 3: bloquer la caméra a 89° en hauteur et la même en bas à -89°, ca évite les caméras dans le vent.
Bouger la camera en même temps que le perso tourne (et inversement) ca ne mange pas de pain non plus.
Mettre la course par défaut et la marche avec shift, c'est plus naturel que l'inverse - a moins d'avoir un autorun.
La collision entre la caméra et les rochers n'est pas géniale, elle passe au travers.

Dernière modification par Gectou4 ; 25/05/2013 à 00h05.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés