Merci à vous trois pour ces super retours, c'est très motivant !

Une ptite question qui me taraude : j'aime beaucoup les animations de balancement des méchas quand ils marchent, mais ces mouvement seront-ils transposés à la vue interne ? (le contraire serait dommage ... mais j'ai du mal à voir comment vous pourriez rendre cela en fait ^^)

C'est bel et bien le cas ! Le background de la vue intérieure dispose d'une petite animation qui retranscrit cet effet de balancement :).

Salut ! J'aimerais beaucoup présenter OTOT sur Indiemag ! Serais t-il possible pour toi de m'envoyer un presse kit à avorpal@indiemag.fr quand tu te sentiras prêt à partager ton projet ? Je vais suivre ça de près en tout cas !

Merci c'est super sympas ! Comme l'a fait remarqué Nival973, le projet est en effet relativement ambitieux, du coup j'ai peur que ce soit encore un peu trop tôt pour le moment. En tout cas, j'ai noté ta proposition afin d'y repenser quand le moment sera venu :).

Bonjour à tous.

Cela fait très longtemps que nous n’avons pas donné des nouvelles d’OTOT. Les derniers mois de travail ont été particulièrement difficiles et éprouvants. Nous avons rencontré des problèmes de design qui ont complètement renversé tout ce que nous avions en tête pour le jeu. Uubu et moi avons commencé à avoir des visions différentes pour le projet, nous avions du mal à trouver des solutions ce qui a rendu l’avancée très difficile.

Nous estimons que les résultats ne sont malheureusement pas à la hauteur des efforts fournis, ni à la hauteur de nos attentes. En conséquence, nous avons décidé de mettre fin au projet. Il s’agit d’un accord mutuel, Uubu et moi restons en bon termes. Lui comme moi, nous restons attachés à ce projet, et convaincus de son potentiel, en témoignent les nombreux retours positifs que nous avons eu concernant les éléments présentés.

Pour donner des explications plus précises, voici les principales erreurs ayant selon nous menées à l’échec du projet :

• Éparpillement : implémentation d’un grappin, animations procédurales, génération procédurale, éditeur de niveaux, pathfinding, IA... Nous avons passé beaucoup de temps sur des éléments qui n’étaient pas forcément prioritaires, ou du moins qui ne donnaient pas coeur au projet. Alors que nous aurions dû nous concentrer sur le gameplay uniquement, mettre en place une boucle de gameplay solide et efficace.
• Ambition : c’est une remarque qui revient souvent dans les post mortem, mais créer un jeu est une tâche extrêmement difficile, et qui demande beaucoup plus de temps que ce que l’on peut imaginer. Je pense que nous n’en avions pas pleinement conscience au début du projet. Il faut aussi se rappeler que nous n’étions pas à temps plein sur OTOT, loin de là. Pour ma part, je suis étudiant en alternance, j’ai donc mes études mais aussi un travail en entreprise à gérer ce qui laisse trop peu de temps pour se concentrer sur un projet supplémentaire.
• Game design : Uubu et moi ne sommes pas game designer et je pense que nous avons beaucoup appris à ce niveau. Nous avons beaucoup discuté du game design, et malheureusement nous avons mis du temps avant de voir des incohérences ou des incompatibilités entre différents aspects. Le point le plus critique se situait au niveau de la lisibilité : comment afficher des énormes mechas à l’écran alors que le joueur contrôle un petit personnage.
• Programmation : entre le moment où le projet a débuté et aujourd’hui, j’ai le sentiment d’avoir beaucoup appris en tant que développeur. À plusieurs reprises j’ai décidé de revoir la manière dont mon code fonctionnait pour l’améliorer. Je pense avoir gagné en rapidité, en connaissances mais aussi en qualité, la qualité étant selon moi essentielle pour conserver une efficacité optimale au fil du temps, alors que le projet devient de plus en plus complexe.
• Communication : je pense que c’était une bonne idée de lancer la communication publique autour du projet, mais nous n’avons pas réussi à le faire correctement et surtout régulièrement. Nous avions pourtant anticipé le problème en rédigeant quelques dizaines d’articles à présenter. Malheureusement, la tournure du projet à fait que beaucoup de choses n’étaient plus d’actualité.

Finalement, on pourrait considérer OTOT comme un projet de R&D. Nous avons beaucoup appris, sur pas mal d’aspects, et je reste persuadé que les échecs sont les meilleurs moyens d’apprendre. Même si c’est un peu difficile à digérer sur l’instant, cette expérience nous sera forcément bénéfique sur le long terme.

Pour ma part, je vais me lancer dans le développement d’un nouveau projet, que j’ai en tête depuis plusieurs années, et que j’aimerais désormais faire arriver à maturation. Evidemment, avec tout ce qui a été dit plus haut, la stratégie n’est plus la même. Je souhaite me concentrer purement sur le gameplay, et réaliser un prototype de manière autonome en réutilisant des sprites déjà existants. Ce n’est qu’une fois que j’aurais un prototype solide et intéressant que je commencerai à en parler publiquement et à collaborer avec d’autres personnes (graphiste notamment).

Nous vous remercions sincèrement pour les retours positifs que vous nous avez donnés, et sommes vraiment désolé de ne pas pouvoir porter ce projet à son terme. J’espère que vous comprendrez notre choix et nous espérons pouvoir un jour parvenir à le relancer.

Merci pour ton retour.

En fait je ne code plus du tout comme je codais il y a un an. Je fais de la programmation depuis cinq ans environ, pourtant j'ai vraiment l'impression d'avoir franchi un cap cette année. Grâce à OTOT, et à des projets professionnels. Contrairement aux projets effectués dans le cadre scolaire, il s'agit là de développements s'étant étalés sur plusieurs mois, et des projets plus complexes que ce que j'avais pu faire par le passé. C'est en travaillant longuement sur un même projet, et donc en côtoyant mon propre code sur une longue durée que je me suis rendu compte de tout ce qui n'allait pas, et du temps que je perdais au fur et à mesure que le projet avançait. Aujourd'hui j'organise mieux mon code, je sépare mieux les fonctionnalités, j'essaye de rendre mes scripts les plus indépendants possibles, les plus clairs et concis possibles, etc... D'ailleurs, j'ai rédigé des guidelines de programmation pour l'entreprise où je travaille, je compte en faire une version un peu plus concise que j'aimerais partager sur internet, dis-moi si ça t'intéresses ;).

Donc le fait de refactoriser son code, c'est essentiel sur le long terme, et c'est trop souvent négligé (car la vision court terme l'emporte souvent). Le problème, c'est que la vision que nous avions pour OTOT s'est cassée la figure. Pour simplifier, on peut donc dire que vu que le projet n'a pas été à son terme, prendre du temps pour faciliter l'avenir a été une "erreur", alors que si le projet avait été à son terme, ça aurait été la bonne chose à faire ahah.

Si tu veux tester un prototype ou que tu dois terminer un truc pour dans deux semaines, en effet ce n'est pas la peine de faire du code clean. Ce qui est sûr par contre, c'est que de toujours faire du code dégueulasse peut être très toxique pour un projet s'étalant sur plusieurs mois, et ce n'est pas un bon moyen de progresser. C'est surtout en refactorisant son code qu'on apprend à faire du code de meilleur qualité, et donc sur le long terme à produire directement un code de meilleure qualité qu'avant.

J'espère avoir répondu à ta question :).