difsod -> Retour sur « Factory, Inc. » (GameJam #15) – Partie 2 sur 3
Articles similaires
2 réflexions au sujet de “difsod -> Retour sur « Factory, Inc. » (GameJam #15) – Partie 2 sur 3”
Je me rend compte que l’une des difficulté dans la création d’un jeu vidéo provient de la capacité à gérer toutes les variables / fonctions.
Actuellement j’essaie de faire une minuscule interface pour afficher un minuscule pathfinding et quelle galère 😉 La moindre erreur, et je suis en train de naviguer entre mes différentes fonctions qui utilisent mes différentes variables pour voir où peuvent se situer les erreurs 😉
En fait ce n’est pas tant le nombre de variables principales qui pose problème (j’en ai pas vraiment beaucoup dans mon minuscule projet), mais plutôt la profusion de variables intermédiaires pour faire les différents traitements qui rend la chose compliquée (à mon avis)
Et on est clairement pas aidé dans le debug avec lua car la fonction ‘print’ n’affiche pas le contenu des tables (et ça c’est juste super frustrant quand on vient comme moi d’un langage comme python ;(
Oui, la gestion des variables et des fonctions est un gros morceau dans la création d’un jeu. Et plus le jeu grossit, plus ça devient « lourd » à gérer, surtout quand on débute, comme moi, et qu’on ne sait pas encore utiliser certains « raccourcis » ou optimisations. Ça a tendance à devenir brouillon, et inutilement touffu. Pire : la moindre modification, même a priori anodine, devient de plus en plus délicate, si on ne veut pas « casser » tout ce qu’on a déjà mis en place. D’où l’intérêt (et la puissance) de la programmation objet, entre autres, mais je n’en suis pas encore là (en tout cas pas en Lua – mais j’y ai un peu touché en Java, déjà)…
Je suis un peu comme toi, le nombre de variables grossit rapidement, et ajoute au fur et à mesure de la complexité à des choses a priori simples, au départ. Je pense que c’est parce qu’on ne sait pas encore bien gérer tout ça, mais en y travaillant et en s’exerçant, on ne peut que progresser.
Quant à ce qui est du debug, je crois qu’avec la Pico-8 c’est encore moins pratique qu’avec le Lua « pur » (et à vrai dire, c’est aussi un peu de ma faute, car même si c’est faisable, j’avoue que je n’ai encore jamais utilisé le « print » dans la console, avec la Pico, et je me sers uniquement d’affichages dans l’écran du jeu, ce qui ne me facilite pas non plus la tâche…).
Pour ce qui est de l’affichage des tables, j’avoue que je ne suis pas sûr de bien comprendre de quoi tu parles. Il me semble qu’on peut les afficher, en Lua, en ayant recours à des boucles… En tout cas c’est ce que je fais, sous Pico-8. Mais je ne connais pas du tout Python, et c’est peut-être pour ça que je ne vois pas ce que tu veux dire exactement…
Bon, ça n’a rien à voir, mais la troisième (et dernière) partie de ce devlog arrive ce soir (mardi). A dans quelques heures, donc…
2 réflexions au sujet de “difsod -> Retour sur « Factory, Inc. » (GameJam #15) – Partie 2 sur 3”
Je me rend compte que l’une des difficulté dans la création d’un jeu vidéo provient de la capacité à gérer toutes les variables / fonctions.
Actuellement j’essaie de faire une minuscule interface pour afficher un minuscule pathfinding et quelle galère 😉 La moindre erreur, et je suis en train de naviguer entre mes différentes fonctions qui utilisent mes différentes variables pour voir où peuvent se situer les erreurs 😉
En fait ce n’est pas tant le nombre de variables principales qui pose problème (j’en ai pas vraiment beaucoup dans mon minuscule projet), mais plutôt la profusion de variables intermédiaires pour faire les différents traitements qui rend la chose compliquée (à mon avis)
Et on est clairement pas aidé dans le debug avec lua car la fonction ‘print’ n’affiche pas le contenu des tables (et ça c’est juste super frustrant quand on vient comme moi d’un langage comme python ;(
Oui, la gestion des variables et des fonctions est un gros morceau dans la création d’un jeu. Et plus le jeu grossit, plus ça devient « lourd » à gérer, surtout quand on débute, comme moi, et qu’on ne sait pas encore utiliser certains « raccourcis » ou optimisations. Ça a tendance à devenir brouillon, et inutilement touffu. Pire : la moindre modification, même a priori anodine, devient de plus en plus délicate, si on ne veut pas « casser » tout ce qu’on a déjà mis en place. D’où l’intérêt (et la puissance) de la programmation objet, entre autres, mais je n’en suis pas encore là (en tout cas pas en Lua – mais j’y ai un peu touché en Java, déjà)…
Je suis un peu comme toi, le nombre de variables grossit rapidement, et ajoute au fur et à mesure de la complexité à des choses a priori simples, au départ. Je pense que c’est parce qu’on ne sait pas encore bien gérer tout ça, mais en y travaillant et en s’exerçant, on ne peut que progresser.
Quant à ce qui est du debug, je crois qu’avec la Pico-8 c’est encore moins pratique qu’avec le Lua « pur » (et à vrai dire, c’est aussi un peu de ma faute, car même si c’est faisable, j’avoue que je n’ai encore jamais utilisé le « print » dans la console, avec la Pico, et je me sers uniquement d’affichages dans l’écran du jeu, ce qui ne me facilite pas non plus la tâche…).
Pour ce qui est de l’affichage des tables, j’avoue que je ne suis pas sûr de bien comprendre de quoi tu parles. Il me semble qu’on peut les afficher, en Lua, en ayant recours à des boucles… En tout cas c’est ce que je fais, sous Pico-8. Mais je ne connais pas du tout Python, et c’est peut-être pour ça que je ne vois pas ce que tu veux dire exactement…
Bon, ça n’a rien à voir, mais la troisième (et dernière) partie de ce devlog arrive ce soir (mardi). A dans quelques heures, donc…