[Résolu] Question d'éviter les bugs...

Bonjour, j'entend souvent parler de bugs un peu partout dans vos projets...

Je pense bien que un bug peut se manifester un peu partout..

Mais quel sont les choses sensibles au bugs...

Qu'est ce qu'on devrai eviter de faire dans la programation??,et pour quoi!?..

Quel sont vos propres astuces pour eviter certain bugs,...

si je demande ca c'est pour pas mettre de ''Attendre 0,1sec'' é toute les parties de programation;...quels sont les choses sensible??à eviter?

Merci s'avance et j'éspère que vous aurez compris la question...

Les 0,1 sont bien des fois mais certaines fois ça marche très bien sans.
Tu peux aussi tester des fois le wait 0,0 ! (encore plus invisible).


Sinon, il n'y a pas vraiment de secret...
Pour moi tu élimine le plus de bugs comme cela :


-Tester régulièrement le jeu par parties

-Tester chaque nouvelle chose à part puis au sein du jeu

-Tester le jeu en entier plusieurs fois

-Bien organiser sa prog pour s'y retrouver

-Utiliser un max de commentaires si la prog devient très dense

-Jouer au jeu plusieurs fois de plusieurs façons (pour imaginer tous les types de joueurs).

-Essayer de faire bugger votre jeu en faisant des choses
illogiques ou risquées.

-Noter sur une fiche les bugs trouvés lors des phases de test pour ne rien oublier. (Après une heure de jeu on peut avoir une liste de 20 bugs et on en oublie aucun comme ça !)

-Faire des tests de progs avant de se lancer réellement dedans au sein du jeu (comme ça c'est beaucoup plus simple à débugger et une fois le système niquel, il suffit de l'incorporer au jeu).

-Jamais se dire "le joueur fera pas cela donc pas besoin de vérifier". Il faut toujours tout vérifier.



Voilà ce qui me passe pas la tête...

Kwawa a écrit:

Mais quel sont les choses sensibles au bugs...

Un jeu linéaire, d'une durée de vie de 10 heures, avec 2000 switchs à gérer, 500 variables à gérer et environ... 50 commun events et blabla, ca peut causer bien des bugs si on ne test pas pendant de longs mois le projet sans cesse.

Des bugs, il y en aura toujours. Le plus important, c'est de corriger ceux qui empêchent de poursuivre le jeu, après tu corriges ceux qui pourraient faire coincer à vie le joueur, après on s'occupe des détails mineurs, sinon tu le fais tester par 10 joueurs différents, dont tu sépares en 10 parties le jeu et un tel va tester telle partie (mais cependant, les testeurs convaincants sont rares). Parfois on peut tricher avec la programmation, ce que je fais souvent, juste pour éviter de telles choses.

Bref, avoir des bugs dans un jeu, ça veut pas dire que le maker suce ou qu'il make comme un cave, mais c'est en raison d'une surcharge de travail et d'une accumulation de petites erreurs facilent à faire, soit en étant distrait, car on a trop de chose à penser ou soit on peut confondre des trucs... Bref, un jeu avec plusieurs bugs peut autant prouver un bon projet qu'un mauvais projet.

Tout dépend de ce que tu fais, les bug sont souvent causé par une erreur d'innatention ou la supression de fichier en pensant qu'il n'est pas utilisé.

M'enfin ya pas vraiment de bug qui reviennent plus que d'autres.

Peut-être appart RM-Tool qui suprimme parfois des fichiers utilisé... :/

Un manque de ressource n'est pas un bug, c'est juste un fichier qui manque à l'appel. Un bug, c'est plutôt en rapport avec le level design, le moteur et tout...

Évidement, sauf les grands makers de Oniromancie n'ont jamais de bugs dans leur jeu, car eux, ils sont de parfais dieux, mais ça, ce ne sont que des makers.. En revanche, les joueurs prévilegient le Gameplay, ce que les makers ne font pas habituellement. Il est donc évident que le Gameplay, ce qui est réellement jouable cause la majorité des bugs.

Sinon, je peux aussi expliquer le fait que l'on peut oublier d'enlever quelque chose. Ça m'est souvent arriver d'oublier d'enlever un évènement test ou un évènement qui a aucun rapport. Ça peut arriver aussi à de vrais jeux officiels.. Certains prévoyaient faire tels choses, mais à la dernière minute, ils pouvaient l'annuler, mais en oubliant peut-être une chose qui auraient dû enlever.

