Aller au contenu


- - - - -

Le Test Avant Envoi


  • Veuillez vous connecter pour répondre
3 réponses à ce sujet

#1 Elenwel

Elenwel

    Granny Smith Wiwi


Posté 27 avril 2011 - 14:56

Le test avant envoi...
Pour une mise en ligne dans la joie et l'allégresse.

Alors  ça  y est? Après quelques mois de souffrance dans les méandres  infernales  du tescs ou du geck vous voici arrivé à l'achèvement de ce  long chemin :  votre module est fini. Et vous avez choisi de l'envoyer à  la B.A.L de  wiwiland, le confiant aux petites mains calleuses des  testeurs  (testeurs au sens général, nous n'effectuerons aucune  discrimination  entre couleurs). Bravo  et merci, c'est grâce à votre  travail que la  communauté  continue d'avancer.

Comme vous le  savez surement,  tout module mis en ligne sur les sites de publications  de wiwiland se  doit d'être testé, afin de garantir une qualité minimale  et de pouvoir  assurer aux joueurs que votre travail  ne détruira pas sa  sauvegarde,  ou sans dramatiser, qu'il y aura le moins de bugs gênants  possible.  Mais les plus anciens le confirmeront sans aucun doute, un  test, c'est  long. C'est pour cela que nous avons mis au point les  tests  communautaires, qui vous offrent la possibilité de permettre à  tout les  wiwilandais de jouer à un module alors même que celui-ci est  en  test, tout en pouvant contribuer à son amélioration en faisant  remonter  les bugs.

Mais, car il y en a toujours un, nous  souhaitons tout  de même garantir une qualité minimale, même si votre  module n'a pas été  testé. Oh je suis sur que pour vous tout ira bien,  mais  nous en avons vu des bugs ma pomme et moi, des bugs bloquants,  des  créations abracadabrantesques envoyant tout ou parti d'Oblivion  dans les  limbes. Et... Nous étions parfois, souvent même, les auteurs  de ces  modules déviants...  C'est pourquoi un petit pré-test sera  effectué  avant la mise en test de votre module, que le test soit  communautaire ou  privé. Durant ce pré-test, un testeur vérifiera les  points suivant de votre module:

Citation

  • Que  votre  module respecte les critères de notre charte, à savoir :  un  contenu  adapté à tous et à tout âge et respectant les lois  françaises.  Ce qui  exclue la pornographie, les modules visant à  traduire une VO en  VF,  les modules redistribuant du contenu de DLC ou  d'extension, etc. En cas  de doute sur ce point vous pouvez nous  contacter sur Confidence, avant  de soumettre votre module.

SUR CE DERNIER POINT ET CE POINT SEULEMENT : SI VOTRE MODULE NE CORRESPOND PAS A CES CRITÈRES SONT REFUS SERA DÉFINITIF. VOUS NE POURREZ PAS LE RE PROPOSER A LA B.A.L, SAUF AUTORISATION PARTICULIÈRE.

  • Que l'archive est complète et respecte les critères tels qu'énoncés dans le sujet Envoi de votre module
  • Que le sujet de la B.A.L contient bien des images (de 1 à 4) illustrant votre module, ainsi qu'une description de votre module.
  • Que  le  module en lui même soit propre. Nous entendons par là que votre  module  n'introduit en jeu que des fonctionnalités (factions, NPCs,  objets,  scripts, cellules) souhaitées et surtout qu'il n'y ait pas  de  modifications inutiles des données du jeu.
  • Et qu'il respecte  la  wiwinormae pour morrowind. Pour Oblivion et Fallout, nous vous  demandons  juste de faire un effort en nommant vos objets, que l'ID  correspondent  bien à la fonction de l'objet (Une chaise ne devrait pas  avoir pour ID :  EL_tutu_rose)
Si un de ces différents points  n'est pas  respecté, le testeur en charge du pré-test vous contactera  sur le sujet  de la B.A.L et vous fera parvenir un rapport et des  conseils vous  permettant de corriger au mieux votre module. Celui-ci  devra ensuite  être renvoyé puis re-soumis à un pré-test avant mise en  test  communautaire ou privé.
  • Enfin un  premier tour du module  rapide en jeu sera effectué afin de détecter un  éventuel bug bloquant.  Ce test en jeu est laissé à la discrétion du  testeur référant et pourra  aboutir à une première fournée de tickets de  bug.
    • Ce petit  test en jeu pourra être accompagné,  dans certain cas, d'une rapide  lecture des scripts de votre module,  afin de détecter au plus tôt  quelques bugs graves pouvant découler de  fonctions buggées.
Pfiouuu...  Comme je  le disais, c'est pas super amusant. Mais c'est ce document qui  sera  utilisé en interne pour les pré-test.  Ce qui vous  permet  de vous préparer Image IPB  Et nous pouvons enfin  rentrer dans le vif du sujet : comment vérifier  que votre module  correspond aux points les plus techniques?

Ces  quelques petites  vérifications vous permettront d'économiser pas mal  d'aller-retour de  correction et donc d'accélérer la publication de  votre module.

Test et nettoyage sur :
Morrowind
Oblivion
Fallout
Skyrim
Test en jeu : ce qu'il faut vérifier

Modifié par Talia Ochemaure, 23 juillet 2017 - 15:01.
Mise à jour des liens vers le wiwiki

Voir le messageD.A.D., le 29 avril 2013 - 21:21, dit :

Un avertissement d'Elenwel, c'est un avertissement qui en vaut deux : si tu n'en tiens pas compte, c'est toujours pour TA pomme, et en général, il ne fait pas de quartier. Mieux vaut éviter les pépins, ça empêche d'y laisser sa peau.

#2 Phant

Phant

    Plus pro, plus propre !


Posté 02 mai 2011 - 20:14

Test en jeu :

J'aimerais, avant même de commencer ce petit guide vous citer le concept fondamental d'un test :

Citation

Tester n'est pas jouer.




C'est même le contraire :D  Vous n'avez pas forcément besoin de grande connaissance technique pour  tester un module, ni d'être un expert dans le Lore de Cyrodiil, ni même  d'être un maitre linguiste, connaissant le français et ses subtilités  sur le bout de ses doigts. Un bon testeur est, à mon avis, quelqu'un qui  ne joue pas au module qu'il test. Quelqu'un qui par exemple ne va pas  suivre la quête, ou va essayer de la résoudre autrement. Quelqu'un de  brutal qui tue tout les NPCs qu'il croise. Quelqu'un qui en fait se pose  continuellement deux questions :


"-Et si je fais ça, il se passe quoi?"
Et surtout :
"-Pourquoi?"

Le deuxième point qui est assez important :

Citation

Le testeur et le modeur devraient être deux personnes différentes

Je ne veux pas dire que vous ne devez pas tester vos propre module, mais  on a tendance face à sa création à être le nez dans le guidon. En tout  cas, je suis totalement incapable de tester ce que je fais. C'est  pourquoi aucun colorié ne test son module. Il y a une raison d'équité,  c'est normal, mais c'est aussi pour garantir que le test sera bien fait.  Nous vous conseillons donc de rechercher des bêta testeurs parmi vos  amis ou parmi les membres du forum. Ce qui n'empêche que vous pouvez  effectuer certaine vérification seul, en étant rigoureux.

Voici une liste non exhaustive des problèmes que nous rencontrons les  plus fréquemment en jeu. Bien sur cela exclu la propreté du module. Mais  celui ci devrait déjà être nickel :)

  • Les statics(en intérieur) :
    • si  vous avez fait des donjons, ou des interior nécessitant plus de deux  statics, il arrive fréquemment qu'il y ai une petite fissure à la  jointure. Cette fissure est bien souvent visible en jeu et peu être fort  désagréable. N'hésitez donc pas à bien raser les murs de vos donjon et à  les parcourir en tout sens plusieurs fois.
    • De même prêter  attention aux ombres incluses dans les meshs (sur  Oblivion, les set  ayléides notamment) : les ombres peuvent donner l'impression de flotter  au dessus du sol ou au contraire, si elle sont trop enfoncé, donne un  côté scintillant très désagréable.
    • Enfin veiller à ce que le  joueur ne puisse se bloquer dans un recoin, même en sautant d'un balcon  ou autres situation que vous jugez improbables. (Note: certain modeur  prévois de temps à autre des pièges, petites zone sans issue qui assure  normalement au joueur une mort certaine. Attention, certains jouent en  god mod, si vous voulez tuer le joueur assurer vous de le faire même  dans ce cas)
  • Les statics (en extérieur):
    • Comme  pour les extérieurs, prenez le temps de vérifier que chaque statics est  à sa place : cailloux flottant, arbre poussant à deux pieds au dessus  du sol, statics mal placé, dont la face interne est visible (ce qui  justement donne un mesh invisible sous certains angles)...
    • Pour  vos maisons, vos châteaux : vérifiez les portes. rien ne doit gêner son  ouverture, rien ne doit entrée en collision avec elle, et encore moins  la traverser, même les murs de la maison :)
    • Enfin  vérifiez que vos décors s'adapte au paysage. Un pont dont les piliers  ne touchent pas le sol est très facile à récupérer à l'aide de cailloux  cache misères. Pas besoin de modifier inutilement le landscape.
  • Les quêtes :
    • Si vos quêtes ont plusieurs embranchement, vérifié soigneusement chacune de ces voies.
    • Essayez  d'adopter un comportement absurde, illogique ou dangereux (en restant  raisonnable) peut-on provoquer une situation blocant votre quête?
    • Les messages du journal sont ils cohérents avec ce que vie le joueur?
  • Les NPcs souvent très liés aux quêtes:
    • Que se passe t'il si le joueur tue votre NPC?
  • Les dialogues :
    • Sont-il cohérents?
    • Peut  on aboutir à une situation que vous n'avez pas prévu (joueur d'une race  exotique ou ne remplissant pas les conditions requise pour vos  dialogues)?
    • Est-ce que tout vos NPCs ont au moins un greeting par défaut? (sur Oblivion)
  • Les armes, les armures, les objets pouvant être portés:
    • Pensez à vérifier le mesh au sol, celui que porte le joueur, la boîte de collision permettant de saisir l'objet
    • Ainsi que les icônes.
  • Les combats:
    • Si  pour faciliter le test vous utilisez tgm. Désactivez le durant vos  combats. Bien souvent un combat "un brin long et épique" en god mod  devient "un véritable cauchemar" pour un joueur n'utilisant pas les  codes.
  • etc... :D

