Ils ont de l'or entre les mains, le choix de réutiliser la même map pourrait être judicieux pour se donner le temps d'y aller à fond sur le reste. S'ils ont vraiment compris tous ce qui faisait défaut au précèdent et bossé dessus pour régler ces tares et faire du jeu ce que botw aurait pu être avec le recul ( on voit que c'est déjà le cas avec les armes cassables, ça donne de l'espoir pour le reste)

Ce serait assez fou s'ils parviennent a recréer le sentiment de découverte qu'on a eu au début du premier

Ce qui peut marcher aussi c'est le sentiment de redécouverte, s'il y a un timeskip par exemple ils peuvent se permettre pas mal de choses et si c'est réussi on aurait le même sentiment qu'en revenant dans un lieu familier qu'on a quitté il y a des années (enfin ça marche pas trop sur ceux qui ont pas aimé BOTW)

Je pars plutôt confiant aussi mais je préfère ne pas me mouiller avant d'y avoir jouer. De toute façon, j'ai lancé le premier complètement à l'arrache et j'y suis allé comme ça donc il n'y a pas de raison que je ne fasse pas pareil avec celui-ci.

Je ne pense pas qu'il y aura le même sentiment de découverte parce que ce n'est plus nouveau mais il peut y avoir un autre plaisir plaisir qui est celui de redécouvrir des lieux qu'on connaît déjà mais avec des changements notables depuis notre dernier passage. Je pense que ça va se focaliser là-dessus au sol et que tout ce qui est au ciel sera la découverte. Il y a d'ailleurs l'air d'avoir un grand nombre d'îles flottantes et on ne réalise pas bien leurs tailles réelles à cause de l'axe dans lequel on les aperçoit depuis le sol.

Ce serait dommage que le type qui n'a jamais joué a botw ait la meilleure expérience de jeu sur la map de botw en jouant à totk par rapport a celui qui avait joué a botw mais dont le plaisir de découverte est gâché.

Questions aux collègues dev : comment vous vous y prendriez pour Rétrospective ?
Techniquement pour remonter le temps de l'objet il faut avoir sauvegardé son trajet, sauf que niveau conso de ressources c'est infâme vu le nombre d'objets dont on doit pouvoir remonter le temps.
Une solution serait aussi simplement de juste avoir en mémoire de quoi pouvoir recalculer en temps réel l'ancien trajet pour sauvegarder moins de choses (et consommer moins de RAM).

A chaud, comme ça, vous faites comment ?

Y aura pas de demi-mesure avec ce jeu, ou ce sera réussi, ou ce sera un raté, tout dépendra encore une fois du contenu. Et la manière dont ils nous font utiliser les pouvoirs aussi.

Le 31 mars 2023 à 11:51:07 :
Questions aux collègues dev : comment vous vous y prendriez pour Rétrospective ?
Techniquement pour remonter le temps de l'objet il faut avoir sauvegardé son trajet, sauf que niveau conso de ressources c'est infâme vu le nombre d'objets dont on doit pouvoir remonter le temps.
Une solution serait aussi simplement de juste avoir en mémoire de quoi pouvoir recalculer en temps réel l'ancien trajet pour sauvegarder moins de choses (et consommer moins de RAM).

A chaud, comme ça, vous faites comment ?

On a trop peu d'info sur Rétrospective, on sait pas vraiment dans quelle situation on peut vraiment l'utiliser. Si je jette une arme, et que j'utilise le pouvoir sur cette arme, est-ce qu'elle revient vers moi ? Et si ça marche, c'est quoi la limite ? Si je jette dix armes, et-ce que le jeu me permettra de remonter le temps à ces dix armes l'une après l'autre ? Ça me paraît invraisemblable honnêtement...

Questions aux collègues dev : comment vous vous y prendriez pour Rétrospective ?
Techniquement pour remonter le temps de l'objet il faut avoir sauvegardé son trajet, sauf que niveau conso de ressources c'est infâme vu le nombre d'objets dont on doit pouvoir remonter le temps.
Une solution serait aussi simplement de juste avoir en mémoire de quoi pouvoir recalculer en temps réel l'ancien trajet pour sauvegarder moins de choses (et consommer moins de RAM).

