BizzyBros

[Warrens]

[...](c'est pas optimum, mais bon ...).[...]

Pas Optimum ? Je trouve que tu sous-estimes les ordinateurs actuels, car c'est une fonction qui ne fait que parcourir un tableau de petite taille (pour ce que j'ai vu du jeu)... J'espère pour Cotsz que le tableau représentant les éléments de son niveau est un tableau d' entiers et non pas de strings/chaines de caractères, si c'est le cas (tableau de strings) on a un problème de performance et effectivement ma fonction (adapté alors aux strings) pompe beaucoup de temps processeur, car elle devra comparer plusieurs caractères pour une seule case.

[Rag'd]

Pas Optimum ? Je trouve que tu sous-estimes les ordinateurs actuels, car c'est une fonction qui ne fait que parcourir un tableau de petite taille (pour ce que j'ai vu du jeu)...

Haha, voilà une conversation intéressante sur la prog Je ne suis pas le dernier à me reposer sur la puissance des ordis actuels. En fait, l'optimisation à tout prix n'est pas mon kif. (je préfère une structure propre)
Effectivement, le tableau est probablement rapide à parcourir, mais répéter une boucle quand tu peux utiliser une variable à incrémenter (ou décrémenter selon), c'est juste que ça me gêne aux entournures malgré tout. (c'est pour ça que c'est une soluce temporaire pour moi)

[Warrens]

Haha, voilà une conversation intéressante sur la prog Je ne suis pas le dernier à me reposer sur la puissance des ordis actuels. En fait, l'optimisation à tout prix n'est pas mon kif. (je préfère une structure propre)
Effectivement, le tableau est probablement rapide à parcourir, mais répéter une boucle quand tu peux utiliser une variable à incrémenter (ou décrémenter selon), c'est juste que ça me gêne aux entournures malgré tout. (c'est pour ça que c'est une soluce temporaire pour moi)