Un bug fréquent, c'est la précision de tous les switchs.. Genre, comme par exemple, il faut tuer 15 ennemis dans la salle pour que la porte s'ouvre. Donc, je programme si ennemi 1, 2, 3, 4, 5, 6, 7, 8, 8, 10, 11, 12, 13, 14 et 15 ON donc, ouvrez la porte. Par accident, je peux faire une petite erreur d'inattention de ce genre et c'est ainsi la raison pourquoi l'évènement marche pas, car au lieu de mettre 9, j'ai remis un 8 à la place.

Un autre, le foutu lag.. Sur un PC Celeron de 800 Mhz, carte vidéo 28 Mo et 192 de Mémoire, c'est facile de savoir si ça lag, mais sur un PC Pentium 4 de 3000 Mhz, carte vidéo 128 Mo et 512 de mémoire, là c'est moins simple, car rien lag... Tsé, t'essaye de faire une grosse énigme, mais ya les énervés avec leur PC de cul qui te chialent après à cause que ça lag... Tu as beau tenter, de regérer les images, minimiser le nombre de parallele processus, minimiser le nombre d'events, rendre le plus possible en call events, mais ya toujours le problème du lag. Les recherches sur RPG Maker 2003... que du temps, que du temps...

Mais bref, je dois dire que je suis plutôt positif devant un jeu avec des bugs, (peut-être pas buggé partout, mais je veux dire que l'on peut retrouver des bugs). Ça prouve malgré un beau potentiel du jeu, que le jeu n'est pas parfait. Un jeu parfait, c'est oniromancie, mais un jeu pas parfait, ce sont ceux qui peuvent avoir des choses intéressantes. Dans Donkey Kong 64, ce jeu est extraordinaire, mais il y a des bugs assez gros, comme aller sous l'île, rentrer dans la ruche avec Chunky bref... Les bugs font partis du projet et ils suffient d'en corriger le plus possible..

Edit: Y'a toujours deux choix... "Try to do better if you know or shup up."

Dark,l'optimisation existe dans tout programme,ya juste que toi,tu ne sais vraiment pas ce que cela veux dire.

Zquest n'en a pas besoin.

pour spz par exemple (car c'est le jeu le plus bourré d'évents que j'ai vu jusqu'ici je crois ^^)
En toute franchise, sur mon pc de salon qui est un AMD 3.8ghrz avec un g.o de ram et une carte 256mega, ça lag déjà un peu En meme temps vu le nombre d'évents par map pour un projet géré par Rm c'est tout à fait normal, je vois mal comment "optimiser" ça plus que ça ne l'est déjà :S

Maintenant c'est clair que si j'y joue avec mon portable de ~800Mhrz je risque de ne pas voir grand chose...

A moins de s'appeler Steve Wozniak, on ne peut pas penser à tout quand on programme quelque chose, donc comme le dit Relm, le meilleur moyen d'éviter les bugs, c'est de tester de fond en comble son projet et d'engager des bêta-testeurs. Le point de vue du développeur et rarement celui du joueur. Pensez à ce dernier comme un bon gros boulet de première qui fera tout ce qu'il peut pour faire foirer votre jeu et vous avez saisi l'idée... Blinder son projet de sécurités (exemple tester la valeur d'une variable avant de l'utiliser comme paramètre) permet le plus souvent d'éviter les bugs.
Maintenant, est-ce que c'est faisable sous RPG Maker sans lag...

C'est impossible sans lag sous Rm. Eviter les "bugs" c'est possible mais pour un jeu non-rpg qui demande beaucoup de ressources et de variables, d'évents et compagnie sous Rm...

C'est pas prévu pour à la base. Je rappelle que le R dans Rm c'est le diminutif de RPG... C'est pour créer des RPG's à la base Rm hein les gars :p C'est pas un outil de programmation, c'est un jouet... Enfin, moi je vois ça comme ça.

Je suis certaines que des jeux même comme SPZ peuvent ne pas lagger en fait... ou beaucoup moins.

Un exemple : ma prog et celle de Mex. J'ai été capable de souvent faire ce que je voulais comme sur Pokémon rainbow mais vu que RM est pas vraiment résistant aux pros denses et qu'il demande beaucoup à ton Pc en ressources (apparement oui lol) et bien le jeu laggait sur pas mal de Pc.

Mex par exemple, sait faire le même genre de chose mais ... sans le lag lol ! En tout cas quand je vois ses programmations c'est pas du tout comme les miennes.

Ce qui est important de savoir : on peut faire une chose d'une multitude de façon sous RM mais il y a toujours une façon qui demande moins au systèmle que les autres... On peut pas savoir comment RM ets programmé et ce qui lui demande plus de travail ou non. Des fois on pense faire la façon la plus clean et légère mais on se trompe parfois car il n'y a pas de façon de comprendre la logique du prog comme ça si facilement.

Si
C'est simple de faire de l'optimisation ^^'

On dois mettre le plus possible les parallele process dans les common event,ça pompe moins.

On dois utiliser le plus possible les call events
On dois utiliser le moins possible les parralele process,surtout dans les maps.(Dans le jeu de Dark,il dois y avoir au moins 3 parralele process par map qui pompe pas mal de puissance...)

Par contre,c'est vrai que quand ya 20 variable qui DOIVENT se regénéré à chaque 0,1 sec,c'est impossible que cela ne lag pas...(J'ai déjà eu ce problème...et...j'ai réussis a le contourner,sauf que cela a salloper le gameplay...

Ex : Une phase plateforme a la castlevania avec des ennemis et un fouet...)

ah oui,et pour savoir comment bien optimiser,toujours avoir un PC pourri avec soi.C'est vraiment utile...

De toute façon, je continue toujours mes recherches sur ce logiciel. Je me suis rendu compte que les 2 options qui peuvent souvent causer problème, ce sont "Move all" et "Stop all". Pour moi, ça me servait beaucoup, mais depuis quelques temps, je me suis rendu compte que ça ne sert qu'à bugguer un jeu, si on fait des combats A-RPG.

La programmation de la flèche est sans doute l'évènement le plus chiant à programmer. Pourquoi?

- De un, ça casse toute.. Impossible de passer sur les évents qui acceptent la superposition.
- De deux, il faut la mettre over the hero, car sinon elle passe pas sur les évènements à la même hauteur que le héros et sous le héros.
- Si on décide de mettre cet évènement en mouvement Slip Tro, elle passe à travers tous les endroits de la map et ça fait irréaliste.
- Faut faire des paralleles process pour tous les évènements que la flèche peut toucher en faisant un effet.
- Si on fait "Move all", la flèche a une chance sur 5 de bugguer si on exécute d'autres choses en même temps.

Fack les choses à faire, c'est gosser, gosser, puis gosser pour trouver des solutions pour éviter les bugs, (je parle pas du lag), mais de la gestion des évènements. Faut malheureusement penser à tout ce que le joueur pourrait faire...

Pour les bugs, ils suffis de faire bêta tester son jeu. ^^
Les autre trouvent toujours plus de bug que le créateur en général.

Astram, c'est pas simple de comprendre ce qui fait moins lagger le log à la base. Pour moi quand je vois que deux solutions simples marchent pareil je ne vois pas comment je pourrai savoir laquelle prend plus de ressources, tu vois ?

Pour les common event on est d'accord mais ca aurait pu etre le contraire... on a aucun moyen de savoir ce aui prend le plus de ressources sans faire plein de tests c'est ça le problème que je soulevais.

Relm a écrit:

-Tester régulièrement le jeu par parties

-Tester chaque nouvelle chose à part puis au sein du jeu

-Tester le jeu en entier plusieurs fois

-Bien organiser sa prog pour s'y retrouver

-Utiliser un max de commentaires si la prog devient très dense

-Jouer au jeu plusieurs fois de plusieurs façons (pour imaginer tous les types de joueurs).

-Essayer de faire bugger votre jeu en faisant des choses
illogiques ou risquées.

-Noter sur une fiche les bugs trouvés lors des phases de test pour ne rien oublier. (Après une heure de jeu on peut avoir une liste de 20 bugs et on en oublie aucun comme ça !)

-Faire des tests de progs avant de se lancer réellement dedans au sein du jeu (comme ça c'est beaucoup plus simple à débugger et une fois le système niquel, il suffit de l'incorporer au jeu).

-Jamais se dire "le joueur fera pas cela donc pas besoin de vérifier". Il faut toujours tout vérifier.

Mod a écrit:

A moins de s'appeler Steve Wozniak, on ne peut pas penser à tout quand on programme quelque chose, donc comme le dit Relm, le meilleur moyen d'éviter les bugs, c'est de tester de fond en comble son projet et d'engager des bêta-testeurs

Ouais jpense aussi comme ca, faut aller partout...et meme quand on est le créateur du jeu jtrouve que c'est plus pratique de chercher ces bugs la, t'essaye le lendemain quand ta un peu près oublié ce que ta fait; les ''beta-testeurs'' jtouve que c'est plus pratique pour la durée de vie, enfin c'est mon avis..plutot que demander à 10 personnes de tester ton jeu, mais c'est clair c'est pas mal par contre si 10 personnes differentes test les meme parties de jeu comme ca si 10 personnes trouve rien:c'est super!!
et Relm en tout cas merci pour la liste d'objectif: excellent!!!surtout la 7ème ligne:très pratique!,deja addict cette methode c'est un monstre gagne temps, surtout quand tu viens de mapper..
Et jvais accrocher cette liste sur mon moniteur, je fonctionne deja comme ca, mais la ca permettera de tout récapituler avant de se lancer dans une autre map: Merci Relm!`^^...

dark8744 a écrit:

Un jeu linéaire, d'une durée de vie de 10 heures, avec 2000 switchs à gérer

KoZzY a écrit:

C'est pour créer des RPG's à la base Rm hein les gars :p C'est pas un outil de programmation, c'est un jouet

dark8744 a écrit:

Un autre, le foutu lag.. Sur un PC Celeron de 800 Mhz, carte vidéo 28 Mo et 192 de Mémoire, c'est facile de savoir si ça lag, mais sur un PC Pentium 4 de 3000 Mhz, carte vidéo 128 Mo et 512 de mémoire, là c'est moins simple, car rien lag... Tsé, t'essaye de faire une grosse énigme, mais ya les énervés avec leur PC de cul qui te chialent après à cause que ça lag...

Astram a écrit:

ah oui,et pour savoir comment bien optimiser,toujours avoir un PC pourri avec soi.C'est vraiment utile...

Ouais j'ai meme pas besoin d'avoir un PC pourri pour ca: mon pc est pourri '^_^`!!
un pc ak 128mb de ram avec plein de trucs (mal) modifié pour à l'époque pouvoir un logiciel de 3d et des pleins de trucs que mon pc supportait pas..
Au final il plante tout le temps!!!la j'avais fait un commencement de a-rpg avec meme pas 2 ennemis pour tester avant de le mettre dans mon projet quoi, et donc: ca lag, ca lag grave!...
et ca fini par planter
bref; ca c'est plus une histoire de ram que de rm`^^
Tout ca pour dire que c'était meme pas un jeu avec 10'000 events commun, etc..

En tout les cas merci beaucoup pour toutes vos réponses!!

(Y'a pas à dire c'est un bon débat, en meme pas 1 jour: plus de 10 réponses!! merci à vous!!...et à E-magination!)

Ccd-Tof a écrit:

M'enfin ya pas vraiment de bug qui reviennent plus que d'autres

En résumé si je demandais ca c'est parce que j'ai cru que rm2k et rm2k3 était plus sensible au bugs ''d'ou on sait pas d'ou ils viennent'' que rmxp

Je trouvai que les gens faisait plus attention aux bugs dans leurs explications pour rm2k que rmxp, qui lui paraissait moins sensible aux bugs..

Mais la on dirait que c'est presque pareil, juste faire un peu plus gaffe peut etre, mais au début j'ai cru qui avait tout d'un coup des bugs qui arrivaient de ''on ne sait ou'' par exemple quand vous tester le jeu chez vous ya aucun prob sur un pont par exemple et quand le jeu est joué chez d'autre gens qui le télécharge; tout d'un coup le pont foire dans ses superpositions, qulque chose comme ca
Mais grace a vos réponses je pense pas que y'a ce genre de chose et encore moins: plus récurrent sur rm2k que rmxp...
enfin bref!...

Merci bcp de vos réponses ca fait super plaisir qu'aie autant de réponses quand on repasse le lendemain :-)

Merci à vous!

Citation :

En résumé si je demandais ca c'est parce que j'ai cru que rm2k et rm2k3 était plus sensible au bugs ''d'ou on sait pas d'ou ils viennent'' que rmxp

Ca existe sur les deux mais XP m'a vraiment refroidie à ce niveau avec Pokémon rainbow : il avait des bugs inexpliqués. Du genre, tu arrive dans un endroit et un switch se et en ON alors que le jeu vient de débuter... -__-
(Et je me connais assez pour savoir que ça ne venait pas de moi).

Sur 2K3 ça peut arriver aussi, j'ai vu cela si tu faisais des event trop dense avec plein d'étiquettes... il se mélange les pinceaux.