A chaud, comme ça, vous faites comment ?

Comme dis au-dessus tout dépend des limites, est-ce que c'est pour tout les objets physiques ou comme dans la vidéo que pour certains objets qui ont un mouvement pré calculé ? Si c'est le deuxième cas, un simple "spline" (en gros la trajectoire de l'objet allant d'un point A à un point B) qui fait un mouvement de base A vers B et qu'on peut inverser pour aller de B à A, dans ce cas c'est pas très gourmand.

Après si c'est pour chaque objet physique, j'imagine que le moteur sauvegarde le déplacement mais en plusieurs fois (pas toute la trajectoire mais par exemple la position de l'objet à chaque secondes jusqu'à ce qu'il soit à l'arrêt) et j'imagine qu'il y a aussi une histoire de distance, si l'objet dépasse une certaine distance autour du joueur alors les calculs sont supprimés, je pense que grossièrement c'est comme ça que ça se fait.

Le 31 mars 2023 à 11:51:07 :
Questions aux collègues dev : comment vous vous y prendriez pour Rétrospective ?
Techniquement pour remonter le temps de l'objet il faut avoir sauvegardé son trajet, sauf que niveau conso de ressources c'est infâme vu le nombre d'objets dont on doit pouvoir remonter le temps.
Une solution serait aussi simplement de juste avoir en mémoire de quoi pouvoir recalculer en temps réel l'ancien trajet pour sauvegarder moins de choses (et consommer moins de RAM).

A chaud, comme ça, vous faites comment ?

je ne suis pas dev mais je me demande si c'est aps la même logique que la conservation de la durabilité et de la présence des armes dans l'open world.

corrigez moi si je me trompe mais si je pose une arme presque detruite à un endroit A, que je parte ailleurs pendant un temps t (avec ou pas des temps de chargement) à mon retour l'arme sera toujours là avec le même niveau de durabilité (jusqu'a la prochaine lune de sang).
pour retrospective, ça sera similaire je pense, le calcul de trajectoire(et donc de la trajectoire inverse) n'est pas si infame que ça je pense, surtout que c'est sur un instant assez court.

Franchement je suis hyper étonné que la Switch arrive à géré tout ça.

Le 31 mars 2023 à 12:24:55 :
Franchement je suis hyper étonné que la Switch arrive à géré tout ça.

ça sera comme pour BoTW je pense niveau conso de ressource, si jamais le calcul des objets persistant devient trop élevé et que ça s'approche trop de la limite, le jeu lancera une lune de sang "d'urgence" (quelque soit le moment de la journée) pour eviter une surcharge.

Ahi, Eiki et Henri toujours fidèles au poste

Le 31 mars 2023 à 11:51:07 :
Questions aux collègues dev : comment vous vous y prendriez pour Rétrospective ?
Techniquement pour remonter le temps de l'objet il faut avoir sauvegardé son trajet, sauf que niveau conso de ressources c'est infâme vu le nombre d'objets dont on doit pouvoir remonter le temps.
Une solution serait aussi simplement de juste avoir en mémoire de quoi pouvoir recalculer en temps réel l'ancien trajet pour sauvegarder moins de choses (et consommer moins de RAM).

A chaud, comme ça, vous faites comment ?

Je pense que ça va concerner que quelques objets bien précis pour lesquelles les trajectoires sont définies d'avance.
Sinon si je devais faire une implémentation moi-même ce serait une approche similaire au VDD:
-foutre un tag "retrospectivable" aux objets déplaçables par le joueur susceptibles de l'être. Si ce sont de gros objets harcodés comme la pierre qui est remontée on a déjà la trajectoire. Sinon,
-toutes les x ms, enregistrer la rotation (quaternion) et la position (vecteur) de l'objet et faire une interpolation avec spline cubique.
-Ne faire ça que si l'objet est dans un certain périmètre pour éviter de stocker des infos pour rien.