Effectivement, le C et C++ (C# et python aussi je pense ) sont des langages multi paradigmes (= plusieurs façon de résoudre un même problème). Malgré tout ma fonction avec boucle ne sera parcourue que 16/17 fois si il y a 16 gold dans le niveau, et si on la compare aux boucles de rendu qui seront exécutées plusieurs centaines de fois (collage d' images à l' écran), il y a tout de même un abysse et ma fonction ne représente qu'un faible surcoût. Mais je note ta préférence pour l' incrémentation / décrémentation. Dans les programmes que je développe de mon côté, je fais néanmoins quelques optimisations qui ressemblent à celle posté plus haut (ce que je proposait à Cotsz). Par exemple tester les collisions entre différents éléments (briques + balles pour un casse-brique) seulement si la balle a bougé depuis le dernier test de collision, c'est un simple booléen (ex: bool ballesHasMoved si égal à true alors on lance le test de collision dans la fonction puis on fixe ce booléen à 'false' , booléen qui sera fixé à 'true' lors d'un prochain déplacement de la balle.

[Rag'd]

Effectivement, le C et C++ (C# et python aussi je pense ) sont des langages multi paradigmes (= plusieurs façon de résoudre un même problème).

Je programme en Python et en effet il est multi-paradigme (impératif, objet et même fonctionnelle alors que son créateur déteste ça - d'ailleurs il ne l'a pas fait optimiser). J'ai un peu perdu mes bases en C et aujourd'hui j'aurais un peu de mal avec les pointeurs.

Malgré tout ma fonction avec boucle ne sera parcourue que 16/17 fois si il y a 16 gold dans le niveau, et si on la compare aux boucles de rendu qui seront exécutées plusieurs centaines de fois (collage d' images à l' écran), il y a tout de même un abysse et ma fonction ne représente qu'un faible surcoût.

Tout à fait ok avec ça.

Mais je note ta préférence pour l' incrémentation / décrémentation.

C'est un formatage de formation informatique (belle allitération hein ) : quand on peut éviter les boucles, on les évite.

Dans les programmes que je développe de mon côté, je fais néanmoins quelques optimisations qui ressemblent à celle posté plus haut (ce que je proposait à Cotsz).Par exemple tester les collisions entre différents éléments (briques + balles pour un casse-brique) seulement si la balle a bougé depuis le dernier test de collision, c'est un simple booléen (ex: bool ballesHasMoved si égal à true alors on lance le test de collision dans la fonction puis on fixe ce booléen à 'false' , booléen qui sera fixé à 'true' lors d'un prochain déplacement de la balle.

Oui, ça semble bien. De toute façon, la gestion des collisions est tout un programme (c'est le cas de le dire ).

[Warrens]

C'est un formatage de formation informatique (belle allitération hein ) : quand on peut éviter les boucles, on les évite.

Tiens c'est la première fois que j'entends/lis ça! Au moins j'aurais appris quelque chose aujourd' hui.

Concernant les pointeurs en C, c'est un vrai problème pour les gérer et aujourd'hui je programme principalement en C++ et je les évite grâce au RAII / RFID du C++, même si on peut utiliser les pointeurs en C++, mais c'est une mauvaise pratique (mais j'ai un petit projet style "trouver des pairs de cartes retournées coté dos" écrit en C car j'aime bien le C malgré le problème des pointeurs, son apprentissage était très plaisant).

[Rag'd]

Je me repose sur le ramasse-miettes de Python (même si le risque d'un infime temps de blocage me pose toujours des questions). note au passage : dispositif inventer pour Lisp, un pur langage en fonctionnelle.
En fait, j'aime quand le langage s'occupe du maximum de choses. Il y a une maxime bien connue chez les informaticiens.

Un bon informaticien est un informaticien fainéant.

[Cotsz]

Comme tu le dis c'est le genre de bug à s'arracher les cheveux.

Heu, oui... Tout as fait Thierry !!!

-créer une fonction retournant un booléen qui va parcourir tout le niveau en comptant les gold.

Oui, mais justement c'est le rôle de la fonction, que j'utilise dorénavent, fournie par les librairies unity:

GameObject[] Golds = GameObject.FindGameObjectsWithTag("Gold");
nombreDeGold = Golds.Length;

Voilà, donc je ne m'attend pas à recevoir une valeur fausse!
Pour le reste, c'est très intéressant mais c'est a peu près du même tonneau !
Unity est là pour faire une partie du boulot, alors je ne dois donc pas avoir à le faire à ça place !
Et justement, comme tout cela ce passe en calcule 'parallèle' (multi-core), il faut faire bien attention à ce que l'on fait
et ne pas ce lancer dans des calcule/procédure trop faramineuses.

Cotz, est-ce que tu utilises une programmation objet, impérative ? Tu es sûr de ne pas avoir un effet de bord quelque part dans ton code ?
Sinon, comme dit Warrens, refaire une boucle ... je propose une de comptage de Golds à chaque fois qu'on pille un peu de gold pour régler le prob temporairement (c'est pas optimum, mais bon ...).

Mon code est compilé au milieux de celui d'Unity, donc oui, j'utilise 'impérativement' la programmation objet !
Au début je comptai dans ma boucle. Chaque fois que je crée un "Gold" (enfin que ma boucle créée), j’ajoutai 1 au compteur, mais plus maintenant, donc.
Les gold sont décrémenter à chaque fois que Tom en "mange" une (c'est le code conseillé par les tuto),
mais j'ai donc moi aussi eu l'idée de les recompter à ce moment là, mais niveau consommation de ressources c'est pas le top,
et surtout ça posai le même genre de problème (erreur de total parfois aussi, mais ça ma mis la puce à l'oreille)

Effectivement, le C et C++ (C# et python aussi je pense ) sont des langages multi paradigmes (= plusieurs façon de résoudre un même problème).

Dans tout les langages (et même sans langage), il y as toujours de multiple façon de résoudre un même problème
C'est justement là, la beauté de la programmation, et ou l'on sépare l'ivraie du bon grain, certaines solutions son évidentes,
d'autres sont plus rapides et enfin d'autres consomme moins de mémoire; c'est là que le programmeur doit faire son choix!


Enfin,
je vous remercie TOUS pour votre support et votre implication, mais en fait c'est finalement Banedon qui avait raison !
(Comme quoi à partir de bases erronées, on peu aboutir à la bonne solution )

Le bug provient d'un "lag" entre mon code et le moteur de Unity. Comme je l'ai expliqué plus haut, les levels/niveaux sont crées plus ou moins complètement aléatoirement.
C'est du balbutiement de création procédurale, mais il arrive parfois que le level crée soit non viable: Pas de "Gold" ou pas de sortie.
Dans ces deux cas le "tableau" est donc detruit (Destroy("Board")) et on en recrée un nouveau. Le bug apparaissait justement dans un des deux cas.
Simplement pars-ce que lorsque je demander le comptage des "Gold" celles de l'ancien tableau n'étaient pas encore toutes détruites !

La solution adoptée (enfin peu être plus une rustine qu'un changement de pneu) à donc était de temporiser le recompte.
il y à donc désormais une temporisation après la création du level, et pour évitée d'autre 'bug' l'apparition de Tom ce fait aussi, maintenant, à ce moment là.
C'est pas très jolie sur les 2/3 premiers niveaux, mais c'est plutôt sympa ensuite...

Donc voilà, un bug, prise de choux, dû aux technologies actuelles (programmation objet & multitâches).
C'est donc bien là l’intérêt pour moi: "manger" de l’expérience dans un domaine de programmation ou je n'ai encore pas beaucoup fait mes preuves

Tous cela pour vous dire MERCI à TOUS, mais c'est bon, je suis passer par à peu près toutes les mêmes prises de tête que vous avez mentionnées,
mais grâce à quelques petits mouchards bien placés, j'ai finie par comprendre.

Je vais donc poster une petite version v0.416 avec ce correctif (et une modification du son qui creuse +credits +Unity5.4.1f1)
Petite pars-ce que j'avais prévu d'autre chose pour elle, mais bon... (10h de boulot pour une 'petite' version c'est déjà pas mal, même si c'est surtout que j'ai étais beaucoup dérangé au téléphone... mais bon...)


Voili, voilou.

Edit -------------------------------------

Un bon informaticien est un informaticien fainéant.

Ils ont volé cette devise aux programmeurs

Edit -------------------------------------

C'est un formatage de formation informatique (belle allitération hein ).

Le VRAi, le GRAND, le BEAU poëte () considère qu'il y à allitération à partir de x3!

Pas très en forme, c'est donc un formatage dû à ma formation informatique que je fit ce jour là.

à mince, à bah woui, avec informatique ça le faisait, à non, lol trop con, je suis!

[Rag'd]

Le bug provient d'un "lag" entre mon code et le moteur de Unity. Comme je l'ai expliqué plus haut, les levels/niveaux sont crées plus ou moins complètement aléatoirement.
C'est du balbutiement de création procédurale, mais il arrive parfois que le level crée soit non viable: Pas de "Gold" ou pas de sortie.
Dans ces deux cas le "tableau" est donc detruit (Destroy("Board")) et on en recrée un nouveau. Le bug apparaissait justement dans un des deux cas.
Simplement pars-ce que lorsque je demander le comptage des "Gold" celles de l'ancien tableau n'étaient pas encore toutes détruites !

Content que tu aies résolu ce problème. J'ai déjà vu cette difficulté de level non valide dans un code avec une génération procédurale de labyrinthe.
Peut-être qu'au lieu d'affecter un état au hasard tuile par tuile, tu pourrais affecter les golds en nombres nécessaires et aussi la sortie ... et toutes les tuiles spéciales dans ton tableau par coordonnées aléatoire et remplir le reste avec les tuiles terre.
Comme-ça tu pourrais éviter les niveaux invalides.

[Cotsz]

Peut-être qu'au lieu d'affecter un état au hasard tuile par tuile, tu pourrais affecter les golds en nombres nécessaires et aussi la sortie ...

Oui, mais il faut comprendre que j'ai étais au plus simple, la génération aléatoire n'est là que temporairement... En attendant l’éditeur de niveau.

[Rag'd]

Oui, mais il faut comprendre que j'ai étais au plus simple, la génération aléatoire n'est là que temporairement... En attendant l’éditeur de niveau.

Ah OK, bonne prog pour le reste alors

[Cotsz]

Et petite suggestion "sonore", le bruit quand on "creuse" et un peu 8bits ... non 2bits ... non 1 bip
Aurais-tu quelque chose d'un peu plus "gaming" dans tes ressources ?

Oui donc woilà, petite modification "sonore" sur la v0.416, ça donne peu être plus l'idée de creuser maintenant...
Ou de découper des "Rice Krispies" avec une paires de ciseaux !!!!
Enfin, bon... J'ai essayer d'éviter l'ennui de ce son répétitif par une varation aléatoire du pitch...
Tu trouve ça mieux ?
Vous trouvez ça mieux ???

Merci de vos réponses...

A woui... =================================> C'est ICI

[Rag'd]

Oui, c'est bizarre ce son Krisples.
Je ne sais pas quel outil tu utilises, mais de mon côté, pour mon projet, j'ai enregistré des sons avec mon smartphone et je les ai retravaillés avec Audacity qui est vraiment pas mal.