AccueilAccueil  PortailPortail  FAQFAQ  RechercherRechercher  MembresMembres  GroupesGroupes  S'enregistrerS'enregistrer  ConnexionConnexion  




Partagez | 
 

 RGSS2->RGSS3 Partie 1 : les Managers

Voir le sujet précédent Voir le sujet suivant Aller en bas 
AuteurMessage
Illusionniste Lv.12
Illusionniste Lv.12
avatar


Masculin Age : 27
Inscrit le : 14/02/2010
Messages : 796

MessageSujet: RGSS2->RGSS3 Partie 1 : les Managers   Dim 25 Déc 2011 - 0:11

Les "Managers"


J'espère pouvoir réaliser une série de tutos à l'intention du maker déjà familier avec le rgss2, et qui veut passer au rgss3.
Je vais commencer cette série avec les 3 "Managers", des modules qui viennent s'ajouter aux déjà existants "Vocab", "Sound" et "Cache".
3 nouveaux modules, DataManager, SceneManager et BattleManager. A quoi servent ils et comment les utiliser ?


Le DataManager

Le Data_Manager s'occupe de l'extraction et de la sauvegarde des données, c'est donc en quelque sorte un reprise du Scene_File (laquelle existe encore, mais comme on le verra après, elle ne s'occupe plus que de mettre en place les Window et est parente de deux nouvelles scènes, Scene_Save et Scene_Load). Les fonctions ont une apparence similaire, on notera quand même :

-> Une classe Game_System a été créée et contient toutes les petites infos du genre last_BGM, last_BGS, le nombre de sauvegardes, le temps de jeu, des marqueurs qui indiquent si le menu/le menu sauvegarde sont désactivés, etc... ces infos sont donc contenues dans le $game_system pour les fonctions d'extractions et de sauvegarde, et dans $data_system pour le chargement de début de jeu (et à ce propos, la nouvelle Scene_Title utilise donc le Data_Manager pour charger les données en cas de nouvelle partie).

-> Apparition du mot-clé rescue, qui permet de gérer les exceptions ; voici son utilisation :
Code:
def method( args )
    begin
  # ... code normal ...
    rescue
  # ... que faire en cas d'erreur ...
    retry # facultatif, permet de recommencer à "begin"
  end
end
Lien vers la doc Ruby
Ce qui donne, dans le rgss3 :
Code:
  def self.save_game(index)
    begin
      save_game_without_rescue(index)
    rescue
      delete_save_file(index)
      false
    end
  end

  def self.save_game_without_rescue(index)
    File.open(make_filename(index), "wb") do |file|
      $game_system.on_before_save
      Marshal.dump(make_save_header, file)
      Marshal.dump(make_save_contents, file)
      @last_savefile_index = index
    end
    return true
  end

  def self.delete_save_file(index)
    File.delete(make_filename(index)) rescue nil
  end
Ce qui signifie : quand j'applique la méthode save_game(index), je lance la méthode save_game_without_rescue(index), et si jamais on n'arrive pas à réaliser correctement cette méthode, alors à la place d'avoir un plantage et une sortie de jeu, on applique la méthode delete_save_file(index) puis on renvoie "false" comme sortie (ce qui permet par la suite de voir si la sauvegarde s'est effectuée correctement).

Le reste du DataManager ressemble au contenu de la Scene_File qu'on trouve dans le rgss2.


Le SceneManager

Le SceneManager est entièrement nouveau, et aborde les passages d'une scène à l'autre. Dans le rgss2, lorsqu'on veut changer de scène, on indique simplement quelle est la prochaine scène et on oublie celle en cours. Dans le rgss3, c'est un peu différent, il est possible de se souvenir des scènes précédentes, et ainsi d'imbriquer les scènes entre elles.
Avant de rentrer dans les explications, je vais commencer par expliquer une nouvelle méthode tirée de ruby et utilisée dans le rgss3 : pop.

Elle s'applique à un vecteur. (My_vector.pop(n))
Par défaut, n=1 : My_vector.pop équivaut à My_vector.pop(1)
Effet : Supprime les n derniers éléments du vecteur et les renvoie. Si le vecteur est vide (=nil), renvoie nil. Si le vecteur contient moins de n éléments, il les renvoie tous.
Exemple :
Code:
a = [ "a", "b", "c", "d" ]
a.pop    #=> "d"
a.pop(2)  #=> ["b", "c"]
a        #=> ["a"] #le vecteur initial ne contient plus que "a"