Coût en mémoire: 4 floats pour le quaternion, 3 floats pour le vecteur soit 7 floats pour un enregistrement. Faut ajouter à ça les autres floats pour les coefficients pour les coefficients d'interpolation de la spline cubique (ça dépend si t'utilises Hermite, CatmullRom ou autre) soit environ 10 floats de chacun 4 bytes en mémoire, soit 40 bytes pour un seul enregistrement d'un seul objet.
Après y a moyen de compresser ça, que ce soit en utilisant des shorts normalisés pour les quaterniosn (2 bytes) ou en utilisant des floats "customs" en changeant le nombre de bits dédiés à l'exponent, mantisse etc. Un float custom standard assez fréquent c'est le float16, 2 bytes mais niveau précision ça laisse vraiment à désirer passées certaines plages de valeurs

Après j'y crois pas trop, cette méthode à trop de limites. L'interpolation est pas très précise, pour les animations ça marche très bien ce genre de trucs car l'artiste peu ajuster les coeffs ou rajouter des points s'il voit qu'il y a une perte de précision trop lourde. Pour un truc en temps réel il peut rien faire.
Aussi si tu fais ça à pas de temps fixe ce sera pas terrible, à moins d'avoir un pas très petit mais tu le payes en mémoire, mémoire qui doit déjà être TRES précieuse. En effet, imagine que ton objet reste immobile pendant x temps puis parte d'un coup à grande vitesse, tu vas interpoler entre 2 transforms complètement différentes en un pas de temps, ce qui va probablement donner des résultats vraiment pas terribles.
Donc faudrait en plus rajouter un truc qui surveille les delta entre transforms pour éviter que ce soit trop brutal, du moins un truc dans le genre.

Après les mecs chez EPD sont des monstres hein, force à eux nonobstant s'ils ont dû coder ce truc de manière "générale", ça peut partir en vrille beaucoup trop facilement vu tout le reste du monde.

Le 31 mars 2023 à 00:54:58 :
Sinon t'as la chaîne R&D de Capcom, tout en jp mais ils montrent beaucoup de choses, y compris leurs outils inhouse https://www.youtube.com/@CAPCOM_RandD/videos
Ca parle de physique, de vfx, de modelling etc etc pour des jeux comme DMCV et MHRise
Enfin tu peux toujours DL les présentations CEDEC de n'importe quelle année en te créant un compte sur le site officiel, tu peux utiliser google translate pour traduire les slides directemtn https://cedil.cesa.or.jp/

Cool. Merci du lien

Le 31 mars 2023 à 12:37:48 :
Ahi, Eiki et Henri toujours fidèles au poste

Le 31 mars 2023 à 11:51:07 :
Questions aux collègues dev : comment vous vous y prendriez pour Rétrospective ?
Techniquement pour remonter le temps de l'objet il faut avoir sauvegardé son trajet, sauf que niveau conso de ressources c'est infâme vu le nombre d'objets dont on doit pouvoir remonter le temps.
Une solution serait aussi simplement de juste avoir en mémoire de quoi pouvoir recalculer en temps réel l'ancien trajet pour sauvegarder moins de choses (et consommer moins de RAM).

A chaud, comme ça, vous faites comment ?

Je pense que ça va concerner que quelques objets bien précis pour lesquelles les trajectoires sont définies d'avance.
Sinon si je devais faire une implémentation moi-même ce serait une approche similaire au VDD:
-foutre un tag "retrospectivable" aux objets déplaçables par le joueur susceptibles de l'être. Si ce sont de gros objets harcodés comme la pierre qui est remontée on a déjà la trajectoire. Sinon,
-toutes les x ms, enregistrer la rotation (quaternion) et la position (vecteur) de l'objet et faire une interpolation avec spline cubique.
-Ne faire ça que si l'objet est dans un certain périmètre pour éviter de stocker des infos pour rien.

Coût en mémoire: 4 floats pour le quaternion, 3 floats pour le vecteur soit 7 floats pour un enregistrement. Faut ajouter à ça les autres floats pour les coefficients pour les coefficients d'interpolation de la spline cubique (ça dépend si t'utilises Hermite, CatmullRom ou autre) soit environ 10 floats de chacun 4 bytes en mémoire, soit 40 bytes pour un seul enregistrement d'un seul objet.
Après y a moyen de compresser ça, que ce soit en utilisant des shorts normalisés pour les quaterniosn (2 bytes) ou en utilisant des floats "customs" en changeant le nombre de bits dédiés à l'exponent, mantisse etc. Un float custom standard assez fréquent c'est le float16, 2 bytes mais niveau précision ça laisse vraiment à désirer passées certaines plages de valeurs

