Sujet: Système de temps interne au jeu [Complexe] Ven 27 Mar 2009 - 9:03
Multipost à cause de dépassement de longueur dsl
Bonjour ,
Je cherchais un système jour/nuit qui gère aussi les saisons. J'ai trouvé un tuto sur un autre site, cependant j'ai modifié le système pour convenir à mes exigeances. (En réalité, j'ai refondu le système car copier-collé, c'est bien, mais comme il est un peu compliqué, je m'y perdais car je ne concevais pas les unités de temps de la même façon. )
Enfin bref, je vous présente ma version du système.
[ Edit 26/03/2008] En réalité, je vous propose plusieurs versions plus ou moins complètes, plus ou moins lourdes. Allez voir la source pour avoir un système plus simple.
[ Edit 13/04/2008] Je posterai bientôt un autre système suivant le calendrier grégorien, ça n'a pas été simple (car il est bien en grégorien maintenant...) mais j'essais de rendre les saisons (donc la météo et le calcul des modifications de la durée du jour aussi) indépendantes de la date mais dans un cycle apart à l'image des lunaisons... Bref les dates de début de saisons, si je ne me plante pas, varieront comme dans la réalité. Le système sera franchement semblable à la réalité, car pour le moment mes dates de débuts de saisons sont fixes... et à ce moment, il sera abouti, enfin pour moi! (de plus, je bosse sur une version "compressée" sur histoire de faire le moins d'event commun possible pour le rendre plus léger pour l'ordi mais, il sera moins compréhensible pour le lecteur).
Description:
Spoiler:
Ce système génére une notion de Temps pour votre jeu, il en déduit la luminosité correspondante (le ton), et génére des effets météos. (+la météo "Soleil" de nostal Geek, et de Volpar ^-^ adaptée).
Il est toujours en phase de test.... Je l'édite souvent, donc il se peut que dans les versions les plus avancées il y ait des bugs. Car pour vérifier que le temps tourne bien, il faut attendre... attendre longtemps .
Je pense surtout que ce genre de système est très personnel, je suis certain que mon système ne vous conviendra pas tel quel et que dans un mois, mon système aura une nouvelle tête...
Le temps: il suit le modèle du calendrier Julien, Minutes, Jours, Mois, Années. (Avant, il y avait aussi les secondes (héritage de ma source) mais, à force d'édit, je les ai retirée car elles demandaient trop d'efforts à l'ordi pour une notion qui dans la réalité est déjà rapide, qui aurait dû l'être encore plus dans le jeu, de ce fait, elles n'auraient pas eu de réelle utilité. Cela explique leur présence, sur certains screens)
Le système sait repérer les jours de la semaine, si vous voulez faire que le lundi les commerces soient fermés. Le nombre de jours dans les vrais mois, et (donc) les années bissextiles... Il sait repérer les saisons, pour la météo.
Vous pouvez lui indiquer l'intérieur de l'extérieur, et vous permez de gérer des exceptions lumineuses, ou météorologiques. Il y a aussi un initialisateur de temps, il sert quand vous modifiez le temps (Auberge... Voyage Temporel ou que sais-je...) pour contrôler qu'il n'y a pas d'incongruités (25ième heures...).
Le tout est assez lourd et indigeste, d'un point de vu event, mais je n'ai pas vu plus complet =^-^=. J'ai fait le choix de faire plein de common events séparés pour mieux m'y retrouver, et vous permettre de customiser sans trop de problèmes, mais je suis sûr que tout est squeezable en deux-trois gros events.
Source:Humitake
Son système découlait déjà d'un autre. On ne réinvente pas l'eau chaude. Ma source gère les secondes, les minutes, les jours, et les mois. Dedans, les mois représentent les saisons. Les exceptions lumineuses ne sont pas gérées, la luminosité varie partout. C'est déjà bien complet, et le tout en une seule common event. Facilement customisable, vous pourrez même créer votre propre Horloge à partir de la sienne.
Les choses sérieuses
Je vais commencer par expliquer les mécanismes de base.
La boucle de temps de base
Spoiler:
****Horloge****
*****Horloge***** est le coeur du système. C'est un processus paralèlle, qui incrémente le temps. En l'activant on active tout, en le déactivant... Euhhh non ça ne désactive pas tout...
Començons simplement... Le screen parle de lui-même.
J'ai crée mes variables <Minutes>, <Heures>, et <Jours> Je crée une boucle à partir d'une étiquette "Debut boucle", le temps y tournera. A chaque tour, il ajoute une minute. Le fait d'attendre 60 ou X frames définit votre minute fictive.
Dans le cas du screen, une minute fictive (F) est environ égale à une seconde réélle (R). Ainsi: une heure (F) = une minute (R) un jour (F) = 24 minutes (R) et ainsi de suite... un mois de 30 jours (F) = 12 heures (R)
Tout est une histoire de dosage. 144 heures (R) pour une année (F) peut paraitre long, mais si vous combinez ce système car un système de sommeil, le temps avancera plus vite. Car il ne faut pas oublier que vous pouvez ajouter directement du temps aux variables correspondantes (quand le perso dort, par exemple).
Le fait de mettre ">= 60", ainsi que de "-= 60" plutôt que de remettre les variables à zéro, est là, au cas où il y a un ajout de temps par un event extérieur au système et pour réguler cet ajout sans l'ignorer. (c'est une sécurité, cependant elle ne sera pas suffisante pour gérer les ajouts de temps)
C'est un principe de limite, ici la limite des minutes est 60. Le principe est le même pour les heures, respectivement 24 et toutes les autres unités de temps.
Et justement, on arrive aux jours, qui incrémentent les mois, mais il y a une complication: Le nombre de jours dans le mois changement. Que cela ne tienne, il suffit de faire un petit événement qui retournera, en fonction du mois actuel, le nombre de jours qu'il contient. Autre broutille: les années Bissextilles et le mois de Février viennent jouer aussi les trouble-fêtes.
Fct Jour dans Mois?
Cette fonction n'est qu'un ensemble de conditions qui testent la valeur du <Mois> par le biais d'une autre variable, Info Temp* J ds M et attribuent en conséquence une nouvelle valeur à Info Temp* J ds M. Elle a besoin qu'on lui dise quel mois on est, puis retourne le nombre de jour dans la même variable.
( mes variables ont peut-être des noms bizarres pour vous, mais c'est parce qu'ils décrivent ce qu'elles contiennent, et les droits d'access que je me fixe dessus. Pour l'info cette variable est pour moi une pseudo-Temporaire, c'est-à-dire qu'elle doit être initialisée "manuellement" avant de pouvoir en faire quelquechose, et elle est de droits d'acces "Info", je me dis qu'après, je me laisse juste le droit de tester la valeur et de ne plus la modfier, bref du charabia que je suis le seul à comprendre (Convention expliquée dans les démos) ).
Il y a le point particulier de Février et les années bissextiles:
D'un point de vue global, pour savoir si a est multiple de b Je me base sur la nature de nos variables: elles sont des entiers donc les divisions donnent des nombres entiers. Exemple: 5/2 = 2 et non 2,5 car l'ordinateur tronque le résultat automatiquement. Ainsi pour savoir si a est multiple de b, il suffit de tester si ((a/b)*b) == a.
Je rappelle qu'une année Bissextile est multiple de 4 (dans le calendrier Julien). Bon, il est vrai que c'est de la broutille, mais il se peut que le 29 Fevrier, vous ayez envie de mettre des events spéciaux... J'aime bien l'idée d'un jour spécial mais bon une fois tout les 4 ans est-ce que ça vaut vraiment le coup? Vous pouvez trafiquer le temps pour rajouter un 32ème jour quand ça vous chante... Pour le moment restons général.
Autre remarque: le calendrier réel est Grégorien: les années bissextiles sont multiples de 4, 400, mais pas de 100... je n'ai pas pris le temps de le faire, car c'est de l'embêtement, mais ça viendra.
Retour à l'****Horloge****
Bon, nous allons incrémenter les mois, puis les années... Maintenant, on sait déterminer la limite des jours par mois, on utilise presque la même formule pour l'incrémentation, presque. La difference vient du fait qu'il n'y a pas de jour 0 ou de mois 0. Pour les minutes ou les heures, ça n'était pas génant car il y a une concordance entre le 60 et le 0, ou le 24 et le 0. Bref il faut décaler de 1 la boucle... ">=" devient strict ">", c'est tout bête.
Les années n'ont pas de limites, bien sûr.
Voyons notre fin de boucle:
Bon on a une boucle de base... Il y a de nombreuses améliorations à apporter, la route est longue, trèèèèès longue . mais c'est un bon début.
Premiers petites Options
Spoiler:
Optionnel:Fct Nbs J totaux??
Cette fonction est très très importante, mais assez compliquée. Il y a sûrement des petites erreurs, mais elles ne l'empêchent pas d'être cohérente. Elle compte le nombre de jour depuis l'origine ou le nombre de jour qu'il faut pour l'atteindre. Son importance tient au fait que nos calendriers humains ne sont pas parfaits et ne permettent pas d'englober tous les cycles naturels parfaitement. Les années bissextiles sont un artifice pour corriger les écarts entre la réalité astronomique et nos dates plus ou moins fixes...
Elle permet de prendre en compte des cycles indépendants de la date: la semaine (cycle de 7 jours), les Lunaisons (cycle de 29,5 jours), les saisons (cycle de 91,... jours). Hélas, nous calculons avec des entiers donc nous ne pouvons pas être très précis, mais cette fonction n'en perd pas son utilité... (Cependant j'ai dû arrêter les saisons à des dates fixes pour stopper leur dérive, car j'en suis resté au calendrier Julien qui laisse les saisons se décaler de 3 jours tous les 100 ans...)
Cette fonction manipule rapidement de très grands nombres, donc n'abusez pas dans les dates éloignées du 0. Cependant je n'ai pas testé les limites...
Elle se divise en 2 parties: si l'année est positive (relativement simple), si l'année est négative (plus compliquée, mais pas de beaucoup)
Partie 1: screen:
La variable Info Temp Nbr J totaux prend la valeur de l'année actuelle test si elle est positive ou négative...
Une fois testée, elle se remet à 0 puis prend la valeur du nombre du jour actuel.
(Temp Nbr J totaux) est un compteur, il va prendre le nombre du mois - 1, va le décrémenter jusqu'à janvier (1-1 = 0) et à chaque décrémentation, on ajoutera le nombre de jour dans le mois, le tout -1 car le jour 0 n'existe pas, il ne s'est pas écoulé.
Ensuite elle additionne le nombre d'année bissextiles x 366, et la différence avec les années actuelles x 365...
Partie 2:
La différence réside dans le fait qu'on retranche le nombre de jour dans le mois, et le nombre de jour actuel car si on est à l'an -1 (je sais, c'est absurde) il faut 365 jour moins les jours depuis le début de l'année pour arriver à l'an 0 (qui en réalité n'existe pas...) .
A la fin, le nombre de jour depuis l'an 0 est dans Info Temp Nbr J totaux. Bon cette fonction est complexe n'hésitez pas à me corriger, et me poser des questions dessus.
Optionnel:Fct Jour Semaine?
Plus ou moins utile, cette fonction utilise Info Temp Nbr J totaux. En considérant que le premier jour était un lundi, cette fonction décrémente de 7 en 7 un double "temporaire" ce nombre, dans une boucle, le reste des opérations nous donne le jour actuel. 0 = Lundi, 1 = Mardi .... 6 = Dimanche... Ce nombre se trouve dans Info Temp Jour Semaine... C'est bidon pour être un common event à part entière, mais si je la mettais dans ****Horloge**** je me perdrais car ça n'a rien avoir avec l'incrémentation du temps.
Il y a deux façons de gerer cette fonction: soit de l'appeler avant de tester Info Temp Jour Semaine, soit inclure directement l'appel dans la boucle du temps en MàJ automatique en quelque sorte, à chaque changement de jour.
Dernière édition par vincentmhd le Mar 23 Fév 2010 - 0:34, édité 2 fois
vincentmhd
Maire Lv.9
Age : 37 Inscrit le : 04/02/2009 Messages : 326
Sujet: Re: Système de temps interne au jeu [Complexe] Ven 27 Mar 2009 - 9:44
Initialisations
Spoiler:
Le blocage ou verouillage
Nos variables commencent toutes à 0... c'est moche et illogique...
Ah ça, je répond "Initialisation"...
C'est ce que nous allons construire. C'est une fonction ou une partie d'event qui ne sera parcourue qu'une fois par le programme, puis qui se verouillera toute seule. Son but est de s'assurer que l'event maître à des variables conforment à l'utilisation qu'il va en faire. Le seul moyen de la dévérouiller est "manuelle"...
Quand je dis "manuelle", j'entend que ce sera voulu, intentionnel car il ne sera pas normal que le jeu dévérouille tout seul une init. J'utilise pour marquer le coup des interrupteurs que je nomme "Blc" pour "Blocage", et je m'interdit d'y toucher en dehors de l'event concernée. Il existe cependant des exceptions, vous allez en voir une, un peu plus loin.
Bon, cette initialisation va être lourde, donc je la met en dehors de l'*****Horloge****** mais pour économie de place, elle aurait pu être dedans. Je crée mon bloqueur:
C'est la base, tout ce qui sera fait dans la condition ne sera lu qu'une fois. Ce screen était juste pour le principe car il est très important...
Le corpus de l'Init
Bon que voulez vous faire? Quelles sont les améliorations à apporter:
- pouvoir fixer ses propres valeur du départ... (ne pas commencer à l'an 0) - voyager dans le temps, en + et en -.
Au final, L'horloge le pourra mais l'expliquer n'est pas trop ma tasse de thé.
L'ajout en +, Horloge le fait déjà automatiquement. En réalité , plus tard d'autres fonctions viendront s'intercaller dans la boucle Horloge et elles auront besoins de valeurs correctes. Donc l'initialisation devra s'en charger avant...
Si on modifie les variables de temps, il va falloir vérifier les valeurs ajoutées pour créer le saut temporel. Cela signifie appeler l'initialisation "manuellement" ... C'est mon exception, elle est valide car dans mon Initialisation, il n'y aura que de la vérification de valeur, et pas d'affectations directes pures et dures Quand on voyagera en - c'est le même topo, c'est une vérification... les <> autour de Blc, symbolisaient cette permission de débloquer ponctuellement l'initialisation.
Pour l'initialisation des valeurs, et le fait de commencer à l'an 1234, il y a plus fin que ajouter 1234 années, 4 mois... C'est là, que je sors mon joker en disant que je peux mettre un blocage dans le blocage... Une boite dans une boite... On pourra appeler l'initialisation sans que cette partie de l'initialisation soit relue. Elle ne sera JAMAIS relue. une Init dans l'Init qui elle, pourra faire des affectations... puisqu'elle n'est pas <>.
Bon, un screen parlera peut-être mieux:
(Dans le screen il y a un mini oubli: l'interrupteur 3, sans nom, s'appelle Blc Init Init Horloge, oubli de copier/coller)
Que voit-on?
Il y a de nouvelles variables "Init":
Les variables Init sont des variables auxquelles, je ne touche que très très rarement car leur fonction est de garder la trace de la date initiale... Pour le moment, c'est un peu inutile mais je suis sûr que j'en aurais besoin un jour. (je cherche à faire une fonction retournant le nombre de jours vécus... != de jours totaux, bref c'est pas aboutie, donc je laisse la porte ouverte) C'est elles qui s'affectent à leur soeur <>, dans mon "langage" barbare <> signifie "pas d'affectations, juste de la modification: += -=... sauf à l'initialisation" et c'est le cas. C'est le seul moment où elles auront une affectation.
On vérifie qu'il n'y a pas de mois 0, ou de jour 0.
Ensuite, on sort du blocage.
Nouveau screen: la vérification des anomalies positives...
La principale différence avec Horloge, c'est que ce n'est pas une boucle Il faut pouvoir en sortir
La vérification des valeurs négatives est vraiment similaire, sauf que les - sont des +, vis et versa...
Bon pour finir, il faut placer un appel vers l'initialisateur depuis la boucle Horloge. Dans la boucle Horloge juste sous l'étiquette de la boucle. Ainsi quand vous mofidifirez les variables de temps <>, Désactivez l'interrupteur de blocage <Blc Init Horloge> et la boucle fera les vérifications d'usage sans remettre le temps à la date Init. (Utile quand le perso dort dans un auberge... le temps passe en un instant )
Si vous utilisez Fct Jour Semaine en MàJ automatique, vous pouvez mettre un appel vers le common event, avant le blocage final de l'Init(histoire de ne pas attendre 1 jour avant d'avoir la bonne valeur ).
Ouf une grosse chose de faite... mais il en reste bien d'autres... mais le temps s'écoule normalement, et on peut commencer à jouer avec. Cependant, il est trop virtuel pour moi. Donnons-lui une forme concrète. Nous allons ajouter la notion de saison.
Les 4 saisons, partie 1
Spoiler:
Repérer la saison
Vous venez de passer un cap! maintenant que le temps tourne rond, il faut l'exploiter.
Les saisons sont très importantes, dans le sens, où elles définissent les météos possibles et la durée du jour et de la nuit...
Pour cela, j'ai 4 variables (il y aurait pu en voir 5, 6 selon vos goûts, 4 semble suffisant, car ça passe déjà vite) qui découpent les 24 h en petits morceaux, le matin, le jour, le soir et nuit pour moi. J'ai aussi une variable formidable, Info Saison qui indique la saison actuelle 1 = printemps, 2= été... (0 = rien! ). Ce sont des "Info" car seule la fonction suivante pourra les modifier, les autres ne feront que de les tester.
Elle est simple (bien que j'ai du la refaire une paire de fois ), elle teste les <Jours> et les <Mois> pour déterminer la saison et change les Infos relatives. Les saisons n'ont pas de dates fixes dans aucun calendrier, (même dans le Grégorien, elles oscillent entre 4 jours) cependant, je les ai fixées en me basant sur la plus récurente: le 21, et les heures du jour sont fantaisistes...
(Oups encore une bêtise de copier-coller, les variables sans nom s'appellent respectivement: Info Matin, Info Jour, Info Soir, Info Nuit.
C'est cette fonction qui est capricieuse dans Horloge car elle doit s'actualiser aux jours près, donc elle s'inclu après (Nbr de Jours totaux) += 1, mais nécéssite aussi un mois correct. C'est à cause d'elle en partie que Init doit faire une première vérif... Cette fonction s'intégre à plusieurs endroits:
-Juste avant le blocage de l'init de l'init... Elle se met à jour par rapport à ce que vous rentrez... rentrez des chiffres potables sinon rien Non je plaisante car c'est revérifié avec le blocage final, vous pouvez entrer 500 minutes, 26 heures, il fera la conversion...
-Juste avant le blocage finale de l'Init.
- et dans Horloge après (Nbr de Jours totaux) += 1 (peu importe par rapport à Fct Jour Semaine, elles sont bien distinctes).
le Gst Tps
Cette fonction gère des interrupteurs jour, matin, soir... Pourtant on a nos variables Infos, non? Oui et non, les varables Info définissent des intervals temporels, les interrupteurs des états. Il aurait été parfaitement possible de ne s'en sortir qu'avec les variables mais c'est fatigant de toujours tester dans quel interval on se trouve, alors que les interrupteurs donnent directement "c'est le matin", "c'est le soir", "c'est le jour" et si aucun actif "c'est la nuit", et cette Gst ("Gestion" dans ma langue) s'occupe de ça.
un simple screen vous fera comprendre la structure des tests:
Oui, il y a des instructions de désactivations inutiles, mais ayant eu des problèmes avec des jours nocturnes , j'ai préféré en mettre plus que nécéssaire.
Cette fonction s'appelle toutes les heures dans horloge , et après la Gst Saison à la fin de l'Init.
la Gst Luz Journee
Un peu plus concret on va enfin modifier la luminosité. Elle se base sur les interrupteurs Info Jour.... Pourquoi avoir séparer Gst Luz et Gst Tps... car Gst Tps tournera tourjours avec l'horloge dans le fond, mais on ne veut pas forcément garder les même modifications de la luminosité pour toutes les maps donc Gst Luz elle est séparé, activable et désactivable par des intérupteurs dans l'Horloge...
Les modifications sont progressives pour paraitre à peut-être naturelles.
On verra ça dans l'intégration.
le screen:
Bon c'est simple. Mettez les tons que vous sentez le mieux... Astuce: pour marquer les Saisons, je modifie très légérèment le ton de l'écran le jour. l'hiver est plus bleu, l'été jaune, l'automne marron, le printemps vert.
L'intégration:
Elle est un petit peu plus subtile, juste un peu. On ajoute un interrupteur qui lui annonce si elle doit continuer ou pas à s'occuper de la mise à jour de l'écran.
Bon maintenant, on a des "vraies" journées.
Intérieur / Extérieur
Enfin, nos journées existent, mais il y a un problème: elles ne se mettent à jour que toutes les heures... Oui, il manque encore plusieurs choses importantes. Une mise à jour rapide est nécéssaire pour les modifications du temps et les séparations intérieur/exterieur.
La première étape est de créer une Gst Luz identique à la première mais avec un temps d'affichage de 1 frame, pour que se soit instantané. Je m'épargne une capture d'écran, car c'est vraiment la même chose que la version progressive.
Elle s'intégre dans l'init à la fin avant le blocage... comme d'hab
On a réglé le problème de l'init mais pas de la séparation intérieur/extérieur. Il faut un autre événement.
MàJ Luz
C'est lui que l'on appelle en franchissant la séparation intérieur/extérieur. Oui, on n'arrête pas le temps parce qu'on a un toit sur la tête, de plus, le temps ne gère pas l'écran... Gst Tps et Gst Luz sont bien distincts...
Bon, il est ultra simple pour le moment, car on ne s'occupe pas des saisons, mais quand on en sera là, il prendra une meilleure forme... et puis on utilise qu'une seule Gst Luz, mais par exemple, dans mes projets, j'utilise une autre Gst Luz pour l'intéreur des maisons. Et ça complique la chose. Le point fort de mon système, c'est que je peux ajouter autant de Gst que mon envie le souhaite... mais il faudra jouer des interrupteurs pour que Horloge et MàJ Luminosité soient d'accord, ou ne pas les inclures dans le système du tout pour les activer manuellement.
Normalement, vous avez là des journées fonctionnelles:
Vous attribuez une date aux variables d'Init du temps, vous activez ou désactivez l'interrupteur Interieur opaque selon où vous commencez. Vous activez l'interrupteur Horloge pour lancer le système.
A la séparation Int/ext, il vous suffit d'activez ou désactivez l'interrupteur Interieur opaque et appelez MàJ Luz.
A l'ajout ou la soustraction de temps, vous désactivez <Blc Init Horloge> pour mettre à jour l'horloge...
Vous pouvez être content de vous, si vous en êtes là.
Dernière édition par vincentmhd le Ven 27 Mar 2009 - 14:19, édité 1 fois
vincentmhd
Maire Lv.9
Age : 37 Inscrit le : 04/02/2009 Messages : 326
Sujet: Re: Système de temps interne au jeu [Complexe] Ven 27 Mar 2009 - 9:46
Les 4 saisons, partie 2
Spoiler:
Généralités
Le sous-système de météo possède deux parties principales: le Générateur de nombre aléatoire, et la MàJ Mto. Ils sont séparés pour une bonne raison la météo doit continuer de varier à l'extérieur même si vous êtes à l'intérieur... et Idem si vous êtes sur un terrain à météo fixe...
A la difference de la luminosité, cela ne choque pas que la météo apparaisse progressivement en sortant d'un lieu. Par contre, la météo Soleil à besoin de menus arrangements pour être progressive.
Les météos sont pour moi stockées dans des events séparées afin de pouvoir les appeller manuellement, si j'ai envie d'avoir une météo spécifiquement sur une carte.
Les météos
Bon les météos sont des copies casi-conformes de celles de Humitake à quoi bon modifier une idée qui est bonne . Elles prennent comme paramètre l'intensité. (la Mto Soleil est spéciale, on verra ça plus loin). Si l'intensité = 0, alors elles ne font rien. Si vous voulez appeller manuellement une météo sur un terrain à météo fixe, il vous faudra lui dire quelle intensité avant, sinon on ne saurait prédire le résultat!.
Mto Pluie et Mto Neige sont strictement les mêmes à l'effet météorologique près.
Mto Orage a un ajout... il déclenche un événement parallèle, Mto Eclair qui fait sonner le tonnerre et le génére des flashs aléatoirement en fonction de l'intensité de l'orage. (Plus l'orage est intense plus les flash ont de chance d'être proche... , dans la pratique ça se ressent assez bien)
Voilà comment fonctionne Mto Eclair:
C'est un ensemble de deux boucles imbriquées:
La première s'occupe de déterminer "quand" la foudre va s'abattre. Elle génére un nombre aléatoire, et elle le multiplie par la différence entre 10 et l'intensité de l'orage... Plus l'Orange sera intense plus la variable sera petite. (L'intensité est comprise entre 0 et 9, mais quand elle est égale à 0 elle n'appelle pas l'éclair)
La seconde boucle décrémente le nombre obtenu, à 0 la foudre s'abat, et elle retourne générer un nouveau nombre...
Et ça continu tant que l'interrupteur (Mto Eclair) est activé.
Le Soleil
Le Soleil est issu du tuto de Nostal Geek et Volpar, mais il faut l'adapter car il est trop "brutal".
Regardons: (Bougre d'âne , il y a les events d'un autre projet dans la liste...)
Il faut au moins que l'on soit dans la journée, c'est déjà bien . Puis on affiche le Soleil avec une opacité nulle (invisible), pour lui demander de progressivement l'augmenter. L'afficher brutallement, ce n'est pas terrible terrible... Des améliorations sont à faire comme y intégrer différentes intensités... mais bon je n'ai pas eu vraiment le temps.
Autre remarque: l'arrêt de cette météo doit être aussi en fondu, sauf si changement de "milieu".
Le générateur
Le générateur crée des nombres aléatoires destinés à la météo, mais il ne touche pas directement aux intensités. C'est pour garder en mémoire la météo "normale", lorsque vous êtes sur un lieu à météo fixe. Car pour appeller une Mto manuellement, vous avez besoin de changer l'intensité... bref et ça peut mettre une petite pagaille, (que le joueur ne remarquera peut-être pas) mais qu'il vaut mieux éviter.
Le générateur fait mumuse avec des "( Temp Aléa ) ". Il les initialise à chaque fois, et leur attribut des valeurs aléatoires en fonction d'un aléatoire (Temp Aléa Mto) et des saisons...
On teste d'abord la saison.
Génére le fameux (Temp Aléa Mto).
En fonction de ce nombre, on génére une seule intensité celle de la Mto qu'il va faire, ou pas du tout.
On régénére (Temp Aléa Mto), pour le Soleil (servira plus tard). Pourquoi la régénérer... parce que le Soleil testera aussi cette valeur et il faudra que toutes les combinaisons soient possibles
Si vous regardez, vous observerez que le Soleil n'y est pas en tant qu Mto normale... Son "( Temp Aléa ) " associé est (Temp Aléa Mto) lui-même car ainsi, il peut faire du Soleil et pleuvoir, ou neiger... (Euhhh c'est une conception personnelle de la météo... , mais ça fait varier deux fois plus la météo, cependant, comme dit précédement, j'ai éliminé le Soleil pendant la Tempête, car là, je conçois que ce soit chelou, c'est dans la MàJ Mto que ça sera fait, comme ça je laisse la possibilité de le faire manuellement.)
Intégration :
Dans Horloge, après le changement d'heure et l'appelle de la Gts Tps. Ainsi la météo changera toutes les heures, c'est rapide, il existe des moyens de ralentir le changement ou de le rendre plus naturel, qu'à taux fixe, je vous le souflerais peut-être mais sachez que si vous êtes arrivé à suivre jusqu'ici, vous saurez vous débrouillez pour le faire vous-même . (oui je suis vilain! indice: un Blc et une Aléa devraient suffire)
Dans l'init à la suite de la Gst Tps aussi.
La MàJ Mto
Cette MàJ ne doit pas se faire à l'interieur ou dans les lieux à Mto fixe. Un jeu d'interrupteurs sera là pour s'occuper de cela. Elle est appellée toutes les heures en extérieur absolument.
Elle ne fait qu'appliquer les changements dictés par Géné Mto. Elle est courte, le screen vous causera à ma place...
C'est elle qui affecte les Aléas aux vraies Intensités puis qui appelle les Mto, comme normalement, il n'y a qu'une Intensité qui est différente de 0, c'est sa Mto qui s'applique, car sinon les effets météos s'écraseraient.
Si vous vous souvenez, notre Aléatoire de Soleil avait une valeur entre 0 et 20, ici on applique Soleil si elle est inférieure à 7 soit environs une chance sur trois. Je pose aussi mon incompatibilité Soleil et Orage.
**** j'ai fait quelques modifications récemment, le renouvellement du Soleil posait problème mais avec une variable mémoire et quelques conditions, on s'en sort. (Le problème était l'effacement brutal du Soleil pour le redémarer juste après, alors qu'il n'aurait pas fallut le renouveller tout simplement.)
L'intégration:
Il y a plusieurs possibilités: soit utiliser des interrupteurs bien distincts, soit des interrupteurs qui s'entre-mêlent. J'ai préféré la deuxième solution.
Ainsi j'obtiens un interrupteur Intérieur Translucide, et un autre Interieur Opaque. Le premier désactive la Mto, mais laisse la Gst luz travailler normalement... ça peut être une ruine, un abris de fortune... Le second désactive tout, tout simplement. Oui avec trois interrupteurs, j'aurais une possibilité en plus... mais ça donne plus de travail car là on utilise que des Gst de base... je compte multiplier les miennes.
un screen: d'Horloge
Bon pas besoin de schéma, elle s'inclu aussi dans l'Init avec les interrupteurs, après Géné Mto
A ne pas oublier elle va dans notre MàJ Luz qui devient MàJ Luz/Mto... deux en un c'est plus simple.
Il y a des trucs en plus... ben oui quand on entre dans une maison, il ne pleut pas dedans, alors on stop les Mto...
Bon normalement, encore un bond en avant. La météo de base fonctionne.
Ce qui suit est du Bonuxx.
vincentmhd
Maire Lv.9
Age : 37 Inscrit le : 04/02/2009 Messages : 326
Sujet: Re: Système de temps interne au jeu [Complexe] Ven 27 Mar 2009 - 9:46
Petites pistes, si vous voulez aller encore plus loin
Spoiler:
J'ai parlé de Lunaison???
Oui j'ai bien parlé de lunaison, mais je pense que simplement expliquer le principe vous suffira... (oui je suis trèèèès vilain) Rassurez-vous elle facile à faire. Les lunaisons, c'est quoi et elles servent à quoi? Les lunaisons sont les differentes phases de la lune, si on arrondi, on peut dire qu'elles apparaissent toutes dans le mois... Elles me servent à modifier les nuits en fonction du jours du mois... la nuit, c'est plus de 50% du temps, donc c'est non négligeable.
En pratique ça donne quoi... En fait, si vous avez bien regardez les screens je ne vous ai pas montré mon ton nocturne... car il est géré par la Gst Luz Lunaison que vous avez peut-être aperçu dans la liste. Comme pour le jour, il y a la version Rap et la version Prog, appelée par les Gst Luz correspondante. Ainsi une Gst est appelée par une autre, ça simplifie l'écriture car Gst Luz Lunaison ne s'occupe pas du tout des heures.
A l'intérieur, il y a des conditions sur les jours du mois, qui changent le ton, c'est bidon... Ce paragrache était juste pour montrer le potentiel du système de Gst, car je pense que vous êtes suffisament dégourdi pour la créer par vous-même. >>Inclus dans le système de la démo 2
Histoire de Calendrier
Le calendrier de cette démo est le calendrier Julien. L'actuel est Grégorien, la différence réside dans les années bissextiles: j'ai déclaré que les années bissextiles étaient multiples de 4... c'est pas faux, mais ce n'est pas complet: elles sont multiples de 4, de 400, mais pas de 100... Oui bon, j'ai eu la flème de tout tester... cela complique pas tant Fct Bissextile?, c'est surtout pour Fct Nbs J totaux? que je ne suis pas allé aussi loin dans la réalité.
Durée du jour en changement progressif
Il est possible de changer la durée du jour de + ou - une minute par jour... Nettement plus fin que par saisons. Par mois peut être un intermédiaire, cependant que se soit par mois, ou par jour, la mise à jour du Gst Tps passe de l'heure, à la minute près, ce qui fera ramer l'ordinateur autant... donc quitte à choisir autant prendre les jours... >>Inclus dans le système de la démo 2
Les temps spéciaux
Les temps spéciaux sont des temps rares, personnellement, je les met en aléatoire dans l'année. Les Eclipses, les Lunes rouges, sont des exemples simples et courants.
En réalité, je n'ai pas de vraies règles, et je n'ai pas envie de vous donner du tout cuit, car j'en déjà fait pas mal . Le principe est de les rajouter à la fin des Gst Tps et Luz, pour que les tons liés aux temps spéciaux écrasent les temps normaux, puis disparaissent à la prochaine MàJ, cependant il faut adapter pas mal de choses au niveau de la MàJ Luz/Mto pour ne pas la faire disparaitre en sortant d'une maison... Ces modifs sont spécifiques aux temps que vous créez c'est pourquoi je n'ai pas de régles, mais sachez que c'est faisable et pas si compliqué. >>Inclus dans le système de la démo 2
Météo... Ajoutez du sons à la pluie, à l'orage... c'est toujours plus vivant. Je n'ai pas essayé les fogs, mais pourrait être sympatique...
Astuces
N°1 Vous pouvez utiliser la boucle du temps pour actualiser des variables très souvent comme une variable contenant la position du joueur... C'est bidon, mais pour les tests dans d'autres événements ça peut être utile.
N°2 Pour inserer les variables dans les messages utilisez \V["id de la variable"] , vous pourrez créer des montres, des horloges, des calendriers... Des machines à remonter le Temps!! >>Inclus dans le système de la démo 1
N°3 Faire apparaitre un event en fonction du temps... c'est assez dangereux visuellement parlant mais c'est tellement plus cohérent. Il y a de multiples façons de faire, mais c'est pas simple de le faire proprement:
Utilisez un événement parallèle qui s'occupera de lui, placer-le en "invisible" et à la date t, mettez son opacité à 0, rendez le visible, et faites augmenter son opacité doucement, c'est chiant à faire mais ça évite les apparitions soudaines. C'est le même principe que le Soleil. Je ne conseille pas ce procédé pour les personnages, mais pour un papillon, c'est sympatique.
Pour les personnages, utilisez les portes... c'est le meilleur moyen d'être cohérent et d'éviter les boulettes. N'oubliez pas mes histoires de blocages et d'Init, ils me servent très régulièrement dans ma gestion des personnages... (exemple dans la démo)
>>Inclus dans le système de la démo 1
N°4 Accelérer et déccelérer le temps : Il suffit de mettre des conditions dans la boucle principale autour de Attendre X frames... ou mettez des variables aux limites... Visuellement, c'est plus joli que le saut temporel pour les petites durées de l'ordre de la nuit. >>Inclus dans le système de la démo 2
N°5 Adapter les maps en fonction des saisons : pas simple à faire... pour les petites maps récurrentes, en faire plusieurs peut être salvateur. Concernant la vraie adaptation, ça demande beaucoup d'events et une paire de procéssus parallèles pour orchestrer tout ça... personnellement j'ai pas encore tenté sérieusement. (dans la démo, les arbres est les touffes d'herbes s'adaptent... mais c'est pas du joli joli)
N°6 Obliger le joueur à dormir! : Oui afin d'être cohérant temporellement parlant, il serait normal que votre joueur dorme régulièrement, afin d'accéler le temps de manière logique et non négligeable. Un état de fatigue apparaissant toutes les X heures est facilement réalisable, bien sûr c'est à vous de raffiner l'idée...
Démo avec système relativement simple corrigée le 26/3/2009
Démo avec système plus avancé mais map à l'arrachée (-Durée du jour en fonction du jour, -Météo générée au mois, -Lunaison indépendante des mois, -6 tons differents par 24h [sauf si nouvelle lune], -Une éclipse par an, -Lune rousse de temps en temps à la place de la pleine lune,
si vous utilisez ce système sans modif, mon petit nom dans les crédits me ferait grand plaisir...)
Edit: maintenant un script analogue est dispo sur mon site: Ici
Dsl pour le multipost...
Dernière édition par vincentmhd le Lun 27 Juil 2009 - 17:43, édité 3 fois
julien
Habitant Lv.6
Age : 33 Inscrit le : 15/02/2009 Messages : 139
Sujet: Re: Système de temps interne au jeu [Complexe] Ven 27 Mar 2009 - 10:47
^^ Content de voir que tu a enfin poster le tuto Moi personnellement je vais pas l'utiliser vu que je ferais le mien moi meme , mais je le trouve complet ... très complet même !
Sylfurion
Mage Lv.11
Age : 27 Inscrit le : 02/03/2009 Messages : 513
Sujet: Re: Système de temps interne au jeu [Complexe] Dim 5 Avr 2009 - 13:25
O_o
exactement ce que je voulais, je te mettrai dans mes credits !!
merci ^^
Contenu sponsorisé
Sujet: Re: Système de temps interne au jeu [Complexe]