[WIP] Sheep ( un mouton pas si stupide)

[Alesk]

Les manipulations de strings en C# sont un peu moisies et consomment pas mal de ressources, alors que la lecture depuis un bitmap, ça va.
Mais bon, ça reste tout de même de l'ordre de la micro seconde

[EmileF]

Bon, j'essayerai ça sûrement un jour, histoire de ne pas mourir idiot, mais j'ai un peu de mal à me représenter ça en comparaison avec le système de données que j'ai utilisé pour CourtCircuit. Sachant que chaque case contient tout les éléments possibles et que je n'active que les éléments désirés.

D'ailleurs je me demande maintenant si c'est un bon procédé. Je poserai la question je ne sais pas où, on verra.

[djulio74]

Alesk,
En gros c'est bien ce que je pensais, tant que tu n’écrit/lit pas en continue dans un Update, ça passe.

Emile
oui ça doit commencer a faire beaucoup de GameObject dans la scène, même si peut sont actif. Mais c'est soit ça, soit jouer du instatiate/destroy... Ou alors opter pour ma solution de modifier les mesh quand tu édite ( et même en générant le niveau en debut de celui ci) , en regroupant les case du même type.


Bon j'ai pas trop avancé sur le jeux en lui même, juste totalement revu la partie éditeur, pour ce soit plus simple pour moi par la suite.
Par contre on ne peut pas jouer pour le moment, juste s'amuser à créer des niveaux.

Download "Seep, un mouton pas si stupide" (désolé fichier zip a l'ancienne^^)

Je vais maintenant pouvoir ajouter des éléments interractif.

[EmileF]

Ne sois pas désolé pour ton zip à l'ancienne comme tu dis, pour diffuser un jeu comme je le fait il me faut le buider en WebGL, ça dure facilement 5 mn, le compresser, ensuite supprimer l'ancien sur itch.io et téléchager le nouveau, et le lancer
En fait c'est plus facile pour le joueur mais c'est beaucoup plus galère pour l'émetteur.

Dans ma méthode, j'ai une grille de 15x15 cases et au moins en comptant les emptys prèt d'une cinquantaine d'objets dans chaque case. Mais en cours de jeu il y beaucoup moins de cases actives, et au maximum 5 ou 6 objets actif dans les cases les plus remplies. Ca ne fait pas grand chose d'actif en cours de jeu. Mais je ne sais pas ce que les inactifs peuvent occasionner en cours du jeu.

J'ai cherché la commodité, car je me voyais mal instancier à chaque fois les objets qu'ils fallaient et je pense qu'au niveau optimisation ce n'est pas le top, enfin je crois.

J'ai hâte de voir ton jeu avancer un peu, je suis curieux de vois ce que ça va donner. le fait que tu aies ajouté de l'eau me fait penser qu'il va y avoir des passages sur des passerelles ou des radeaux, çà peut ajouter un truc, alors ne traîne pas il y en a qui attendent lol.

a bientôt...

[djulio74]

Oui c'est vrai que ça a l'air bien plus galère pour toi ( je dirais pour l'instant), mais tellement plus plaisant pour le joueur.
Faudra je m'y penche a l'ocaz, mais m'obligerai a changer de version d'unity , ce qui n'est pas vraiment d'actualité pour moi pour l'instant. lol

Pour ta méthode, je ne sais pas non plus l'impacte que peux avoir autant de gameobject inactif, à part à première vu alourdir le projet ( et donc le build) en Mo.
Ton projet se prêterai cependant bien à un peu une même approche que moi :
- Je n'ai qu'un GameObject par type de case possible.
- une fois avoir lu mon image du niveau ( pour toi le texte), je modifie le mesh de chaque GameObject de base pour avoir l’apparence voulue du niveau.

Je peux avoir une grille de 50x50, je n'ai que quelques GameObject pour l'apparence. le reste est stoqué dans un array de struc, qui me sert pour les déplacement et toute autres actions.
Par exemple pour chercher les voisins d'une cellule, toi tu cherche si un GameObject est a une certaine distance dans 4 direction. Avec l'array, disons t'es en case n°30 sur un plateau de 15x15, tu aurais juste à tester les cases 30+15, 30-15, 30+1, 30-1 , pour voir si elles sont définies comme active dans ton struc.( sans avoir besoin qu'elles aient de gameObject).
En gros au lieu de tester a chaque fois TOUT les gameObject, tu sait déjà quelles cases sont a coté d'une autre avec leur index.

Mais tu as raison, souvent un peu barbare d'instancier/destroy de multiple GameObject.

Hé hé oui, l'eau amène de nouvelles possibilité que tu as très bien cerné. Mon mouton ne s'est pas encore noyé rassure toi mais j'ai encore revu le coté éditeur pour plus de facilité pour moi, et surtout bien luté pour qu'il soit flexible, pouvoir jouter des élément sans avoir a toucher au code : Juste ajouter un GameObject d'un nouveau type dans la scène, et tout seul au lancement du jeux il est ajouté dans les menu pour pouvoir être sélectionné et placé sur la map.. Astuce que j'ai cherché longtemps mais qui est assez efficace dans mon cas, je vais voir pour partager.

Enfin bon, tout ça pour dire j'ai pas franchement trop avancé, mais c'est pour pouvoir avancer plus vite par la suite.
Je ne manquerais pas de diffuser dès qu'il y aura des changement significatif.

[EmileF]

Par exemple pour chercher les voisins d'une cellule, toi tu cherche si un GameObject est a une certaine distance dans 4 direction. Avec l'array, disons t'es en case n°30 sur un plateau de 15x15, tu aurais juste à tester les cases 30+15, 30-15, 30+1, 30-1 , pour voir si elles sont définies comme active dans ton struc.( sans avoir besoin qu'elles aient de gameObject).