"Dans la vie, rien n'est à craindre, tout est à comprendre."

#3 Spitoven

Spitoven

Posté 30 septembre 2012 - 19:17

Voir le messagePhant, le 02 mai 2011 - 20:14, dit :

Attention, certains jouent en  god mod, si vous voulez tuer le joueur assurer vous de le faire même  dans ce cas.

Je m'excuse, mais personnellement je n'appliquerai pas cette ligne. Quand on joue en god mod, c'est bien pour ne pas mourir, et c'est un souhait que je respecte. Les joueurs qui jouent en god mod le font généralement avec la console, avec laquelle un petit tcl suffit pour les tirer du moindre mauvais pas. D'ailleurs, pour l'avoir déjà vécu, mourir en god mod peut être particulièrement énervant. En outre...merci pour cette notice :)

Modifié par Spitoven, 30 septembre 2012 - 19:18.

Image IPB

#4 Elenwel

Elenwel

    Granny Smith Wiwi


Posté 01 octobre 2012 - 07:30

Certes, mais il y a aussi des cas où la mort fait parti intégrante du gameplay du mod. C'est le cas pour Fremleyan  (un mod Oblivion) par exemple, une partie des énigmes sont du "try and die", ça fait parti du module. Si un joueur ne mourrait pas lorsqu'il appuis sur le mauvais bouton, il perdrait une parti de l’intérêt du module et surtout il n'aurait plus aucune indication d'échec. Avec deux résultats type:
-Ce mod est tout moisi les énigmes sont nulles
-Faux report de bug ici ou ailleurs.

Il y a plein d'autre situation où la mort est nécessaire, n'en déplaise aux joueurs sous tgm (c'est mon cas ;) ). Quand on fait un test on essaye de respecter au mieux la volonté du modeur, d'où le conseil. Si l'on veut que le PJ meurt, il faut s'en assurer.

Voir le messageD.A.D., le 29 avril 2013 - 21:21, dit :

Un avertissement d'Elenwel, c'est un avertissement qui en vaut deux : si tu n'en tiens pas compte, c'est toujours pour TA pomme, et en général, il ne fait pas de quartier. Mieux vaut éviter les pépins, ça empêche d'y laisser sa peau.




0 utilisateur(s) li(sen)t ce sujet

0 membre(s), 0 invité(s), 0 utilisateur(s) anonyme(s)