Forum Unity3D-France

Bonjour,
je vous remercie par avance de vos réponses.

Je souhaite créer une nouveau jeu, mais avant de me lancer dedans j’essaie de résoudre tout les problème technique que j'arrive à imaginer.
Mon problème est le suivant : je cherche à créer une sorte de RPG solo qui ce joue plus ou moins automatiquement, jusque la c'est dans mes cordes. La vrai particularité est que je souhaiterai que le jeu continue une fois que l'application soit fermé.
Je voudrais donc que par exemple l'utilisateur définisse une destination, ensuite ferme le jeu. Reviens plusieurs heures (24-48h max) après et qu'il puisse reprendre le jeu comme ci le jeu avais continué sans lui.
Le vrai difficulté est que je voudrais que le jeu fasse exactement comme ci il avais joué pendant ce temps (prendre des coup par les monstres, etc).
Ma piste de réflexion étais la suivante avant de tombé à l'eau :
- Faire tourné l'application dans un FixedUpdate() limité a 50ms
- D'une manière ou d'une autre je récupérè l'heure de fermeture de l'application
- Attendre la réouverture
- Calculé le nombre de frame qui aurai du être écoulé depuis ce temps
- Relancé la boucle de calcule dans un Update()... qui devrais environ être entre 10 et 20ms jusqu'a avoir rattrapé le temps actuelle.

Sur le papier sa devrai marché sauf que pour rattrapé 50ms de frame sur 24h il en faudrait environ 1/3 de temps ce qui reviendrai à 8h de simulation... ce qui colle pas à un gameplay correcte (je serai prêt à faire attendre l'utilisateur 1min sur 24h de "non-jeu" pour être correct).

J’avoue être vraiment à sec au niveau des idées... peut être c'est juste impossible et que je devrais chercher un autre gameplay ?
Je ne cherche pas une réponse toute faites mais juste une piste de réflexion.

Si ce n'est pas très claire n’hésitez pas à me le dire.
Je vous remercie beaucoup par avance.

Salut,

Je me suis déjà posé cette même question sans pouvoir trouver de "bonne" solution.
La meilleure solution que j'avais imaginée était de simuler le temps "offline" lors de la reconnexion, mais cela créer de l'attente pour le joueur. Et si on veut compenser l'attente on faisant la simulation plus rapidement en augmentant le temps de simulation par frame cela créer des pertes de temps (car si une action mets moins de temps à s'exécuter qu'une frame de simulation, la différence est perdue, ou cela devient un vrai bordel de stocker les différences etc)

Donc si quelqu'un a des idées je suis aussi intéressé.

Et pourquoi pas utiliser un serveur qui calcule tout ça en externe? Par contre, cela nécessite obligatoirement une connexion.

Salut boubouk,

Ton idée est sympa, mais effectivement pour un jeu solo ce serait dommage d'avoir une connexion obligatoire.

si vos donnés sont découplées de unity (oubliez le update de unity et faire son propre update dans son modele de donnée)
Vous pourrez faire autant d'update que vous voulez dans un update unity. Quand tu ouvre ton apllication tu fais (heure maintenant - heure fermes) / temps d'une frame, ca donne le nombre d'update a faire.

je sais pas si c'est une piste qui peut aider, a voir.

Salut. C'est compliqué mais tu a au moins le mérite d'avoir trouver une solution (longue mais solution quand même), dans tout les cas je pense que si tu veux "reconstruire" le temps ou le jeu est fermé, tu va devoir te pencher vers le multithread et te dépatouiller pour qu'il gère plusieurs aspect de ta simu, en d'autre terme c'est vraiment beaucoup de travail car tu va devoir faire attention au composant de unity qui ne son pas thread-safe (et bien sur, faire en sorte que t'es propre simu soit thread-safe) donc ça demande de réfléchir à tout ça avant de ce lancer, pour anticiper le développement des fonctionnalités qui nécessiterons d'être thread-safe par la suite. Tu gagne beaucoup de temps de simu, mais aussi beaucoup plus de travail. De toutes façons si ta simu prend 8h c'est pas le fait d'implémenter du multi-thread qui va la faire passer à 1 minute, mais c'est fort probable que tu y soit confronté si tu veux vraiment mettre en place cette idée en ayant le processus fermé.

Par contre étant donné que tu n'a rien dev pour l'instant, le multi-thread est optionnel car on ne sait même pas la charge CPU que prendras la simu, tu peux donc reconstruire en plusieurs simu sans utiliser de multi-thread (et l'utiliser pour réduire encore plus le temps).

avant de parler de multithreading il faut déjà que tes données soit isolées dans un modèle non unity. A mon avis ca tu n'y échappera pas. Ensuite une foule de questions vont te permettre de choisir une solution plutôt qu'une autre. Un exemple tous simple, si un véhicule va du point A au point B en 10 secondes, est-ce que tu fais 1000 update de 0.01 sec ou est-ce que tu fais simplement le calcul une fois (dans un proto, quand j'avais changé mon serveur pour qu'au lieu de faire des updates il calcule juste la position d'un vaisseau a un temps X j'avais gagné un temps fou)

Salut,
Je remonte ce poste parce que j'ai eu a travailler il y a quelques années sur un probléme un peu similaire, j'avais créé une série de statistique à plusieurs échelles pour alléger le travail. Au lieu de simuler absolument tout le gameplay, tu fonctionne par approximation, la seul chose que veux ton joueur c'est le un résultat.
dans ton cas par exemple, tu a 8h à simuler pour un RPG: une quête prend en moyenne 20min, soit 24 quête. tu donne à ton joueur le résultat moyen de 24 quêtes et un avancement aléatoire dans une quête en cours et c'est réglé.
S'il s'absente que 10min, au début d'une quête, il revient avec la quête complété à 50%, et s'il affronte un ennemi par minute en moyenne, tu lui donne le résultat de 10 combat.
tu ne pourra jamais resimuler frame par frame plus de quelques seconde.

La précisions avec laquelle tu va simuler sont absence dépend uniquement du compte rendu que tu veux soumettre à ton joueur: liste de zone visité ? liste des quêtes complété ? liste des ennemis affronté ? etc