Après j'y crois pas trop, cette méthode à trop de limites. L'interpolation est pas très précise, pour les animations ça marche très bien ce genre de trucs car l'artiste peu ajuster les coeffs ou rajouter des points s'il voit qu'il y a une perte de précision trop lourde. Pour un truc en temps réel il peut rien faire.
Aussi si tu fais ça à pas de temps fixe ce sera pas terrible, à moins d'avoir un pas très petit mais tu le payes en mémoire, mémoire qui doit déjà être TRES précieuse. En effet, imagine que ton objet reste immobile pendant x temps puis parte d'un coup à grande vitesse, tu vas interpoler entre 2 transforms complètement différentes en un pas de temps, ce qui va probablement donner des résultats vraiment pas terribles.
Donc faudrait en plus rajouter un truc qui surveille les delta entre transforms pour éviter que ce soit trop brutal, du moins un truc dans le genre.

Après les mecs chez EPD sont des monstres hein, force à eux nonobstant s'ils ont dû coder ce truc de manière "générale", ça peut partir en vrille beaucoup trop facilement vu tout le reste du monde.

tiens ça fait longtemps

Le 31 mars 2023 à 12:37:56 :

Le 31 mars 2023 à 00:54:58 :
Sinon t'as la chaîne R&D de Capcom, tout en jp mais ils montrent beaucoup de choses, y compris leurs outils inhouse https://www.youtube.com/@CAPCOM_RandD/videos
Ca parle de physique, de vfx, de modelling etc etc pour des jeux comme DMCV et MHRise
Enfin tu peux toujours DL les présentations CEDEC de n'importe quelle année en te créant un compte sur le site officiel, tu peux utiliser google translate pour traduire les slides directemtn https://cedil.cesa.or.jp/

Cool. Merci du lien

Le 31 mars 2023 à 12:41:28 :

Le 31 mars 2023 à 12:37:48 :
Ahi, Eiki et Henri toujours fidèles au poste

Le 31 mars 2023 à 11:51:07 :
Questions aux collègues dev : comment vous vous y prendriez pour Rétrospective ?
Techniquement pour remonter le temps de l'objet il faut avoir sauvegardé son trajet, sauf que niveau conso de ressources c'est infâme vu le nombre d'objets dont on doit pouvoir remonter le temps.
Une solution serait aussi simplement de juste avoir en mémoire de quoi pouvoir recalculer en temps réel l'ancien trajet pour sauvegarder moins de choses (et consommer moins de RAM).

A chaud, comme ça, vous faites comment ?

Je pense que ça va concerner que quelques objets bien précis pour lesquelles les trajectoires sont définies d'avance.
Sinon si je devais faire une implémentation moi-même ce serait une approche similaire au VDD:
-foutre un tag "retrospectivable" aux objets déplaçables par le joueur susceptibles de l'être. Si ce sont de gros objets harcodés comme la pierre qui est remontée on a déjà la trajectoire. Sinon,
-toutes les x ms, enregistrer la rotation (quaternion) et la position (vecteur) de l'objet et faire une interpolation avec spline cubique.
-Ne faire ça que si l'objet est dans un certain périmètre pour éviter de stocker des infos pour rien.

Coût en mémoire: 4 floats pour le quaternion, 3 floats pour le vecteur soit 7 floats pour un enregistrement. Faut ajouter à ça les autres floats pour les coefficients pour les coefficients d'interpolation de la spline cubique (ça dépend si t'utilises Hermite, CatmullRom ou autre) soit environ 10 floats de chacun 4 bytes en mémoire, soit 40 bytes pour un seul enregistrement d'un seul objet.
Après y a moyen de compresser ça, que ce soit en utilisant des shorts normalisés pour les quaterniosn (2 bytes) ou en utilisant des floats "customs" en changeant le nombre de bits dédiés à l'exponent, mantisse etc. Un float custom standard assez fréquent c'est le float16, 2 bytes mais niveau précision ça laisse vraiment à désirer passées certaines plages de valeurs