Je repasse au SceneManager. Celui-ci possède 3 attributs, @scene qui contient la scène courante, @background_bitmap qui contient l'image d'arrière plan (par exemple, la carte en plus terne et foncé lorsqu'on est sur le menu), et @stack. @stack est un array qui contient toutes les scènes précédentes dont on se "souvient". Je ne serai clair qu'avec un exemple.

Exemple :
-> Je suis sur la carte, mon bonhomme bouge : Je suis dans Scene_Map, le stack est égal à [], on a aucune scène en mémoire.
-> J'appuie sur échap, je passe dans le menu (script Scene_Map, ligne 188) ; alors nous avons le code SceneManager.call(Scene_Menu), lequel modifie le stack, qui devient ["Scene_Map"] (Scene_Map est donc mémorisé) et envoie au menu.
-> Je rentre dans l'onglet Objets (Scene_Menu, ligne 48) ; même chose, le stack devient ["Scene_Map", "Scene_Menu"] et la Scene_Item se déclenche.
-> Je reviens dans le Menu, en appuyant sur Annuler (Scene_Item, ligne 26) : la méthode return réalise en fait l'action SceneManager.stack.pop, c'est à dire, regardez plus haut si vous avez oublié, qu'on supprime le dernier élément de stack (stack redevient alors ["Scene_Map"]), mais l'argument renvoyé est "Scene_Menu" (l'élément retiré), ce qui permet de revenir dans le menu. Je redonnerai les détails en parlant des Window.

L'idée générale à retenir est que lorsqu'on passe d'une scène à l'autre, on stocke la première pour savoir où on va retomber en sortant de la suivante. Cela implique des méthodes un peu différentes de celles rencontrées dans le rgss2 :

SceneManager.call(Nom_de_la_Scene) permet de déclencher une nouvelle scène en mémorisant l'actuelle dans le stack.
SceneManager.exit permet de sortir du logiciel ; en effet, la fonction main (qui est toujours en dessous des autres codes) est juste un démarrage du SceneManager (méthode run, SceneManager ligne 18)
SceneManager.goto(Nom_de_la_Scene) permet de passer à une nouvelle scène sans mémoriser la précédente. Dans le rgss3, c'est utilisé pour quitter la Scene_Title sans la rentrer dans le stack. En principe, cette méthode n'est à utiliser que lorsque vous allez vers une scène qui ne permet pas de retour en arrière, comme c'est le cas pour le titre.
SceneManager.return permet de revenir à la scène précédente (par exemple, pour revenir du menu sur la carte, ou du menu d'équipement au menu global)

Pas grand chose à ajouter sur le SceneManager. Ah, si, vous avez repéré la méthode use_midi? et vous vous demandez à quoi ça sert. Comme vous avez du voir dans les rtps de Ace, les musiques sont désormais en .ogg (ce qui explique que les rtps soient si lourds, au passage), et donc le format .mid n'est plus obligatoire.
Or, si le format .mid est aussi léger, c'est en fait parce qu'il ne contient que la partition du morceau qui doit être joué, et que c'est au support de le traduire en son. Débloquer une bonne qualité de son avec du midi nécessite donc de la mémoire vive, et c'est pourquoi on a ajouté cette méthode use_midi?, qui détermine si la musique actuelle est sous format midi, pour optimiser la lecture du midi seulement quand la musique en cours est effectivement sous format midi.

Le BattleManager

Un gros titre pour pas grand chose, le BattleManager est simplement un module qui contient la moitié de la Scene_Battle du rgss2 (celle ci s'en retrouve très allégée dans le rgss3, vu qu'elle ne contient plus que la gestion des fenêtres et des commandes très larges telles que initialize, update, terminate, les sélections, etc...) En résumé, le BattleManager a été créé pour rendre la Scene_Battle plus lisible en la transformant en code de structure pur, c'est tout ce qu'il y a à dire.

Il s'agit donc d'un gros foire à tout. On y trouvera la gestion du son pendant le combat, les actions réalisées à la fin du combat (gain d'objets, exp, fuite, combat perdu etc...), les tests de début de combat (attaque surprise), des méthodes relatives au nombre de combattants (vous le savez, on peux avoir plus de 4 héros dans le menu, mais un nombre limité de héros peut combattre : il faut donc penser à limiter les actions possibles aux combattants uniquement) et une méthode pour distribuer l'ordre des actions réalisées selon la vitesse (agi) des combattants et des monstres.


Voilà, tuto fini !
La prochaine fois, j'espère bientôt, un petit point sur les nouveautés des Window.

_________________


Merci à Kouett pour :
Spoiler:
 


Dernière édition par Tiroflan le Lun 26 Déc 2011 - 14:50, édité 5 fois
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
+ Heir Øf Ŧime +
+ Heir Øf Ŧime +
avatar


Masculin Age : 26
Inscrit le : 27/06/2008
Messages : 10881

MessageSujet: Re: RGSS2->RGSS3 Partie 1 : les Managers   Lun 26 Déc 2011 - 12:19

Bonjour,

Déjà, haha, je suis une buche en script ( je pense que c'est pareil pour les autres, à l'heure actuelle ) donc je vais devoir te faire confiance sur le contenu O/ ( tes petits camarades scripteurs commenteront sans doute s'ils ont des ajouts ou autres ).

Niveau structure et clarté, rien à dire, ça m'a l'air d'un très bon tuto ( si même moi je comprends plus ou moins ce que tu dis, c'est dire ... ).

Tuto validé, +3 points de participation, merci à toi !

_________________
♦Supporter officiel de Flavii3n♦
Time On My Side
Trailer ♑ Présentation ♑ Télécharger


Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Maître des Duels
Maître des Duels
avatar


Masculin Age : 25
Inscrit le : 29/07/2009
Messages : 7838

MessageSujet: Re: RGSS2->RGSS3 Partie 1 : les Managers   Lun 26 Déc 2011 - 12:47

Bien trop fouilli à mon gout.

Tu mélanges les notions RGSS3 avec les notions de base en programation.

Je n'ai pas encore touché RGSS3, je pensais obtenir une explication viable mais je ne comprends toujours pas réellement ce que sont les managers en lisant ton tuto.

Tu parle de Managers qui s'ajoutent à Vocab, Cache et Sound sauf que ces modules... n'ont aucune raison de s'apeller manager (sous VX en tout cas) étant donné qu'ils ne contiennent que des "raccourcis" ou des éléments texte préfaits.

Ensuite, tu illustre l'opérateur ternaire, le "pop" de l'array (car c'est un array en ruby et non un vecteur =[ ) ou encore le rescue. Le problème, c'est que ce sont des notions de programation ruby de base et non en rapport avec les managers. Donc c'est du surplus inutile et parasite.

Tu confonds également les termes, argument au lieu d'attribut, erreur au lieu d'exeption. Ce sont des détails mais ils sont très important étant donné qu'ils risque de prêter à confusion si tous sont utilisés n'importe comment.

En somme, si on retire les passages parasites, les inversions de mots, on se retrouve avec un survol de ce que tu es censé nous expliquer. Ce qui est dommage pour les gens qui seraient réellement interessés par ce nouveau mécanisme.

Bref, tuto à améliorer.

_________________
Gimme a hell yeah.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Illusionniste Lv.12
Illusionniste Lv.12
avatar


Masculin Age : 27
Inscrit le : 14/02/2010
Messages : 796

MessageSujet: Re: RGSS2->RGSS3 Partie 1 : les Managers   Lun 26 Déc 2011 - 13:41

En fait, la série de tutos vise à passer vite de rgss2 à rgss3, avec le code sous les yeux (c'est pour ça que je donne les références sur les lignes, mais je vais préciser). Donc le but ici, c'est juste d'avoir un aperçu des nouveautés et de comment est pensé le rgss3, d'où le besoin d'expliquer les nouvelles formes de programmation (rescue, pop, A ? B : C) pour avoir une lecture facilitée du rgss3.

Bon, les termes que je confond, ok. Mais je ne les connais pas, n'ayant pas de formation en programmation. "Array" donne "tableau" en français, et j'assume "vecteur" puisque c'est à une dimension. Je corrige pour arguments et attributs aussi, c'est vrai que c'est différent. Je ne vois pas comment on peut se planter entre erreur et exception, par contre. Ah, et les managers s'appellent juste comme ça dans le rgss3, même si ça ne reste que des modules, je ne savais pas que ça pouvait signifier autre chose.

Même sans les codes sous le nez, je pense quand même que tu as pigé ce qu'on trouve dans ces nouveaux modules, et leur logique ?
C'est le seul but du tuto.

_________________


Merci à Kouett pour :
Spoiler:
 
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Citadin Lv.7
Citadin Lv.7
avatar


Masculin Inscrit le : 15/03/2011
Messages : 167

MessageSujet: Re: RGSS2->RGSS3 Partie 1 : les Managers   Lun 26 Déc 2011 - 14:02

Citation :
Je ne vois pas comment on peut se planter entre erreur et exception
Ce n'est pas du tout la même chose.

Pour vecteur, ce n'est pas dramatique, même si le terme tableau est plus adéquat parce que
Code:
(Array.new) << ((Array.new) << Array.new)) << 6
C'est toujours un vecteur Razz ?

pop, on s'en fiche... c'est juste une méthode ...
Sinon, c'est pas mal.

_________________
XHTML's the true way !
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://funkywork.blogspot.com/
Illusionniste Lv.12
Illusionniste Lv.12
avatar


Masculin Age : 27
Inscrit le : 14/02/2010
Messages : 796

MessageSujet: Re: RGSS2->RGSS3 Partie 1 : les Managers   Lun 26 Déc 2011 - 14:09

Bon, je vais modifier alors erreur et exception n_n. Mais tu peux m'expliquer, juste, vu que j'aime pas trop modifier dans le vide ?

Pour les nouvelles méthodes... oui, c'est vrai que ça aide pas du tout à piger une logique. Si je les ai mis, c'est juste parce que j'ai du aller chercher ce qu'elles faisaient pour comprendre le code et que pour moi, c'était nécessaire de les mettre pour avoir une lecture fluide des codes avec le tuto.

Merci à vous deux !

Edit : Oh, Zang, pour le fouillis, t'as raison, mais c'est vraiment parce que ces trois modules sont eux même très différents, et je ne pouvais pas donner une structure bien carrée au tuto à cause de ça. Il y aura certainement plus de contenu dans le tuto sur les Window, et la structure sera beaucoup plus nécessaire.

_________________


Merci à Kouett pour :
Spoiler:
 
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Citadin Lv.7
Citadin Lv.7
avatar


Masculin Inscrit le : 15/03/2011
Messages : 167

MessageSujet: Re: RGSS2->RGSS3 Partie 1 : les Managers   Lun 26 Déc 2011 - 14:25

Une exception est une manière de traiter un cas "exceptionnel" qui n'est pas forcément une erreur. Mais les deux sont propageables.

_________________
XHTML's the true way !
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://funkywork.blogspot.com/
Maître des Duels
Maître des Duels
avatar


Masculin Age : 25
Inscrit le : 29/07/2009
Messages : 7838

MessageSujet: Re: RGSS2->RGSS3 Partie 1 : les Managers   Lun 26 Déc 2011 - 14:31

En fait pop fait partie de la logique des piles/files.
Si la personne ne l'a pas, c'est bien dommage pour elle mais le but du tuto n'est pas d'expliquer cela.

Même chose pour l'opérateur ternaire. C'est une notion importante oui mais parasite dans ce genre de tuto.

De plus, ce que tu dis par rapport aux managers me font penser qu'ils sont différents des modules que sont Vocab, Cache et Sound dans VX. C'est pour cela qu'il faut réelement expliquer le but final d'un manager.

_________________
Gimme a hell yeah.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur
Contenu sponsorisé




MessageSujet: Re: RGSS2->RGSS3 Partie 1 : les Managers   

Revenir en haut Aller en bas
 

RGSS2->RGSS3 Partie 1 : les Managers

Voir le sujet précédent Voir le sujet suivant Revenir en haut 
Page 1 sur 1

 Sujets similaires

-
» Quelle partie de votre cerveau utilisez-vous ?
» RPGMAKERVXACE! écran titre nouvelle partie ect...
» Supprimer une partie de trace
» Offre Ideo, résiliation de la partie internet
» Resiliation partie box sur forfait Ideo

Permission de ce forum:Vous ne pouvez pas répondre aux sujets dans ce forum
RPG Maker VX :: Entraide :: Tutoriels :: Tutoriels Vx Ace-
Créer un forum | © phpBB | Forum gratuit d'entraide | Signaler un abus | Forum gratuit