Merci pour vos échanges les gars, je suis sûr que ça aidera notre ami wimf!
Je me permets de réagir rapidement à quelques unes de vos idées :

Je ne pensais pas rencontrer une telle levée de boucliers en évoquant cette idée - ndla: la 3d temps réel -

Ahah ne t'inquiète pas Nival. L'idée était très bonne et mérite toujours d'être considérée par wimf selon son ambition et ses capacités.
Simplement, il est parti sur un projet plus facile d'accès : Visionaire + précalculé, et l'idée marche tout à fait. S'il veut continuer dans cette voie, je l'en encourage, et j'attends de voir les nouvelles images pour lui donner un avis plus poussé. Ce sont les visuels qui seront décisifs.

Du peu que j'ai vu du jeu, ce pour quoi je défends le précalculé pour ce type de jeu est aussi ce qui lui manque. Pas vraiment de personnalité, des décors pas vraiment fouillés, pas de mise en scène, un personnage qui flotte en l'air et qui ne reflète pas une vraie personnalité. Ce n'est pas facile à faire et c'est difficile de juger dans l'état actuel des choses mais pour l'instant il ne supporte pas la comparaison avec Coral Cave

Essayez de ne pas décourager wimf ^o^'
Par ailleurs, comparer son jeu à The Coral Cave, ce n'est pas évident. Même si on est effectivement dans le point and click, et même si on affectionne tous The Coral Cave, les deux jeux n'ont rien à voir. C'est comme comparer Monkey Island avec Gabriel Knight: les deux sont des jeux d'aventure, mais n'ont pas le même esprit, pas le même style. Le jeu d'aventure est un milieu vaste et très varié.

je trouve qu'il est beaucoup plus difficile d'apporter de la personnalité à un modèle 3D qu'à une représentation en 2D.

