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 DataManagerLe 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 SceneManagerLe 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 BattleManagerUn 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.
Accueil 
Dernières images 
Sujet: RGSS2->RGSS3 Partie 1 : les Managers 
Dim 25 Déc 2011 - 0:11
?