Après j'y crois pas trop, cette méthode à trop de limites. L'interpolation est pas très précise, pour les animations ça marche très bien ce genre de trucs car l'artiste peu ajuster les coeffs ou rajouter des points s'il voit qu'il y a une perte de précision trop lourde. Pour un truc en temps réel il peut rien faire.
Aussi si tu fais ça à pas de temps fixe ce sera pas terrible, à moins d'avoir un pas très petit mais tu le payes en mémoire, mémoire qui doit déjà être TRES précieuse. En effet, imagine que ton objet reste immobile pendant x temps puis parte d'un coup à grande vitesse, tu vas interpoler entre 2 transforms complètement différentes en un pas de temps, ce qui va probablement donner des résultats vraiment pas terribles.
Donc faudrait en plus rajouter un truc qui surveille les delta entre transforms pour éviter que ce soit trop brutal, du moins un truc dans le genre.

Après les mecs chez EPD sont des monstres hein, force à eux nonobstant s'ils ont dû coder ce truc de manière "générale", ça peut partir en vrille beaucoup trop facilement vu tout le reste du monde.

tiens ça fait longtemps

Jai l'impression que ça fait quelques mois seulement, ça passe beaucoup trop vite Bien profité du GOTY XC3?

sinon oui, ya moyen que les blocs de pierres qui tombent du ciel soient hardcoded.
(je vois bien aussi venir le script qui ne les fait tomber que quand tu es a portée d'ailleurs)

Coût en mémoire: 4 floats pour le quaternion, 3 floats pour le vecteur soit 7 floats pour un enregistrement. Faut ajouter à ça les autres floats pour les coefficients pour les coefficients d'interpolation de la spline cubique (ça dépend si t'utilises Hermite, CatmullRom ou autre) soit environ 10 floats de chacun 4 bytes en mémoire, soit 40 bytes pour un seul enregistrement d'un seul objet.
Après y a moyen de compresser ça, que ce soit en utilisant des shorts normalisés pour les quaterniosn (2 bytes) ou en utilisant des floats "customs" en changeant le nombre de bits dédiés à l'exponent, mantisse etc. Un float custom standard assez fréquent c'est le float16, 2 bytes mais niveau précision ça laisse vraiment à désirer passées certaines plages de valeurs

et d'ailleurs, ce genre de memoire c'est la RAM qui est concernée c'est ça? donc ça va prendre sur les 4GB que la switch a? (corrige moi si je me trompe)

Le 31 mars 2023 à 12:47:16 :

Le 31 mars 2023 à 12:37:56 :

Le 31 mars 2023 à 00:54:58 :
Sinon t'as la chaîne R&D de Capcom, tout en jp mais ils montrent beaucoup de choses, y compris leurs outils inhouse https://www.youtube.com/@CAPCOM_RandD/videos
Ca parle de physique, de vfx, de modelling etc etc pour des jeux comme DMCV et MHRise
Enfin tu peux toujours DL les présentations CEDEC de n'importe quelle année en te créant un compte sur le site officiel, tu peux utiliser google translate pour traduire les slides directemtn https://cedil.cesa.or.jp/

Cool. Merci du lien

Le 31 mars 2023 à 12:41:28 :

Le 31 mars 2023 à 12:37:48 :
Ahi, Eiki et Henri toujours fidèles au poste

Le 31 mars 2023 à 11:51:07 :
Questions aux collègues dev : comment vous vous y prendriez pour Rétrospective ?
Techniquement pour remonter le temps de l'objet il faut avoir sauvegardé son trajet, sauf que niveau conso de ressources c'est infâme vu le nombre d'objets dont on doit pouvoir remonter le temps.
Une solution serait aussi simplement de juste avoir en mémoire de quoi pouvoir recalculer en temps réel l'ancien trajet pour sauvegarder moins de choses (et consommer moins de RAM).

A chaud, comme ça, vous faites comment ?