C'est vrai ! La 3D semble plus facile à utiliser lorsqu'on ne sait pas dessiner, mais pour avoir un résultat convaincant il faut beaucoup de travail. C'est un peu un piège.
C'est pour cela que je proposais à wimf de regarder s'il peut utiliser le cell-shading. On a des jeux où ça marche plutôt bien sur les personnages, et on oublie un peu qu'il s'agit de 3D. Je n'avais plus d'exemple en tête, je n'ai repensé qu'à Runaway (bien que je n'aime pas trop le résultat, pour le coup...)

Essayez de ne pas décourager wimf ^o^'

Ce n'est pas le but. Je suis un peu dur mais je pense que des commentaires constructifs, même négatifs, apportent plus qu'un commentaire d'encouragement du genre: "Génial, un Point&Click. Continues comme ça, c'est super."
Cela peut faire plaisir à l'ego mais cela ne fait pas avancer énormément. Le pire, c'est pas de commentaire du tout.

Par ailleurs, comparer son jeu à The Coral Cave, ce n'est pas évident. Même si on est effectivement dans le point and click, et même si on affectionne tous The Coral Cave, les deux jeux n'ont rien à voir. C'est comme comparer Monkey Island avec Gabriel Knight: les deux sont des jeux d'aventure, mais n'ont pas le même esprit, pas le même style. Le jeu d'aventure est un milieu vaste et très varié.

Je ne compare pas The Coral Cave avec le jeu de wimf en terme de style et d'esprit mais par rapport à la base même du point&click: un character design original et inspiré, des décors fouillés et variés, une ambiance travaillée, ...
Peut-être que ce sera le cas pour le jeu de wimf et que le personnage n'est qu'un clone lambda pour tester le moteur. Mais alors il est pour nous impossible de juger en l'état actuel de la qualité du projet: sans character design fort, sans dialogue, un scénario à peine esquissé, sans décor fouillé, sans exemple d'énigmes, ...
Il semble que wimf veuille déjà passer en test pour une partie (1/10?) du jeu. Je comprends ainsi que le design est plus ou moins défini. Et là j'avoue que j'ai peur parce que cela me fait pas du tout envie.

Ce que je trouve très positif dans la démarche de wimf, c'est qu'il n'a pas vu trop grand. Pour une personne seule pour tout faire, c'est un très bon réflexe.

"Là où pour moi on a un overkill en utilisant de la 3D temps réel pour un Point&Click, c'est bien au niveau du Runtime"
"si le développeur maîtrise parfaitement les outils 3D pour le pathfinding, autant utiliser ses compétences existantes. Au niveau autodidacte, il existe un nombre relativement limité de personnes qui maîtrise ce genre de choses."
"Le plus gros problème des moteurs 3D, c'est la gestion des collisions et l'optimisation des performances."

En fait tu parles comme si utiliser un moteur 3D impliquait de le concevoir en grande partie. Là oui, la gestion des collision c'est un enfer, l'optimisation (et le "runtime") un travail d'équilibriste et d'optimisation ultra pointu, etc.

Sauf qu'Unity est déjà un moteur 3D qui est relativement bien optimisé (sans avoir à utiliser les outils d'optimisation supplémentaires qu'il propose dés lors qu'on est sur un projet "simple", en dehors oui des lightmap si on veut intégrer des éclairages complexes, mais ça c'est vraiment pas sorcier!), qu'il gère tout seul les collisions, et même au-delà la physique si on veut, avec une facilité de mise en œuvre déconcertante, et il intègre aussi un outils de gestion du pathfinding avec génération de "navmesh", donc là encore tout existe clé en main!

Mais de toute façon tu sembles perdre de vue le projet dont il s'agit: un point & click!
La gestion et l'optimisation poussée des temps d'exécutions est un enjeu crucial quand on considère typiquement des jeux d'action temps réel où le moteur va devoir gérer tout en même temps: un affichage temps réel d'environnements complexes surchargés d'effets (explosions,etc.), les commandes multiples mise à la disposition du joueur, l'IA des ennemis avec des pathfinding complexes mais aussi des "comportements", les collisions et éventuellement les mécaniques de physique qui y sont rattachés, la balistique et collision des tirs, les animations de tout ce beau monde par rapport aux actions en cours et aux interactions avec l'environnement... et tout cela avec un timing intransigeant!
Pour un point & click 95% de ces difficultés classiques (et pour lesquelles Unity est de toute façon taillé) passent à la trappe.

D'ailleurs dans un point & click les problématique de collision (qui ne sont donc de toute façon pas un problème dans Unity mais quand bien même) peuvent tout à fait être purement et simplement éliminées au profit du seul pathfinding: puisque le déplacement ne se fera que vers une zone déjà identifiée comme "explorable", le personnage ne devrait jamais recevoir une commande le faisant se déplacer en dehors des limites de la salle. Et si la méthode de pathfinding implémentée lui fait spontanément éviter d'éventuels obstacles, alors là encore les tests de collisions peuvent devenir inutile. D'ailleurs beaucoup de point & click simplifient encore la problématique en ne proposant comme zone cliquable pour les déplacements qu'une surface de forme convexe, si bien qu'il n'y a dés lors même plus besoin de pathfinding: rejoindre un point de cette surface depuis n'importe quel autre se fera toujours en ligne droite, et sera toujours libre d'obstacles. Si on place des obstacles au milieu, on peut toujours alors découper l'ensemble de la surface allouée aux déplacements en plusieurs zones de formes convexes et créer un tableau croisé pour gérer très simplement le pathfinding "à la main", du type "si je veux aller à un point de la zone 3 depuis la zone 1 je passe par le zone 2", on peut aussi sinon gérer un arbre de "node" (pas compliqué là encore tant que la zone de déplacement reste simple et que l'on n'est pas exigent sur l'optimisation des trajectoires, donc facile à implémenter pour un point & click, et bien plus complexe pour un jeu d'action une fois de plus), mais de toute façon ces problématiques sont dans un point & click parfaitement les mêmes que le moteur soit 2D ou 3D! La seule différence perçue par le développeur peut éventuellement venir de l'intégration d'une fonction spécifique, et plus ou moins facile d'accès, selon l'outil de développement utilisé. Et Unity intègre bien des outils de gestion des collisions et du pathfinding.

PS: mais en fait les point & click les plus classiques n'utilisaient pas le moindre pathfinding et lorsqu'il y avait un obstacle au milieu de la zone de déplacement souvent donc de forme convexe, il y avait gestion de collision simple et le personnage s'arrêtait alors tout simplement, au joueur de cliquer au bon endroit pour faire contourner l'obstacle, et cela n'entrainait aucun problème ou frustration.

Vous devriez en débattre dans un sujet spécifique, cela éviterait de tout mélanger. C'est intéressant, et cela peut justement intéresser d'autres personnes qui ne liront pas ces pages. C'est un sujet qui revient souvent et qui mérite sans doute de l'attention !

j'ai pendant vos discutions, changé la position de ma caméra et je suis en train de travailler sur les lumières et couleurs de ma scène (avec des couleurs plutôt que des textures). Effectivement ça donne déjà vachement mieux, et je suis , je pense, en phase d'arriver à un résultat qui est nettement mieux. Une fois peaufiné, je posterai la photo de la même room mais retravaillée et je serais alors très impatient d'avoir vos nouveaux avis :)

J'ai hâte de voir la scène retravaillée de wimf.
Le cadrage et l'éclairage sont essentiels pour créer une sensation de mystère.
Même avec des moyens techniques limités, un bon éclairage et un bon cadrage peuvent faire des merveilles !
En plus, c'est certainement la partie la plus amusante du travail.

Bonne chance !

Je répondrais simplement qu'il suffit de regarder quelques vidéos de test d'Atomium sur les jeux faits avec Unity pour entendre assez souvent le reproche que la gestion des collisions n'est pas bien gérée. Je l'ai entendu une fois dire sur un jeu fait avec Unity que celui-ci ne souffrait d'aucun gros problème de ce genre. Ce qui me laisse dire que certains développeurs y arrivent mieux que d'autres avec le même moteur mais qu'à la base il n'est pas parfaitement optimisé. Et ici on parle bien de projets relativement limités concernant ces problématiques.
Je ne dis pas qu'il n'y a pas de solutions mais qu'il ne faut jamais sous estimer les problèmes de pathfinding et de collisions. Il n'y a pas de solutions universelles qui marchent clés en main. Je mettrai ma main à couper que ces problèmes sont dans le top 5 des problèmes rencontrés par les développeurs.
Je suis d'accord qu'il est plus facile de trouver des solutions fonctionnelles pour un point and click mais que le problème est simple à la base, je trouve cela osé.

@The_IceHouse: en effet, il serait bon de ne pas squatter le thread de wimf. Désolé wimf pour les digressions.

Je suis plutôt d'accord avec ta vision d'Unity et des jeux en 3D, Conceptgame, car je trouve ça plus difficile d'accès qu'on a tendance à le dire. D'un autre côté Nival a raison de proposer cette technologie à wimf, qui peut très bien s'y essayer par curiosité. Si toi ou Nival souhaitez alimenter un débat dans un autre sujet, je le suivrai avec intérêt (et éventuellement participerai si je m'en sens capable).

Je rejoins totalement Atelier Sentô sur la remarque des cadrages et éclairages. Si wimf travaille avec 3dsmax (on dirait ?), il peut améliorer son éclairage facilement en utilisant des direct lights avec des ombres en raytrace qui passent à travers les fenêtres, ou à travers des stores, etc. Les scènes d'intérieur permettent généralement de créer de bonnes ambiances, en plaçant bien ses lampes selon les différentes sources de lumière, qu'elles soient naturelles ou pas. Je conseillerais de mettre un plafond (invisible à la caméra si besoin), qui stoppe la lumière du soleil extérieur, afin d'aider à créer les ambiances dans les maisons. C'est mieux d'avoir un éclairage intérieur géré dans une pièce close, plutôt que plafond ouvert comme c'est le cas dans les dernières images.
Pour éclairer l'extérieur des pièces, il est intéressant d'utiliser une skylight s'il n'utilise pas de moteur de rendu. A première vue c'est le cas, c'est le default renderer, mais 3dsmax vient avec Mental Ray, et ce serait donc dommage de ne pas s'en servir le cas échéant !

Vivement les nouveaux screenshots.

"il serait bon de ne pas squatter le thread de wimf. Désolé wimf pour les digressions."

Bah, le problème c'est que l'utilisation éventuelle de la 3d temps réelle dans un point & click que j'envisageais ici est bien du fait du cas particulier que représente le projet de Wimf, à savoir un point & click dont tous les éléments graphiques sont déjà modélisé en 3D, et dont tant la modélisation que le rendu utilisé restent parfaitement compatible avec les capacités actuels de rendus temps-réels (a fortiori considérant le peu d'exigence en terme de calculs annexes que requiert un point & click).

"Je répondrais simplement qu'il suffit de regarder quelques vidéos de test d'Atomium sur les jeux faits avec Unity pour entendre assez souvent le reproche que la gestion des collisions n'est pas bien gérée. Je l'ai entendu une fois dire sur un jeu fait avec Unity que celui-ci ne souffrait d'aucun gros problème de ce genre. Ce qui me laisse dire que certains développeurs y arrivent mieux que d'autres avec le même moteur mais qu'à la base il n'est pas parfaitement optimisé"

Déjà, je n'ai entendu At0mium s'en plaindre explicitement que pour un seul jeu, c'est Monochroma ; certes il prétend alors que ce n'est pas la première fois qu'il constate ce genre de problèmes avec un jeu sous Unity, au demeurant j'aimerai connaitre les autres jeux qu'il avait alors en tête, car quand on voit d'autres jeux utilisant massivement son moteur physique, comme p.ex. Broforce (certes utilisé en projection uniquement 2D ; mais cela devrait être le cas aussi pour Monochroma! Et ce sera le cas pour un point & click aux mécanismes standards) la réussite est évidente!

Tout le problème de l'utilisation du moteur physique d'Unity est je pense (et à ce que j'ai pu en tester) surtout de l'ordre du simple bon sens, comme pour tout moteur physique. Il faut naturellement éviter tout collider qui se base sur le maillage d'un objet complexe, en privilégiant des approximations les plus simples possibles. Il faut être très prudent aussi sur le nombre d'objets à considérer dans les collisions, ne pas hésiter à approximer en zappant clairement et simplement des objets "négligeables" dans une représentation qui reste crédible des interactions avec l'environnement, il faut aussi si des interactions avec des objets n'auront lieu de façon prévisible que dans certaines zones, désactiver et activer la prise en charge des différents collider en fonction de là où se situe l'action (surtout si l'on considère un environnement de grande taille avec de nombreux collider) ; enfin il faut régler la précision du moteur physique, en terme de résolution spatiale et temporelle, là encore en considérant la totalité (et la complexité) des collider pouvant être présents simultanément dans le moteur physique, mais aussi la bonne adéquation entre l'échelle à laquelle sont représentés les modèles 3D et la résolution spatiale définie du moteur physique, et puis considérant les vitesse max que peuvent avoir les objets en mouvements! (un écueil "classique": un objet très rapide qui traverse un objet très fin)

Cela étant dit, cela peut sembler "complexe" à appréhender, mais en fait non dans certaines situations, à commencer par les cas où:
- on ne s'intéresse qu'aux collisions et pas en plus à la physique des solides qui pourrait en découler(ce qui est le cas ici), a fortiori si les collider considérés sont en plus fixes (ce qui est le cas ici)
- on n'a que faire de considérer finement les limites précises des objets, et par exemple si des approximations par "boites englobantes" peuvent être bien suffisantes (ce qui est le cas ici)
- on ne s'intéresse aux collision que dans un espace 2D (ce qui est le cas ici)
Dés lors la gestion des collisions ne devrait pas poser de problème, et se résumera peu ou prou à s'assurer de la bonne adéquation entre résolution spatiale du moteur physique et échelle des modèles 3D ; ce qui ne devrait requérir aucun ajustement par rapport aux paramètres par défaut si les dimensions de ses modèles 3D suivent l'échelle des dimensions considérée par défaut par Unity (enfin, la base de l'intégration de modèles 3D dans un moteur quoi, même pour un moteur de rendu c'est pareil ).

"Si wimf travaille avec 3dsmax (on dirait ?), il peut améliorer son éclairage facilement en utilisant des direct lights avec des ombres en raytrace qui passent à travers les fenêtres, ou à travers des stores, etc."

Ah mon avis il tirera en plus énormément bénéfice d'une prise en charge d'un "éclairage indirect", ou au moins de "square lights", ou alors plutôt d'un rendu d'"occlusion" vis à vis de l’extérieur, pour avoir un bel éclairage diffus de sa pièce au travers des fenêtres. Il serait aussi intéressant de mettre un plafond qui permettra de jouer sur l'éclairage (en tant que déflecteur) dans une éventuelle solution d'éclairage indirecte, en ne l'affichant en revanche pas lors du rendu (soit en cochant "non rendable" ou je ne sais plus quoi du genre, soit simplement en utilisant un plan situé vers le bas: par défaut les polygones ne sont affichés lors du rendu que s'ils font face à la caméra, donc dés lors dirigés vers le bas ils n'apparaitront plus lorsque la caméra fera une prise de vue par au-dessus ; l'avantage étant que dans ce cas il suffira que la caméra repasse sous le plafond pour que celui-ci devienne automatiquement visible ;)).