Mais, je peux le faire ça, j'ai une grille de 15*15 ou 16*16 je sais plus je peux utiliser cette méthode, et en plus que je connaissais. je ne sais pas pourquoi je n'y ai pas pensé, c'est un défaut chez moi, je cherche toujours ce qui est plus compliqué. "pourquoi faire simple quand on peut trouver plus dur". Surtout que dans la création de mes grilles, j'ai on booléan qui m'indique les "Cellules". Quel c... Bon allé tout doux Ca tourne et même plutôt pas mal.
D'ailleurs je suis à 20 niveaux et bientôt à 30, je suis content, ça avance.

Allez, salut à bientôt.

[djulio74]

Oui si ta méthode marche bien, pas forcément la peine d'en changer.
Juste par curiosité, quelle est la taille en Mo de ton build en standAlone?

De mon coté j'ai avancé un peu, ajout d'élément mobile actionné par interrupteur ( comme suggéré par Émile).
J'en ai fait que 4 niveaux juste pour voir ce que ça donne, et déjà ça ouvre de nouvelles possibilités.

Download "Seep, un mouton pas si stupide"

qu'en pensez vous?
Des idées pour d'autres interactions à ajouter?

[Deceleris]

Mec, j'ai essayé ton jeux, franchement j'me suis dit "Wow c'est génial !"

ça a énormément de potentiel, t'a eu une super idée.

Puis c'est typiquement le genre de jeu ou même avec des graphiques pas ouf tu t'éclates, le seul conseil que je peut te donner c'est continues comme ça x)

[Alesk]

Yo !

Ces interrupteurs sont bien sympa, par contre ça peut vite devenir compliqué de se souvenir quel interrupteur actionne quels murs.
Peut-être que mettre un code couleur serait judicieux (inter rouge / mur rouges, inter bleu / murs bleus, etc....)

Pour complexifier un poil plus, tu pourrais ajouter un autre type de bloc, avec des flèches inscrites dessus.
Lorsque le mouton tape contre l'un de ces blocs, il se dirige alors aussitôt dans le sens de la flèche.

[EmileF]

Juste par curiosité, quelle est la taille en Mo de ton build en standAlone?

J'ai relevé la taille du dossier comprenant tout jeu+data 34 mo le jeu 21 mo. Ca fait beaucoup?

J'ai essayé ton jeu, super
ça prend tournure et c'est très intéressant.
Juste une petite question est-ce que le fait de s’arrêter sur un interrupteur ne serait pas suffisant, sans avoir besoin de presser la touche espace?
Je suis assez fainéant sur les bords..

J'ai pas d'idée nouvelle pour le moment mais si j'en ai une...

Super continue...