Je pense que ça va concerner que quelques objets bien précis pour lesquelles les trajectoires sont définies d'avance.
Sinon si je devais faire une implémentation moi-même ce serait une approche similaire au VDD:
-foutre un tag "retrospectivable" aux objets déplaçables par le joueur susceptibles de l'être. Si ce sont de gros objets harcodés comme la pierre qui est remontée on a déjà la trajectoire. Sinon,
-toutes les x ms, enregistrer la rotation (quaternion) et la position (vecteur) de l'objet et faire une interpolation avec spline cubique.
-Ne faire ça que si l'objet est dans un certain périmètre pour éviter de stocker des infos pour rien.

Coût en mémoire: 4 floats pour le quaternion, 3 floats pour le vecteur soit 7 floats pour un enregistrement. Faut ajouter à ça les autres floats pour les coefficients pour les coefficients d'interpolation de la spline cubique (ça dépend si t'utilises Hermite, CatmullRom ou autre) soit environ 10 floats de chacun 4 bytes en mémoire, soit 40 bytes pour un seul enregistrement d'un seul objet.
Après y a moyen de compresser ça, que ce soit en utilisant des shorts normalisés pour les quaterniosn (2 bytes) ou en utilisant des floats "customs" en changeant le nombre de bits dédiés à l'exponent, mantisse etc. Un float custom standard assez fréquent c'est le float16, 2 bytes mais niveau précision ça laisse vraiment à désirer passées certaines plages de valeurs

Après j'y crois pas trop, cette méthode à trop de limites. L'interpolation est pas très précise, pour les animations ça marche très bien ce genre de trucs car l'artiste peu ajuster les coeffs ou rajouter des points s'il voit qu'il y a une perte de précision trop lourde. Pour un truc en temps réel il peut rien faire.
Aussi si tu fais ça à pas de temps fixe ce sera pas terrible, à moins d'avoir un pas très petit mais tu le payes en mémoire, mémoire qui doit déjà être TRES précieuse. En effet, imagine que ton objet reste immobile pendant x temps puis parte d'un coup à grande vitesse, tu vas interpoler entre 2 transforms complètement différentes en un pas de temps, ce qui va probablement donner des résultats vraiment pas terribles.
Donc faudrait en plus rajouter un truc qui surveille les delta entre transforms pour éviter que ce soit trop brutal, du moins un truc dans le genre.

Après les mecs chez EPD sont des monstres hein, force à eux nonobstant s'ils ont dû coder ce truc de manière "générale", ça peut partir en vrille beaucoup trop facilement vu tout le reste du monde.

tiens ça fait longtemps

Jai l'impression que ça fait quelques mois seulement, ça passe beaucoup trop vite Bien profité du GOTY XC3?

bien profité oui(même si un peu deçu sur certains trucs), Eiki beaucoup moins mdr

Le 31 mars 2023 à 12:50:07 :
sinon oui, ya moyen que les blocs de pierres qui tombent du ciel soient hardcoded.
(je vois bien aussi venir le script qui ne les fait tomber que quand tu es a portée d'ailleurs)

Coût en mémoire: 4 floats pour le quaternion, 3 floats pour le vecteur soit 7 floats pour un enregistrement. Faut ajouter à ça les autres floats pour les coefficients pour les coefficients d'interpolation de la spline cubique (ça dépend si t'utilises Hermite, CatmullRom ou autre) soit environ 10 floats de chacun 4 bytes en mémoire, soit 40 bytes pour un seul enregistrement d'un seul objet.
Après y a moyen de compresser ça, que ce soit en utilisant des shorts normalisés pour les quaterniosn (2 bytes) ou en utilisant des floats "customs" en changeant le nombre de bits dédiés à l'exponent, mantisse etc. Un float custom standard assez fréquent c'est le float16, 2 bytes mais niveau précision ça laisse vraiment à désirer passées certaines plages de valeurs

et d'ailleurs, ce genre de memoire c'est la RAM qui est concernée c'est ça? donc ça va prendre sur les 4GB que la switch a? (corrige moi si je me trompe)

Oui c'est ça, que de la mémoire vive, qui est déjà bien sollicitée pour tout ce qui se passe à côté. Clairement c'est pas GF qui aurait pu faire ce jeu

je vois bien aussi venir le script qui ne les fait tomber que quand tu es a portée d'ailleurs

Ça c'est une certitude. Tu vas pas obliger le joueur à scanner l'environnement à chaque fois pour savoir quelle pierre vient de tomber et est rembobinable.