Tes explications sur l'utilisation du moteur 3D sont très intéressantes mais je trouve exagéré de considérer que c'est simplement du bon sens. Ce n'est pas très sympa pour les développeurs de Monochroma, qui ne doivent pas en avoir suffisamment apparemment.
Blagues à part, je trouve qu'il serait risqué de laisser croire à wimf que tout sera plus simple s'il bascule sur Unity. Le moteur est séduisant, il est performant et possède déjà de nombreux plugins de qualité plus ou moins variables mais tout ne se fera pas seulement avec du bon sens.
Le choix de Unity ne me paraît pas du tout absurde puisqu'il ne fait que de la modélisation 3D mais il y aura forcément un moment où il pourrait lui paraître plus simple de revenir vers un outil connu ou qu'il y ait du découragement parce qu'il a tout revu depuis le début au niveau du moteur. Je lui conseillerai de bien poser à plat le travail à faire avant de se lancer car lorsqu'on bascule, il vaut mieux ne pas lâcher le morceau à la moindre difficulté. J'ai vu trop de projets indé tomber aux oubliettes parce que leur créateur s'était dispersé pendant le développement. C'est trop dommage et cela mérite réflexion.
D'un point de vue personnel, je réfléchis depuis un bon moment à faire un point and click en 3D avec Unity pour mon prochain jeu. Quand je liste tout ce que je dois faire pour arriver au résultat en comptant l'investissement d'apprentissage des points de Unity que je ne maîtrise pas en comparaison à un moteur 2D que je connais bien plus en détail, le choix n'est pas si évident que cela.

Ceci étant dit, on peut trouver des plugins et des exemples associés qui ne nécessite aucun scripting comme Adventure Creator pour Unity: http://www.adventurecreator.org/games/showcase

Tiens nous au courant de tes choix et de ton expérience, wimf.